📅 Original date posted:2017-05-26
📝 Original message:Your proposal seems to be simply BIP 91 tied to the
as-yet-entirely-undefined hard fork Barry et al proposed.
Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
you propose, would make the deployment on the incredibly short timeline
Barry et al proposed slightly more realistic, though I would expect to
see hard fork code readily available and well-tested at this point in
order to meet that timeline.
Ultimately, due to their aggressive timeline, the Barry et al proposal
is incredibly unlikely to meet the requirements of a
multi-billion-dollar system, and continued research into meeting the
spirit, not the text, of their agreement seems warranted.
Matt
On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
> Forgive me if this is a dumb question. Suppose that rather than
> directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in
> just triggered BIP141 signaling (plus later HF). Would that avoid
> incompatibility with existing BIP141 nodes, and get segwit activated
> sooner? Eg:
>
> - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support
> for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
> - If bit 4 support reaches 80%, it locks in two things: the scheduled HF
> (conditional on segwit), and *immediately* turning on bit 1 (BIP141 support)
>
> I realize this would still leave problems like the aggressive HF
> schedule, possible chain split at the HF date between Segwit2MB nodes
> and any remaining BIP141 nodes, etc. My focus here is how
> incompatibility with existing nodes could be minimized.
>
> (BIP91 could also be used if BIP141 support still fell short of 95%.
> But if Segwit2MB support reaches 80%, it seems likely that an additional
> 15% will support BIP141-without-HF.)
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:01:23
in reply to nevent1q…8kcs
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:01:23Event JSON
{
"id": "dad0c45032b937c569b8420da3b0b0f969faba2ee353ae66a09e4ca3537f8391",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686160883,
"kind": 1,
"tags": [
[
"e",
"5f4e5578a00516f73144a00c0c15e1afca8ff6c2e2a719034eb27cdcba62a8d3",
"",
"root"
],
[
"e",
"ff5c2be26565f3285065519ad1351c561251dfe27ded3389ecf38fbb12e5cb69",
"",
"reply"
],
[
"p",
"dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7"
]
],
"content": "📅 Original date posted:2017-05-26\n📝 Original message:Your proposal seems to be simply BIP 91 tied to the\nas-yet-entirely-undefined hard fork Barry et al proposed.\n\nUsing James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as\nyou propose, would make the deployment on the incredibly short timeline\nBarry et al proposed slightly more realistic, though I would expect to\nsee hard fork code readily available and well-tested at this point in\norder to meet that timeline.\n\nUltimately, due to their aggressive timeline, the Barry et al proposal\nis incredibly unlikely to meet the requirements of a\nmulti-billion-dollar system, and continued research into meeting the\nspirit, not the text, of their agreement seems warranted.\n\nMatt\n\nOn 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:\n\u003e Forgive me if this is a dumb question. Suppose that rather than\n\u003e directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in\n\u003e just triggered BIP141 signaling (plus later HF). Would that avoid\n\u003e incompatibility with existing BIP141 nodes, and get segwit activated\n\u003e sooner? Eg:\n\u003e \n\u003e - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support\n\u003e for \"segwit now, HF (TBD) at scheduled date (Nov 23?)\"\n\u003e - If bit 4 support reaches 80%, it locks in two things: the scheduled HF\n\u003e (conditional on segwit), and *immediately* turning on bit 1 (BIP141 support)\n\u003e \n\u003e I realize this would still leave problems like the aggressive HF\n\u003e schedule, possible chain split at the HF date between Segwit2MB nodes\n\u003e and any remaining BIP141 nodes, etc. My focus here is how\n\u003e incompatibility with existing nodes could be minimized.\n\u003e \n\u003e (BIP91 could also be used if BIP141 support still fell short of 95%. \n\u003e But if Segwit2MB support reaches 80%, it seems likely that an additional\n\u003e 15% will support BIP141-without-HF.)\n\u003e \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",
"sig": "746563dd58fd0f3b8aa243204a22e3f885a4b7ef4e7164c5ff3b62cafc45cad0cc76777d2c3bce9c903242f15834185cc883664deecf762abda2fa88a298fa13"
}