{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-06\n📝 Original message:Replies inline.\n\nOn 05/06/15 22:44, Tier Nolan wrote:\n\u003e On Wed, May 6, 2015 at 11:12 PM, Matt Corallo \u003cbitcoin-list at bluematt.me\n\u003e \u003cmailto:bitcoin-list at bluematt.me\u003e\u003e wrote:\n\u003e     Personally, I'm rather strongly against any commitment to a block size\n\u003e     increase in the near future.\n-snip-\n\u003e The question being discussed is what is the maximum block size merchants\n\u003e and users will accept.  This puts a reasonable limit on the maximum size\n\u003e miners can increase the block size to.\n\u003e \n\u003e In effect, the block size is set by the minimum of the miner's and the\n\u003e merchants/user's size.min(miner, merchants/users).\n\nIndeed, \"the bitcoin community of users and miners can decide to do\nwhatever they want\", but this is univeral - \"they\" could decide whatever\nthey want if \"they\" want to hardfork. That said, \"we\" should be having a\nrigorous technical discussion about whether it is sane to recommend a\ngiven course of action by releasing software which makes it happen.\n\n\u003e \n\u003e     This allows the well-funded Bitcoin ecosystem to continue building\n\u003e     systems which rely on transactions moving quickly into blocks while\n\u003e     pretending these systems scale. Thus, instead of working on technologies\n\u003e     which bring Bitcoin's trustlessness to systems which scale beyond a\n\u003e     blockchain's necessarily slow and (compared to updating numbers in a\n\u003e     database) expensive settlement, the ecosystem as a whole continues to\n\u003e     focus on building centralized platforms and advocate for changes to\n\u003e     Bitcoin which allow them to maintain the status quo[1].\n\u003e \n\u003e \n\u003e Would you accept a rule that the maximum size is 20MB (doubling every 2\n\u003e years), but that miners have an efficient method for choosing a lower size?\n\u003e \n\u003e If miners could specify the maximum block size in their block headers,\n\u003e then they could coordinate to adjust the block size.  If 75% vote to\n\u003e lower the size, then it is lowered and vice versa for raiding.\n\u003e \n\u003e Every 2016 blocks, the votes are counter.  If the 504th lowest of the\n\u003e 2016 blocks is higher than the previous size, then the size is set to\n\u003e that size.  Similarly, if the 504th highest is lower than the previous\n\u003e size, it becomes the new size.\n\u003e \n\u003e There could be 2 default trajectories.  The reference client might\n\u003e always vote to double the size every 4 years.\n\u003e \n\u003e To handle large blocks (\u003e32MB) requires a change to the p2p protocol\n\u003e message size limits, or a way to split blocks over multiple messages.\n\u003e \n\u003e It would be nice to add new features to any hard-fork.\n\u003e \n\u003e I favour adding an auxiliary header.  The Merkle root in the header\n\u003e could be replaced with hash(merkle_root | hash(aux_header)).  This is a\n\u003e fairly simple change, but helps with things like commitments.  One of\n\u003e the fields in the auxiliary header could be an extra nonce field.  This\n\u003e would mean fast regeneration of the merkle root for ASIC miners.  This\n\u003e is a pretty simple change.\n\nThe point of the hard block size limit is exactly because giving miners\nfree rule to do anything they like with their blocks would allow them to\ndo any number of crazy attacks. The incentives for miners to pick block\nsizes are no where near compatible with what allows the network to\ncontinue to run in a decentralized manner."}