bitcoinThroughputAnalysis

-chain throughput the lightning network would need if it indeed scales up to a large fraction of the world's tranasctions. > Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software I believe I made my assumptions very clear. The easiest attack against bitcoin today is a Sybil attack that drains the resources of public nodes. Because that is the weakest link of bitcoin, that should be the highest priority to improve. It is rather indisputable that making a full node take more resources will reduce the fraction of people willing to run a public full node, and that making a full node take less resources to run will conversely increase the fraction of people willing to run a public full node. Do you disagree with that last sentence? The next important question would be how elastic is that relationship? Would reducing the resources by half double the number of public full nodes? Would it do more? Less? Another question would be: how many more public nodes would we get from further adoption of bitcoin? And again, the third piece would be: how much adoption would we get from increasing on-chain throughput? This 3 variable set of relationships would be quite interesting to add the the discussion of this in order to contrast the goals I chose vs the ones you have. Are you willing to do that math or make estimates? Or are you just demanding that I put in the effort to evaluate your claims (that increasing throughput via larger block size is the fastest way to improving bitcoin's worst-case / weakest-link security) for you? Of course, your assumption seems to be that bitcoin is most suceptible to a political attack, whereas the easiest attack I've analyzed is a Sybil attack on public node resources. Are you willing to quantify the risks and costs of attack there and do the analysis? If so, I think that would be very valuable. But as it stands, it sounds like you're simply claiming that you have discredited my work without actually showing any of your own work that might give rigorous evidence that my paper has flaws that can be improved on. I also asked you a question that you ignored. I'd appreciate an answer: >> It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing?

ys people transact, some better than others. If your analysis were to make that a critical piece of the discussion, it would have to be justified in more depth. But I'm not trying to ask you to do hours of analysis here. > Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack You may read what you want, but the intention of the paper was primarily to create a reusable way to evaluate the safe/secure throughput limits of bitcoin. The intention was explicitly not to come up with the "correct" or "best" assumptions or requirements of the network. It simply chose conservative limits and rolled with those. I was very clear about this in the paper. I'm happy to discuss the assumptions, but if your problem with the paper is that the assumptions aren't where you think they should be, you're asking of the paper something outside of its scope. > You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it. I don't think you're understanding me. You are explaining the current state of things. I'm thinking about a future where bitcoin doesn't take research to configure, and is a no brainer to run. You don't have to worry about reaching bandwidth caps or slowing down your apartment's internet or making your machine slow when you're playing a game. We agree that it currently takes committed people to run bitcoin. I think that needs to change. > Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility While I would love to hear about new strategies my paper doesn't incorporate, the first half of the paper explicitly doesn't incorporate new technology. It analyses the network as created by current bitcoin software. > For example, there's trust-based network-peering That's interesting. I worry that relying on trust might introduce issues, but its interesting nonetheless. I'll read through that. Thanks! > Strawman. I never said that 10s of millions of people would be willing to do that When I wrote that sentence, I still misunderstood what you meant. I forgot to revise after realizing you just meant that 10s of millions of people would need to be able to run full nodes, but it seems you think that far fewer would actually have to run full nodes. > The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years. Perhaps you're right. But this paper neither refutes nor confirms that, and analysizing the optimal tradeoffs there is, again, out of scope for the paper. > There are relatively low-cost ways to prevent that from being the case in the future. Yes and many of those ways are even less secure. If you're referring to the trust-based network-peering you mentioned, perhaps there's something there, but trust-based is by definition not trustless, which is generally what bitcoin is built to be. I agree some kinds of small but less-than-minimal trust could definitely be useful. But the fact is that bitcoin doesn't currently have those mechanisms. > It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing? > It's a broader and more sensible goal to pursue Perhaps. But the scope of the paper is broad enough. I hope you can appreciate that ideas an techniques in the paper can be useful even if the goal is not something you agree with.

as that will result in me not being allowed to even criticize your central assumptions due to be over-burdened by the analysis requirement. >>Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain? The assumption that the lightning network will even work is extremely speculative, and the burden is on those making this assumption to support it, not on me to support the idea that it won't. There is no compelling reason to believe that an experimental network with extremely low adoption levels will ever prove highly useful, and gain widespread usage. >>Instead it chooses goals and finds what requirements satisfy those goals. Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack, and not merely that it can't scale and satisfy the goal of 90% of the world population being able to run a full node using only 10% of hardware and network resources they already own. It doesn't justify its starting assumption. >>That is true today becauase its a pain in the ass to run a full node. I disagree. All it takes is to install the Bitcoin full node software on any computer with sufficient hardware resources, and start running it, with next to no configuration. You can even buy plug-and-play Bitcoin nodes where the full node software comes already installed on the device, to skip that trivial step of downloading and installing the software. >>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. I don't see how you're justifying your argument that running a full node is not for the minority of people that are "committed individuals". You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it. Moreover, I clearly acknowledged that the resources a full node takes to run affects the number of people likely to run it, as I specifically restricted the percentage of the world population able to run a full node under high-scalability assumptions to 1%, or 80 million, on the basis that only they could afford to purchase those resources, My claim implies 99% of the world population would not be likely to run a full node in a high-scalability scenario, due to the unaffordability of acquiring the hardware and bandwidth resources for this cohort. >>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#syb... . Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility, and far more likely to actually work, than imposing extreme restrictions on Bitcoin's throughput, which would only work if the extremely inconsistent assumption that tens of millions of people who currently cannot transact on Bitcoin will run a full node. For example, there's trust-based network-peering: http://www.cs.columbia.edu/~danr/courses/6772/Fall06/papers/... >>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. Strawman. I never said that 10s of millions of people would be willing to do that, or this would be needed to maintain resistance to cooption. >>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. The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years. >>Regardless, even a 1% probability of that happening per century is far too high I think. This conclusions on an extremely inconsistent set of assumptions. On what basis is 99.9% of the world population not being able to use Bitcoin due to the current extreme restrictions on throughput, a better scenario than there being a 1% probability of a scalable and mass-adopted Bitcoin suffering a failure of the type you describe once per century? >>Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes. There are relatively low-cost ways to prevent that from being the case in the future. >>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. It would require more than just miners that want it. It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition, or else those SPV data servers who want the change would face social backlash and a mass migration away from reliance on them. >>One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed. Yes, and I think of all the ways to mitigate the risks to Bitcoin, this is the most effective one, that results in the greatest reduction of risk to Bitcoin. >>Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change. If they can convince real people to support the change, they can also support real people running full nodes to support the change, so this risk is not alleviated by restricting transaction throughput to lower the cost of running a full node. > convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial. >>My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks. Pursuing the goal of "seeing people financially empowered by cryptocurrency" would also involve pursuing the goal of "mak[ing] the Bitcoin system be secure against adversarial attacks", but it does not hold it as the only goal. It's a broader and more sensible goal to pursue, since a highly secure Bitcoin network is only useful to the extent that people can use it. >>I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you. If I see evidence of bias in your writings, I will express my opinion on it.

sumptions 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#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.

peed tends to stay mired in the tens per second region is that no amount of consensus accounting gimmickry will overcome the underlying physical limitations of true global scale decentralization of consensus. Yeah, there are physical limits. The speed of light is the ultimate limit here. You can't come to a consensus with someone faster than you can send and receive a response from them. And the minimum requirements for consensus probably require a lot more than one message and one response.