📅 Original date posted:2017-05-26
📝 Original message:Mandatory signalling is the only way to lock in segwit with less than
95% hashpower without a full redeployment(which for a number of
technical reasons isn't feasible until after the existing segwit
deployment expires). There's no reason not to signal BIP141 bit 1
while also signalling bit 4, but you would want to use bit 4 to
coordinate bit 1 mandatory signalling.
It would not be feasible to schedule any HF until one can be
completely sure BIP141 is active(at least not without waiting for the
timeout and doing a redeployment) due to activation/p2p codepath
complexity. This is why the mandatory signalling period is needed.
Since it is likely a HF will take months of development and testing I
see this or something similar as the fastest safe path forward:
1. Use BIP91 or similar to activate BIP141 via mandatory signalling
ASAP(likely using bit 4)
2. Develop HF code based on assumption that BIP141 is active so that
you only have to test the BIP141->HF upgrade/activation codepath.
3. Deploy HF after BIP141 lock in(bit 4 can be reused again here since
this will be after BIP91 expiration)
When rolling out some features it often makes sense to combine them
into a single fork for example BIP's 68, 112, 113 were rolled out at
the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF
has required features that would conflict with with features in the
segwit rollout which is why attempting to simultaneously deploy them
would cause major complexity/testing issues(you would have to deal
with feature conflict resolution for multiple potential activation
scenarios). By doing a staged rollout of segwit and then a HF you get
a single testable upgrade path.
Based on past development experiences I wouldn't expect a 6 month
timeline to be realistic for a properly tested HF, but this proposed
upgrade path should be the fastest available for both SegWit and a HF
regardless.
On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Just to clarify one thing, what I described differs from BIP91 in that
> there's no orphaning. Just when Segwit2MB support reaches 80%, those 80%
> join everyone else in signaling for BIP141. BIP91 orphaning is an optional
> addition but my guess is it wouldn't be needed.
>
>
> On May 26, 2017 4:02 PM, "Matt Corallo" <lf-lists at mattcorallo.com> wrote:
>>
>> 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
>> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 18:01:24
in reply to nevent1q…5f7n
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 18:01:24Event JSON
{
"id": "e2c2861e93eac814694842125ac2528fb1c3740df674c83e37bf007a8a2e0307",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160884,
"kind": 1,
"tags": [
[
"e",
"5f4e5578a00516f73144a00c0c15e1afca8ff6c2e2a719034eb27cdcba62a8d3",
"",
"root"
],
[
"e",
"476029df4f7bc32f57bcbc1b40c5b8d9c31e472c78b7740af3cb9a3c9e658e2f",
"",
"reply"
],
[
"p",
"dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b"
]
],
"content": "📅 Original date posted:2017-05-26\n📝 Original message:Mandatory signalling is the only way to lock in segwit with less than\n95% hashpower without a full redeployment(which for a number of\ntechnical reasons isn't feasible until after the existing segwit\ndeployment expires). There's no reason not to signal BIP141 bit 1\nwhile also signalling bit 4, but you would want to use bit 4 to\ncoordinate bit 1 mandatory signalling.\n\nIt would not be feasible to schedule any HF until one can be\ncompletely sure BIP141 is active(at least not without waiting for the\ntimeout and doing a redeployment) due to activation/p2p codepath\ncomplexity. This is why the mandatory signalling period is needed.\n\nSince it is likely a HF will take months of development and testing I\nsee this or something similar as the fastest safe path forward:\n1. Use BIP91 or similar to activate BIP141 via mandatory signalling\nASAP(likely using bit 4)\n2. Develop HF code based on assumption that BIP141 is active so that\nyou only have to test the BIP141-\u003eHF upgrade/activation codepath.\n3. Deploy HF after BIP141 lock in(bit 4 can be reused again here since\nthis will be after BIP91 expiration)\n\nWhen rolling out some features it often makes sense to combine them\ninto a single fork for example BIP's 68, 112, 113 were rolled out at\nthe same time as are BIP's 141, 143, 144, 145 for segwit, however a HF\nhas required features that would conflict with with features in the\nsegwit rollout which is why attempting to simultaneously deploy them\nwould cause major complexity/testing issues(you would have to deal\nwith feature conflict resolution for multiple potential activation\nscenarios). By doing a staged rollout of segwit and then a HF you get\na single testable upgrade path.\n\nBased on past development experiences I wouldn't expect a 6 month\ntimeline to be realistic for a properly tested HF, but this proposed\nupgrade path should be the fastest available for both SegWit and a HF\nregardless.\n\nOn Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Just to clarify one thing, what I described differs from BIP91 in that\n\u003e there's no orphaning. Just when Segwit2MB support reaches 80%, those 80%\n\u003e join everyone else in signaling for BIP141. BIP91 orphaning is an optional\n\u003e addition but my guess is it wouldn't be needed.\n\u003e\n\u003e\n\u003e On May 26, 2017 4:02 PM, \"Matt Corallo\" \u003clf-lists at mattcorallo.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e Your proposal seems to be simply BIP 91 tied to the\n\u003e\u003e as-yet-entirely-undefined hard fork Barry et al proposed.\n\u003e\u003e\n\u003e\u003e Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as\n\u003e\u003e you propose, would make the deployment on the incredibly short timeline\n\u003e\u003e Barry et al proposed slightly more realistic, though I would expect to\n\u003e\u003e see hard fork code readily available and well-tested at this point in\n\u003e\u003e order to meet that timeline.\n\u003e\u003e\n\u003e\u003e Ultimately, due to their aggressive timeline, the Barry et al proposal\n\u003e\u003e is incredibly unlikely to meet the requirements of a\n\u003e\u003e multi-billion-dollar system, and continued research into meeting the\n\u003e\u003e spirit, not the text, of their agreement seems warranted.\n\u003e\u003e\n\u003e\u003e Matt\n\u003e\u003e\n\u003e\u003e On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:\n\u003e\u003e \u003e Forgive me if this is a dumb question. Suppose that rather than\n\u003e\u003e \u003e directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in\n\u003e\u003e \u003e just triggered BIP141 signaling (plus later HF). Would that avoid\n\u003e\u003e \u003e incompatibility with existing BIP141 nodes, and get segwit activated\n\u003e\u003e \u003e sooner? Eg:\n\u003e\u003e \u003e\n\u003e\u003e \u003e - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support\n\u003e\u003e \u003e for \"segwit now, HF (TBD) at scheduled date (Nov 23?)\"\n\u003e\u003e \u003e - If bit 4 support reaches 80%, it locks in two things: the scheduled HF\n\u003e\u003e \u003e (conditional on segwit), and *immediately* turning on bit 1 (BIP141\n\u003e\u003e \u003e support)\n\u003e\u003e \u003e\n\u003e\u003e \u003e I realize this would still leave problems like the aggressive HF\n\u003e\u003e \u003e schedule, possible chain split at the HF date between Segwit2MB nodes\n\u003e\u003e \u003e and any remaining BIP141 nodes, etc. My focus here is how\n\u003e\u003e \u003e incompatibility with existing nodes could be minimized.\n\u003e\u003e \u003e\n\u003e\u003e \u003e (BIP91 could also be used if BIP141 support still fell short of 95%.\n\u003e\u003e \u003e But if Segwit2MB support reaches 80%, it seems likely that an additional\n\u003e\u003e \u003e 15% will support BIP141-without-HF.)\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e\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": "9400fc23967cde08c96f3981295d4f069bef874c5fe6968187eef5ec4a6b7c6fb01ef9d719771a67c232e92d1a976615d8ecd51e630f7ba143484dffb60f2f27"
}