{"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:One thing to add is that perhaps in a future version of Bitcoin Core,\nthere could be an option for users to continue using the old consensus\nrules, or an option to support the new rules (an option when they update\nand an ability to change in the settings). Both types of user can\nbenefit from the software updates and choose with a single piece of\nsoftware what they support. Information for whether or not a user is\nsupporting the changes could be included in the version message.\nPossibly this information could be incorporated into transactions also.\n\nIf they wish to support the new rules, then their client would support\nlarger blocks when there is majority miner consensus, otherwise their\nclients will always only support the old rules.\n\nThis way the decision is not being forced upon the user in any way.\n\nJust an idea.\n\nOn 07/05/15 16:58, Matthew Mitchell wrote:\n\u003e In my personal opinion, this does make some sense to me, assuming I\n\u003e understood Gavin.\n\u003e \n\u003e I suppose it could be done with a new flag (like the P2SH flag) which\n\u003e displays miner support for larger blocks. The new rules would apply when\n\u003e a large majority of miners support the new rules by counting the number\n\u003e of flagged blocks over a certain number of blocks on the network in a\n\u003e deterministic fashion.\n\u003e \n\u003e This way miners can continue to produce blocks which are supported by\n\u003e both old and new clients. When it appears most people have migrated to\n\u003e the new client, miners can start flagging support for the new rules, and\n\u003e when a large majority of miners agree, the new rules would kick in for\n\u003e all miners/clients running the new software. Miners could therefore glue\n\u003e together the network during the migration phase until enough people have\n\u003e updated to avoid severe fork scenarios. The only problem is ensuring\n\u003e that miners will continue to support both networks for long enough to\n\u003e enable successful migration.\n\u003e \n\u003e And if too many people disagree to make a clean hard fork (too many\n\u003e people stubbornly stick to the old rules), then it could be that the\n\u003e hard fork is aborted and everyone goes back to the old rules, or quite\n\u003e simply that the miners never give support for the new rules despite the\n\u003e mechanism being included in the new client. In those cases it would be\n\u003e as if nothing changed.\n\u003e \n\u003e This way the hard fork would be determined by user participation as\n\u003e judged by the miners.\n\u003e \n\u003e If it is done, I can't think of a fairer way.\n\u003e \n\u003e Matthew Mitchell\n\u003e \n\u003e On 07/05/15 15:52, Gavin Andresen wrote:\n\u003e\u003e For reference: the blog post that (re)-started this debate, and which\n\u003e\u003e links to individual issues, is here:\n\u003e\u003e   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks\n\u003e\u003e\n\u003e\u003e In it, I asked people to email me objections I might have missed. I\n\u003e\u003e would still appreciate it if people do that; it is impossible to keep up\n\u003e\u003e with this mailing list, /r/bitcoin posts and comments, and\n\u003e\u003e #bitcoin-wizards and also have time to respond thoughtfully to the\n\u003e\u003e objections raised.\n\u003e\u003e\n\u003e\u003e I would very much like to find some concrete course of action that we\n\u003e\u003e can come to consensus on. Some compromise so we can tell entrepreneurs\n\u003e\u003e \"THIS is how much transaction volume the main Bitcoin blockchain will be\n\u003e\u003e able to support over the next eleven years.\"\n\u003e\u003e\n\u003e\u003e I've been pretty clear on what I think is a reasonable compromise (a\n\u003e\u003e one-time increase scheduled for early next year), and I have tried to\n\u003e\u003e explain why I think it it is the right set of tradeoffs.\n\u003e\u003e\n\u003e\u003e There ARE tradeoffs here, and the hard question is what process do we\n\u003e\u003e use to decide those tradeoffs?  How do we come to consensus? Is it worth\n\u003e\u003e my time to spend hours responding thoughtfully to every new objection\n\u003e\u003e raised here, or will the same thing happen that happened last year and\n\u003e\u003e the year before-- everybody eventually gets tired of arguing\n\u003e\u003e angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?\n\u003e\u003e\n\u003e\u003e I AM considering contributing some version of the bigger blocksize-limit\n\u003e\u003e hard-fork patch to the Bitcoin-Xt fork (probably  \"target a hobbyist\n\u003e\u003e with a fast Internet connection, and assume Nelson's law to increase\n\u003e\u003e over time), and then encouraging merchants and exchanges and web wallets\n\u003e\u003e and individuals who think it strikes a reasonable balance to run it.\n\u003e\u003e\n\u003e\u003e And then, assuming it became a super-majority of nodes on the network,\n\u003e\u003e encourage miners to roll out a soft-fork to start producing bigger\n\u003e\u003e blocks and eventually trigger the hard fork.\n\u003e\u003e\n\u003e\u003e Because ultimately consensus comes down to what software people choose\n\u003e\u003e to run.\n\u003e\u003e\n\u003e\u003e -- \n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud \n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\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/97e8772e/attachment.sig\u003e"}