4 ms·
>>I do mention in the paper that the assumptions are up for debate, but I did try pretty hard to justify those assumptions so they are certainly not arbitrary.
by CryptoPunk 5y ago
>>I do mention in the paper that the assumptions are up for debate, but I did try pretty hard to justify those assumptions so they are certainly not arbitrary.
Where in the paper did you justify those assumptions? I see them as not only totally arbitrary, but wrong according to any common sense analysis of threats or weighing of priorities.
>>If by "biased" you mean that I decided what results I wanted to get, and then chose the assumptions based on that, I really would love a bit more benefit of the doubt.
I will be happy to give you a benefit of the doubt if you can convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency.
>>You don't know me, so its a bit strange for you to start accusing me of cooking the books on something I spend literally dozens if not hundreds of hours on.
I don't think it's strange when you rest a behometh of an analysis on assumptions as unjustified as Bitcoin needing to limit scalability so that 90% of the world population, the vast majority of whom live in the developing world and can't afford to use Bitcoin today due to lack of scalability, can run a full node.
If one thinks adversarially, then one has to assume potential malicious intentions behind writings intended to justify limiting the scalability of the most well-known and highest market cap cryptocurrency.
>>However at the same time, we don't want the rugged pulled out from under us: we don't want bitcoin's rules to be changed out from under us. Enough full nodes need to be out there to ensure that various attacks aren't possible on the network and that blocks that propagate are valid blocks. I think there is some sweet spot on both of those amounts. And I do think more discussion is needed around the assumptions we're making. I wrote this paper in part to start exactly such a discussion about the assumptions and what concrete targets we have for bitcoin in terms of these network demographics.
Again: a trivial analysis shows that your logic is totally unsound. The population for whom you want to keep Bitcoin's node operation costs limited is also the population that cannot afford to use Bitcoin directly and thus has no incentive to run a full node.
It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin.
In a scenario where 80 million people, or the richest 1% of the world population, is both using Bitcoin regularly, and can afford to run a Bitcoin full node on dedicated hardware, is both possible, and entirely sufficient to prevent the rules of the network from being changed.
I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now, the Bitcoin economy is 200X larger than it is now, there are tens, possibly hundreds of thousands of people worldwide running full nodes, and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user. It's totally implausible, and I cannot imagine any reasonable basis for you holding this assumption.
>>Again, not arbitrary. The reason I did that is to include normal people. Normal people aren't going to buy and set up a dedicated server for bitcoin.
Almost any one who runs a full node is a committed individual, not a normal one. And a committed individual could very plausibly buy dedicated hardware, and allocate 100% of it to running a full node. The assumption that normal people need to be able to run a full node without buying hardware is not justified, as such people are very unlikely to run a full node anyway.
To summarize: normal non-committed people running Bitcoin nodes is in no way needed to maintain Bitcoin's resistance to attacks state-level actors, or prevent the rules from being changed without resistance from the userbase. This cohort is already a non-factor, and the more committed cohort running full nodes is entirely sufficient to maintain the network's decentralization and censorship resistance.
>>Well, yes, they could afford to. That isn't the question I'm concerned with. Its not about cost. Its about convenience. Will 10s of millions of people buy extra hardware just to run bitcoin? I would argue no, they won't.
It's not very inconvenient to buy and plug in a dedicated machine for running a full node. And if there are 80 million people worldwide who can afford to that, and practically everyone in the world is using Bitcoin every day, then yes, a significant minority of those 80 million people will go through the trouble of doing that.
If even 0.5% of that 80 million do, that's 400,000 nodes. And if some state, or collection of states, begins to organize to try to attack the network, more amongst those 80 million will be motivated to run a node if they live in a jurisdiction that allows it.
>>But yes, you're probably right that 10s of millions of people running PUBLIC full nodes is probably enough. My understanding is that we're at less than 1/1000th of that goal at the moment.
I didn't say 10s of millions of people running public full nodes is enough. I said 10s of millions of people BEING ABLE TO run one is enough.
Driving for 10s of millions of full nodes, by limiting network throughput to the point where only 0.1% of the world population can transact on it daily, makes absolutely no sense. That would never work.
Furthermore, it makes no sense why Bitcoin would need 10s of millions of full nodes. It's an arbitrary assumption, that is not supported by any detailed threat analysis or any evidence of real-world attacks that necessitate that size of a network for that matter.
>>Putting the majority of economic activity in SPV nodes would leave the system quite vulnerable in situations where a majority of hashpower hardforks to something dangerous or malicious.
SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain. Such an attack would be extremely conspicious, and there would be a strong social reaction to it resulting in any SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data.
Right now, the vast majority of the world population cannot use Bitcoin, and you're trying to justify the extreme restrictions on throughput that cause this, on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers, in which case the majority of the world population would be no worse off than they are now, where they rely on an entirely centralized financial system, because they cannot use Bitcoin.
>>I'm curious what your analysis would be of that.
Only what I already stated: the best defense against a political attack is allowing Bitcoin to scale by 100 or 1,000 times in throughput, to increase the proportion of the population that is economically dependent on the network, and would oppose attempts to politically attack it.
- billytetrud 5y ago> Where in the paper did you justify those assumptions? I have a whole section on available machine resources which cites a ton of sources. I also wrote down specific goals and an exhaustive list of "Failure-Mode Considerations". The assumptions and requirements are based on matching available resources with the stated goals and preventing the listed failure modes. If they don't match up, I'd love to debate that. If they do match up, but you think the goals are off base, I'd love to debate that too. I'm curious what specifically we disagree on that leads to our disagreement on the acceptability of the assumptions. > It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin. Ok. So I hear you saying that my assumptions lead to a primary bottleneck that can be loosened by reducing the requirements. You're saying that assuming that 90% of Bitcoin users should be able to run a full node alongside the goal of everyone on earth using bitcoin leads to a situation where there is not enough on-chain space to support that number of users. I think that's a valid line of thinking. However, I don't think analysis of that is in any way "trivial". How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there? Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain? Or do you think the lightning network will scale? If you think the lightning network will be able to scale to a world-wide payment network, how much on-chain traffic is needed to support it? Will people batch their transactions? How well will schnorr signature aggrigation work to reduce traffic in practice? Etc etc. This paper don't really use any of that kind of thinking in its assumptions. Instead it chooses goals and finds what requirements satisfy those goals. Do you think my analysis likely finds the right requirements to satisfy the given goals and assumptions? > any one who runs a full node is a committed individual That is true today becauase its a pain in the ass to run a full node. You need to keep it on all the time, it sucks up resources on your computer, it takes some research to configure it correctly or buy the right hardware (so that it isn't a potato). It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run. More wallets could integrate a full bitcoin node, however they aren't doing that because it is so resource intense. If every desktop wallet ran a full node, then I'm sure you would agree that a lot more people would run a full node. > The assumption that normal people need to be able to run a full node without buying hardware is not justified Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#sybil-and-eclipse-attacks https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... . We can't rely on just "committed individuals" to run public full nodes. There just aren't enough of them. > It's not very inconvenient to buy and plug in a dedicated machine for running a full node. I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen. > If even 0.5% of that 80 million do, that's 400,000 nodes I calculated that we need 5 million honest public full nodes to have enough security to resist state-level sybil attacks. Again, see the Sybil and Eclipse Attacks section. > In a scenario where .. the richest 1% of the world .. is .. using .. a Bitcoin full node .. sufficient to prevent the rules of the network from being changed. I disagree, as I said in my previous comment. And in the next paragraph. > I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now .. and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user. Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously. Outcry doesn't happen instantaneously. An attack (or mistake) like that could cause massive massive damage in a very short period of time. Lets say 45% of world's economic activity (the 1%) is done using full nodes. The rest is on SPV nodes. A 51% group of miners could create a hard fork and release it. Let's further say the group also has a large sybil network they use to propagate their blocks more quickly (which may be useful in honest mining) and these nodes also serve SPV nodes. Up to 55% of the network (all the SPV nodes) could follow that hard fork as soon as its release, more if the fork has support among others running those full nodes. This would in turn give the rest of the miners who weren't party to this an economic incentive to follow that fork, since it has the majority of both hashpower and economic activity. Even if outcry then happened, it would be impossible to undo the damage done. Another hardfork could be done to reverse the change, but the forks could never re-merge. This would split bitcoin into two currencies and cause massive economic chaos and friction that would probably be numbered in the billions of dollars in disruptive damage. You could say that its unlikely that 51% of the miners could put together such a hard fork without people knowing about it, and I agree (although its certainly in the realm of realistic possibility). However, I think its not clear that enough outcry would happen such that miners wouldn't end up doing it anyway. People in the world generally don't pay much attention to large-scale things like this, especially things like monetary policy and technical security related things. Its quite likely I think that >95% of people simply wouldn't pay much attention to it until it happened. Regardless, even a 1% probability of that happening per century is far too high I think. Even if 55% of the world's economic activity ran on full nodes, miners wouldn't necessarily know that. Its very hard to measure those kinds of things precisely, and wishful thinking could bias them to thinking more people are on SPV than in reality. A hard fork would still have massive negative consequences. The way SPV is currently designed, a hard fork like this could be harmful to anyone running an SPV node. However, if the fraction of SPV nodes is low enough, the incentive to attempt such an attack would be subtantially lower. So that's one situation and one aspect of it. There would also be bad consequences for the vulnerability of mining to attack if the blocksize limit was 2GB. > SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain How long would this take? How many SPV users (ie 99% of the population in your ideal scenario) would actually put in the effort to make any change whatsoever? > Such an attack would be extremely conspicious, and there would be a strong social reaction to it I agree with both of those things. But conspicuousness of an attack doesn't prevent it from happening and causing massive damage in the time while the attack is able to operate. > SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data. Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes. While yes, SPV servers could be blacklisted, this would hardly be a painless or easy process. And it would be too late to stop the hard fork in my scenario above from happening. The economy would have already switched onto the hardfork, and the transactions on that fork would be irreversible without even more massive disruption and damage. > on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork. That's exactly the scenario where something like this could happen. Rash decisions, lots of contention, emotions flaring. No centralized authority was needed for that scenario to cause problems. And if SPV nodes could simply be coopted to whoever had majority hashpower (or even minority hashpower in the cases where SPV nodes are mostly tied to specific SPV services rather than a distributed network of SPV server nodes), that would be no bueno.