Bram Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-29 📝 Original message:On Tue, Mar 28, 2017 at ...
📅 Original date posted:2017-03-29
📝 Original message:On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/e04b8d19/attachment.html>
Published at
2023-06-07 17:58:05Event JSON
{
"id": "409503a97a87b383d94dc168275155eb4702f75c437c89852a6ad66962c255e8",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160685,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"c883b42142060cf52f30bdc6c49b01decf02aac1a6a2228d75303483dcc75f0f",
"",
"reply"
],
[
"p",
"dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7"
]
],
"content": "📅 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",
"sig": "a94200eb68f9c15c42200745666b1d61f41e4dfb180d57a26fd7e1981bea38cb70b95adbb3b7e69455dddf594da40fe8a6efb86e34ff4437c888f6ca44016eb3"
}