> 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 s

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