3 ms·

> I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for

> I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for the network to remain safe from an attack. Can you actually copy-paste..? I don't have any good clips of text that would connect them better. A lot of the connection between them is left vauge and implied. I agree this can be improved. I've created an issue for this: https://github.com/fresheneesz/bitcoinThroughputAnalysis/issues/4 https://github.com/fresheneesz/bitcoinThroughputAnalysis/iss... Feel free to comment there. > I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population. I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways 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.

CryptoPunk 5y ago
Your arguments and analysis together contain grave contradictions that discredit them. For instance, you argue that your position/paper does not rely on potential future innovations, like here: >>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. But then you rely on your assumption that Bitcoin could indeed gain significant adoption, while limited to an on-chain throughput limit of three transactions per second, based on a secondary assumption: that off-chain transaction solutions, that despite years of development, have failed to gain any appreciable market adoption, and which many argue are fundamentally limited in their utility, especially in scenarios where on-chain transaction fees are high, will in fact undergo development and innovation that will make them widely useful: >>I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways 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. My assumption, that one of many low-cost approaches to defending against Sybil attacks, could be successfully developed and implemented into Bitcoin, is much safer than your assumption that off-chain based payment systems, like Lightning Network, will overcome their many technical limitations and become market successes, and massively increase Bitcoin's adoption. So to summarize, you are in fact resting your 'Bitcoin node costs required to keep the network safe' assumption on assumptions about future development/adoption of highly experimental and unproven off-chain technologies. Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software that will be developed: >>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. This is just one of several ways in which your stance and arguments appear disingenuous due to their inconsistencies.
- billytetrud 5y ago
  > you argue that your position/paper does not rely on potential future innovations Let me ask you something: how much of my paper did you actually read? Again, the first half discusses current bitcion (actually 2019 bitcoin, when I wrote the paper). The second half discusses a prediction of future bitcoin. And did you read the section on User Growth and Growth of Public Nodes? Its very relevant to your line of thinking. https://github.com/fresheneesz/bitcoinThroughputAnalysis#user-growth-and-growth-of-public-nodes https://github.com/fresheneesz/bitcoinThroughputAnalysis#use... > a secondary assumption: that off-chain transaction solutions... will .. undergo development and innovation that will make them widely useful Nothing in the core of my paper relies on any assumptions about the lightning network. The paper is about on-chain throughput not 2nd layers. The only mention of the lightning network is in discussion around how much on-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?

CryptoPunk 5y ago

Your arguments and analysis together contain grave contradictions that discredit them. For instance, you argue that your position/paper does not rely on potential future innovations, like here: >>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. But then you rely on your assumption that Bitcoin could indeed gain significant adoption, while limited to an on-chain throughput limit of three transactions per second, based on a secondary assumption: that off-chain transaction solutions, that despite years of development, have failed to gain any appreciable market adoption, and which many argue are fundamentally limited in their utility, especially in scenarios where on-chain transaction fees are high, will in fact undergo development and innovation that will make them widely useful: >>I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways 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. My assumption, that one of many low-cost approaches to defending against Sybil attacks, could be successfully developed and implemented into Bitcoin, is much safer than your assumption that off-chain based payment systems, like Lightning Network, will overcome their many technical limitations and become market successes, and massively increase Bitcoin's adoption. So to summarize, you are in fact resting your 'Bitcoin node costs required to keep the network safe' assumption on assumptions about future development/adoption of highly experimental and unproven off-chain technologies. Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software that will be developed: >>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. This is just one of several ways in which your stance and arguments appear disingenuous due to their inconsistencies.

billytetrud 5y ago
> you argue that your position/paper does not rely on potential future innovations Let me ask you something: how much of my paper did you actually read? Again, the first half discusses current bitcion (actually 2019 bitcoin, when I wrote the paper). The second half discusses a prediction of future bitcoin. And did you read the section on User Growth and Growth of Public Nodes? Its very relevant to your line of thinking. https://github.com/fresheneesz/bitcoinThroughputAnalysis#user-growth-and-growth-of-public-nodes https://github.com/fresheneesz/bitcoinThroughputAnalysis#use... > a secondary assumption: that off-chain transaction solutions... will .. undergo development and innovation that will make them widely useful Nothing in the core of my paper relies on any assumptions about the lightning network. The paper is about on-chain throughput not 2nd layers. The only mention of the lightning network is in discussion around how much on-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?