{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-26\n📝 Original message:This is a hard fork. It is not about miners, at all. 2013 showed that when\nthere is true consensus mining can be coordinated on the order of hours or\ndays. This is about pushing through a coercive change to the\ndecentralization tradeoffs of bitcoin without unanimous consent.\nOn Jun 26, 2015 12:03 PM, \"Tier Nolan\" \u003ctier.nolan at gmail.com\u003e wrote:\n\n\u003e On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman \u003c\n\u003e patrick.strateman at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e  For a proposed hard fork to reach a level of consensus necessary to be\n\u003e\u003e safe requires that there be a clear and self evident course of action.\n\u003e\u003e\n\u003e\n\u003e Safety increases with more lead-in time.  If the reference client was\n\u003e updated so that the hard fork happened in two years, it would be pretty\n\u003e safe.  Miners would have time to update.\n\u003e\n\u003e If miners (or the community) objected, it is sort of like a game of\n\u003e chicken.\n\u003e\n\u003e This is one of the problems with not making decisions in advance, the\n\u003e resulting hard fork is inherently safer.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/f4b14ff9/attachment.html\u003e"}