{"type":"rich","version":"1.0","author_name":"npub16wtdr5grjycaw37553u5vvlfq09rwxhzz4kler6pz952a7ny6mtqslgem7","author_url":"https://nostr.ae/npub16wtdr5grjycaw37553u5vvlfq09rwxhzz4kler6pz952a7ny6mtqslgem7","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-05\n📝 Original message:On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Also I don't think \"hitting the limit\" must be necessarily harmful and\n\u003e if it is, I don't understand why hitting it at 1MB will be more\n\u003e harmful than hitting it at 2MB, 8MB or 8GB.\n\n\nI don't think merely hitting the limit is bad. The level of tx fees in\nequilibrium give some clue as to the level of harm being done. If fees are\nat $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.\n\nThere is NO criterion based on mining centralization to decide between\n\u003e 2 sizes in favor of the small one.\n\u003e It seems like the rationale it's always \"the bigger the better\" and\n\u003e the only limitation is what a few people concerned with mining\n\u003e centralization (while they still have time to discuss this) are\n\u003e willing to accept. If that's the case, then there won't be effectively\n\u003e any limit in the long term and Bitcoin will probably fail in its\n\u003e decentralization goals.\n\u003e I think its the proponents of a blocksize change who should propose\n\u003e such a criterion and now they have the tools to simulate different\n\u003e block sizes.\n\u003e\n\nIn the absence of harder data, it might be interesting to use these\nsimulations to graph centralization pressure as a function of bandwidth\ncost over time (or other historical variables that affect centralization).\nFor instance, look at how high centralization pressure was in 2009\naccording to the simulations, given how cheap/available bandwidth was then,\ncompared to 2010, 2011, etc. Then we could figure out: given today's\nbandwidth situation, what size blocks right now would give us the same\ncentralization pressure that we had in 2011, 2012, 2013, etc?\n\nOf course this doesn't mean we should blindly assume that the level of\ncentralization pressure in 2012 was acceptable, and therefore any block\nsize increase that results in the same amount of pressure now should be\nacceptable. But it might lead to a more productive discussion.\n\n\n\u003e I want us to simulate many blocksizes before rushing into a decision\n\u003e (specially because I disagree that taking a decision there is urgent\n\u003e in the first place).\n\n\nIMO it is not urgent if the core devs are committed to reacting to a huge\nspike in tx fees with a modest block size increase in a relatively short\ntime frame, if they judge the centralization risks of that increase to be\nsmall. Greg Maxwell posted on reddit a while back something to the effect\nof \"the big block advocates are overstating the urgency of the block size\nincrease, because if there was actually a situation that required us to\nincrease block size, we could make the increase when it was actually\nneeded.\" I found that somewhat persuasive, but I am concerned that I\nhaven't seen any discussion of what the \"let's wait for now\" camp would\nconsider a valid reason to increase block size in the short term, and how\nthey'd make the tradeoff with tx fees or whatever else was necessitating\nthe increase.\n\nJorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew\nwith certainty that increasing to 4MB would result in a 20 cent/tx\nequilibrium that would last for a year (otherwise fees would stay around $5\nfor that year), would you be in favor of an increase to 4MB?\n\nFor those familiar with the distinction between near/far mode thinking\npopularized by Robin Hanson: focusing on concrete examples like this\nencourages problem solving and consensus, and focusing on abstract\nprinciples (like decentralization vs. usability in general) leads to people\ntoward using argument to signal their alliances and reduce the status of\ntheir opponents. I think it'd be very helpful if more 1MB advocates\ndescribed what exactly would make them say \"OK, in this situation a block\nsize increase is needed, we should do one quickly!\", and also if\nGavin/Mike/Jeff described what hypothetical scenarios and/or test results\nwould make them want to stick with 1MB blocks for now.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/0913c1b2/attachment.html\u003e"}