{"type":"rich","version":"1.0","author_name":"npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6","author_url":"https://nostr.ae/npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-29\n📝 Original message:On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e The basic idea is, as many of us agree, hard fork is risky and should\n\u003e be well prepared. We need a long time to deploy it.\n\u003e\n\nMuch as it may be appealing to repeal the block size limit now with a grace\nperiod until a replacement is needed in a repeal and replace strategy, it's\ndubious to assume that an idea can be agreed upon later when it can't be\nagreed upon now. Trying to put a time limit on it runs into the possibility\nthat you'll find that whatever reasons there were for not having general\nagreement on a new setup before still apply, and running into the\nembarrassing situation of winding up sticking with the status quo after\nmuch sturm and drang.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/e04b8d19/attachment.html\u003e"}