Barry Silbert segwit agreement
9 messages, 26 to 28 May 2017. Started by Jacob Eliosoff.
Tom Zander (3), Jacob Eliosoff (2), Matt Corallo (2), James Hilliard (2)
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.)
On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote:
Quoted text (1 line)
> Forgive me if this is a dumb question.
Sorry for picking your email.
I understand people want something different for the agreement, I know I do too. We have a specific agreement on the table, signed by a huge subsection of the industry.
Maybe the time for changing things is not to be *after* the signatures are set. I know I’d change some detials. But do we really want to go through another conference where all the important people are present to agree on a compromise? Or can we use the one we have?
The compromise is pretty simple; https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
* Activate Segregated Witness at an 80% threshold, signaling at bit 4 * Activate a 2 MB hard fork within six months
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:
Quoted text (26 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
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@mattcorallo•com> wrote:
Quoted text (45 lines)
> 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@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >
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@lists•linuxfoundation•org> wrote:
Quoted text (59 lines)
> 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@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@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote:
Quoted text (2 lines)
> It would not be feasible to schedule any HF until one can be > completely sure BIP141 is active
why?
Quoted text (2 lines)
> 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
This should not be an issue, it started 2 years ago. Its tested.
While I'm not 100% convinced there are strict technical reasons for needing to wait till after segwit is active before a hard fork can be started (you can, after all, activate segwit as a part of the HF), there are useful design and conservatism reasons (not causing massive discontinuity in fee market, handling major system changes one at a time, etc).
Still, totally agree that attempting to design, code, and test a new hard fork in six months, let alone deploy it, let alone simultaneously with segwit, is a joke and fails to take seriously the investment many have made in the bitcoin system. Previous, rather simple, soft forks required similar if not more development time, not counting deployment and activation time.
If the community is unable to form consensus around segwit alone for political reasons, further research into hard fork design may help, but even forks tied together would nearly certainly need to activate months apart.
On May 26, 2017 5:30:37 PM EDT, James Hilliard <james.hilliard1@gmail•com> wrote:
Quoted text (114 lines)
>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@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@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@lists•linuxfoundation•org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> > >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>
On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
Quoted text (7 lines)
> > why? > > the main > issue is due to 0.13.1+ having many segwit related features active > already, including all the P2P components, the new network service > flag, the witness-tx and block messages, compact blocks v2 and > preferential peering.
Hmm, the flags are identical in 0.13 and 0.14 clients.
Either way, this is rather trivial to solve. If bugs in older clients mean they can’t operate properly when SW is activated (via bit 4) but they don’t know its activated (since they only look at bit1), then just ban them when they misbehave. And tell people to upgrade to a version where SegWit is less buggy.
Quoted text (6 lines)
> You would have to then have multiple activation > codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF > etc. By doing BIP141 first you then only have the BIP141(active)->HF > activation codepath to test for, and you also can't be sure you can > rely on BIP141(inactive)->HF activation codepath being the only one > until segwit activation expires.
Heh, well, this is rather simple to solve by not having all those activation codepaths and just picking **one**.
You can safely replace the bit1 activation code with a bit4 activation logic, which is based on 80% and has no end-date. We both know that the bip9 (bit1) based activation will not trigger before the expiration date anyway.
These worries are rather trivial to solve if you do a little bit of proper architecture of the solution. This honestly can’t be a reason for saying NO to the majority of the mining hash power giving you a break and offering a better SegWit activation.
On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (16 lines)
> On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote: >> > why? >> >> the main >> issue is due to 0.13.1+ having many segwit related features active >> already, including all the P2P components, the new network service >> flag, the witness-tx and block messages, compact blocks v2 and >> preferential peering. > > Hmm, the flags are identical in 0.13 and 0.14 clients. > > Either way, this is rather trivial to solve. If bugs in older clients mean > they can’t operate properly when SW is activated (via bit 4) but they don’t > know its activated (since they only look at bit1), then just ban them when > they misbehave. > And tell people to upgrade to a version where SegWit is less buggy.
That would partition off those clients, which is not something we would want to happen.
Quoted text (10 lines)
> >> You would have to then have multiple activation >> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF >> etc. By doing BIP141 first you then only have the BIP141(active)->HF >> activation codepath to test for, and you also can't be sure you can >> rely on BIP141(inactive)->HF activation codepath being the only one >> until segwit activation expires. > > Heh, well, this is rather simple to solve by not having all those activation > codepaths and just picking **one**.
This isn't possible until either BIP141 segwit is active or BIP141 segwit has expired.
Quoted text (5 lines)
> > You can safely replace the bit1 activation code with a bit4 activation > logic, which is based on 80% and has no end-date. > We both know that the bip9 (bit1) based activation will not trigger before > the expiration date anyway.
We don't know that since bip9 bit1 only needs 55% hashpower to be triggered(see BIP91 activation method for how this can be done)
Quoted text (5 lines)
> > These worries are rather trivial to solve if you do a little bit of proper > architecture of the solution. This honestly can’t be a reason for saying NO > to the majority of the mining hash power giving you a break and offering a > better SegWit activation.
BIP91 activation is clearly superior than trying to fully redeploy, it is far simpler and can be done almost immediately with only miners needing to upgrade.
Quoted text (9 lines)
> > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev