Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!
Once we mitigate these bandwidth limitations, increasing the block size limit stops looking so dangerous.
Franky, all you've proven is that video-conferencing is a slightly better analogy for the upload requirements of running a bitcoin node than is downloading a web page. I don't need to "debunk Skype," as you put it, because the question is not whether "the internet cannot cope with their activity".
The question is absolutely not "can more than 2mb can be uploaded?" The question is not, is it possible to run a node? The question is, at what point do bandwidth limitations disincentivize the operation of full nodes to the extent that centralization endangers security and fungibility?
2mb.. or even 2mb+segwit is not an issue.. and is not a nuclear bomb threat.. so at this point of this topic of 2mb.. CHILL OUT. there is no doomsday.
i do agree that 20mb is a doomsday. but 2mb is not. so that hopefully ends your argument that 2mb is a problem.
I posed a theoretical question -- you are the one getting dramatic. How do you know that 20MB is doomsday? How do you know that 2MB is not? My biggest problem is with people arguing for a contentious hard fork (dangerous in its own right) without providing any technical justifications for it.
We already know that over the past several years, as block size has gradually increased, operating nodes have persistently fallen. Would you suggest that block size, which is directly related to bandwidth requirements for nodes, is not related to the perpetual decline in nodes?
blaming it purely on bandwidth as the reason is false.
many users are not running a full node 24-7 not due to bandwidth concerns. but more so to do with the fact that people are not day trading as much, people are not spending 3-10 times a day so they see less point in keeping their computer on 24-7 if they are not actually going to use it.
EG in gaming. if you want to go away for half an hour and do something else. you just go AFK(away from keyboard) and minimise the game while keeping it running. but if your only going to play the game for 10 minutes a day. you will log out and switch off the computer because you know you wont be using it any time soon.
ive even seen it in IRC chat rooms. those that just go AFK return promptly but never log out of IRC. but when people say 'im going out for the day' they log out completely.
Can you prove any of this? "The extent to which bitcoin node operators are day trading" (via their wallets
) is not a measurable pressure on nodes. Upload bandwidth requirements are. And why is this comparable to running a node, anyway? Why would I turn off my node just to go AFK? Wouldn't you agree that it would be optimal for node operators to keep them running, rather than turning them on and off for short instances of use?For my claim to be true, bandwidth does not to be "purely" the reason, but part of it. That implies that bandwidth is a real pressure on node centralization that has to be considered if bitcoin is to remain a p2p protocol.
again internet speed is not an issue, the fear that it would be an issue .. is the issue. even on standard DSL in 2011 people on livestream/twich/skype were ok, and 5 years later still ok.. infact millions of people.. not 5000,, millions of people are making HD content which is actually more bandwidth than my numbers in my last post.
Again, you are comparing whether one can run Skype with whether one can run a bitcoin node -- already a poor analogy given that optimally a node is running all the time (i.e. not just during a teleconference). The question is not whether one can run a bitcoin node:
Quote
The question is, at what point do bandwidth limitations disincentivize the operation of full nodes to the extent that centralization endangers security and fungibility? We already know that over the past several years, as block size has gradually increased, operating nodes have persistently fallen. Would you suggest that block size, which is directly related to bandwidth requirements for nodes, is not related to the perpetual decline in nodes? As a node operator, I can tell you that bandwidth is the only possible reason why I wouldn't run a node (as opposed to storage, hard disk resources, hardware). That's the only pressure. Most people do not have unlimited fiber connections. Most people have capped-bandwidth cable or low quality DSL. So the question is not, "can these people run a node, using much or all of their upload bandwidth? Or will they choose not to? The latter is what we must contend with -- and is related to the perpetual decline in nodes over the past couple years.
Limited by bandwidth caps or speed, will a potential node operator run a node if it interferes with his use of Skype, online games, upload streaming, torrenting, etc? Running a node means balancing bandwidth resources. Since there is zero incentive to run a node (other than to self-validate in the short term), a node operator will shut down their node before curbing any other bandwidth-heavy activity, if bandwidth is limited. So, at what point will typical node operators simply start switching off their nodes? The data suggests that this has already been happening for a long time at <1MB, and you don't have any data to argue against that.
This certainly doesn't mean doomsday at all. Here is part of the quote that you deleted from my post:
I said that bitcoin has capacity limitations that are linked to bandwidth limitations for individual nodes. Further optimizations like IBLTs and weak blocks could greatly mitigate those limitations (and over time, infrastructural limits to upload bandwidth should improve as well).
Once we mitigate these bandwidth limitations, increasing the block size limit stops looking so dangerous.
Quote
IBLTs and weak blocks: 90% or more reduction in critical bandwidth to relay blocks created by miners who want their blocks to propagate quickly with a modest increase in total bandwidth, bringing many of the benefits of the Bitcoin Relay Network to all full nodes. This improvement is accomplished by spreading bandwidth usage out over time for full nodes, which means IBLT and weak blocks may allow for safer future increases to the max block size.
Once we mitigate these bandwidth limitations, increasing the block size limit stops looking so dangerous.