{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-26\n📝 Original message:On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman \u003c\npatrick.strateman at gmail.com\u003e wrote:\n\n\u003e  For a proposed hard fork to reach a level of consensus necessary to be\n\u003e safe requires that there be a clear and self evident course of action.\n\u003e\n\nSafety increases with more lead-in time.  If the reference client was\nupdated so that the hard fork happened in two years, it would be pretty\nsafe.  Miners would have time to update.\n\nIf miners (or the community) objected, it is sort of like a game of chicken.\n\nThis is one of the problems with not making decisions in advance, the\nresulting hard fork is inherently safer.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/dd5e7ab9/attachment.html\u003e"}