{"type":"rich","version":"1.0","author_name":"npub18unhg43arsfv864rhmsdr2w28lmqcc65025rrvquq6wslrfharrsezct0n","author_url":"https://nostr.ae/npub18unhg43arsfv864rhmsdr2w28lmqcc65025rrvquq6wslrfharrsezct0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-07\n📝 Original message:In my personal opinion, this does make some sense to me, assuming I\nunderstood Gavin.\n\nI suppose it could be done with a new flag (like the P2SH flag) which\ndisplays miner support for larger blocks. The new rules would apply when\na large majority of miners support the new rules by counting the number\nof flagged blocks over a certain number of blocks on the network in a\ndeterministic fashion.\n\nThis way miners can continue to produce blocks which are supported by\nboth old and new clients. When it appears most people have migrated to\nthe new client, miners can start flagging support for the new rules, and\nwhen a large majority of miners agree, the new rules would kick in for\nall miners/clients running the new software. Miners could therefore glue\ntogether the network during the migration phase until enough people have\nupdated to avoid severe fork scenarios. The only problem is ensuring\nthat miners will continue to support both networks for long enough to\nenable successful migration.\n\nAnd if too many people disagree to make a clean hard fork (too many\npeople stubbornly stick to the old rules), then it could be that the\nhard fork is aborted and everyone goes back to the old rules, or quite\nsimply that the miners never give support for the new rules despite the\nmechanism being included in the new client. In those cases it would be\nas if nothing changed.\n\nThis way the hard fork would be determined by user participation as\njudged by the miners.\n\nIf it is done, I can't think of a fairer way.\n\nMatthew Mitchell\n\nOn 07/05/15 15:52, Gavin Andresen wrote:\n\u003e For reference: the blog post that (re)-started this debate, and which\n\u003e links to individual issues, is here:\n\u003e   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks\n\u003e \n\u003e In it, I asked people to email me objections I might have missed. I\n\u003e would still appreciate it if people do that; it is impossible to keep up\n\u003e with this mailing list, /r/bitcoin posts and comments, and\n\u003e #bitcoin-wizards and also have time to respond thoughtfully to the\n\u003e objections raised.\n\u003e \n\u003e I would very much like to find some concrete course of action that we\n\u003e can come to consensus on. Some compromise so we can tell entrepreneurs\n\u003e \"THIS is how much transaction volume the main Bitcoin blockchain will be\n\u003e able to support over the next eleven years.\"\n\u003e \n\u003e I've been pretty clear on what I think is a reasonable compromise (a\n\u003e one-time increase scheduled for early next year), and I have tried to\n\u003e explain why I think it it is the right set of tradeoffs.\n\u003e \n\u003e There ARE tradeoffs here, and the hard question is what process do we\n\u003e use to decide those tradeoffs?  How do we come to consensus? Is it worth\n\u003e my time to spend hours responding thoughtfully to every new objection\n\u003e raised here, or will the same thing happen that happened last year and\n\u003e the year before-- everybody eventually gets tired of arguing\n\u003e angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?\n\u003e \n\u003e I AM considering contributing some version of the bigger blocksize-limit\n\u003e hard-fork patch to the Bitcoin-Xt fork (probably  \"target a hobbyist\n\u003e with a fast Internet connection, and assume Nelson's law to increase\n\u003e over time), and then encouraging merchants and exchanges and web wallets\n\u003e and individuals who think it strikes a reasonable balance to run it.\n\u003e \n\u003e And then, assuming it became a super-majority of nodes on the network,\n\u003e encourage miners to roll out a soft-fork to start producing bigger\n\u003e blocks and eventually trigger the hard fork.\n\u003e \n\u003e Because ultimately consensus comes down to what software people choose\n\u003e to run.\n\u003e \n\u003e -- \n\u003e --\n\u003e Gavin Andresen\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud \n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/733b3667/attachment.sig\u003e"}