[bitcoin-dev] Barry Silbert segwit agreement

[shaolinfry via bitcoin-dev]

Someone sent me a copy of the Barry Silbert agreement, an agreement forged between a select number of participants https://pastebin.com/VuCYteJh

Participants agree to immediately activate Segwit, however, under a different activation proposal. Since I have spent the last few months researching various activation strategies of the current BIP141 deployment, as well as redeployment, I feel I am quite well placed to comment on the technicalities.

To be clear, the proposal as far as I can see does not activate BIP141, but is a completely new deployment which would be incompatible with the BIP141 deployment. I'm not sure how that can be considered "immediate" activation. Surely immediate activation would just be for miners to start signalling and segwit would be activated in 4-5 weeks. The proposal seems to require a lower 80% threshold, I assume because they were unable to convince 95% of the hashpower to go trigger activation.

There are a few options to activating segwit now, the first being for 95% of hashrate to signal. The second is for the community to deploy BIP148 UASF which will force miners to signal segwit. Being a UASF it is date triggered. The third option is a redeployment of segwit on a new bit, but requires waiting for the existing deployment to time out, because all the p2p messages and service bits related to segwit must be replaced too (which is what BIP149 does).

A fourth option, first suggested to me by James Hilliard, was to make BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded this up a few weeks ago https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal but didnt get around to posting to the ML yet. This effectively lowers the threshold from 95% to 65% as coded, or could be upped to 80% or whatever was preferable.

I think this removes the primary risk of BIP148 causing the creation of two chains, and gives an improved chance to get segwit activated quickly (assuming a majority of miners wish to go this route). But hash a primary disadvantage of still leaving the activation in the hands of miners. If it doesn't work out, then BIP149 can then be used as proposed, but it'll be even safer because we'll have futher guaged support.

References:

SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal
BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki

I think the Barry Silbert agreement is very ill considered, and clearly lacking peer review from the technical community. Suggestions of a HF in 4 months are completely unrealistic and without technical merits. But more importantly, closed door agreements between selected participants is not how to garner consensus to change a $30bn decentralized system. The purpose of my email is to try and assist in the "immediate activation of segwit" which only requires hashrate to participate; and to provide some techincal input since I have done a great deal of research and development into the topic.

Given the history we've already passed the point where we should be expecting miners to cooperate in lowering their own fee income with a capacity increase; but we should be open to all reasonable options in the interest in moving things forward in a safe and collaborative way.

[Peter Todd via bitcoin-dev]

Post by shaolinfry via bitcoin-dev
Someone sent me a copy of the Barry Silbert agreement, an agreement forged between a select number of participants https://pastebin.com/VuCYteJh

It's interesting how changing the bit used to signal could be used as a way to
try to trick people into changing node software ASAP to support the hard-fork
code. Basically, the narrative would be that other software *doesn't* support
segwit, so you have to upgrade right away.

Post by shaolinfry via bitcoin-dev
A fourth option, first suggested to me by James Hilliard, was to make BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded this up a few weeks ago https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal but didnt get around to posting to the ML yet. This effectively lowers the threshold from 95% to 65% as coded, or could be upped to 80% or whatever was preferable.

In contrast this proposal wouldn't have that effect, because as you point out
it's compatibel with the existing segwit protocol once activated.

Smells like political engineering to me.

[Hampus Sjöberg via bitcoin-dev]

I'm really happy to see people trying to cooperate to get SegWit activated.
But I'm really unsure about the technicalities about Silbert's proposal.

If we're going to do a hardfork, it makes most sense to assist Johnson in
his spoonnet/forcenet proposals.
Just doing a simple 2MB without fixing anything else is very uninteresting,
and a hardfork without addressing replay protection seems really
unprofessional to me.
And proposing a hardfork in 4 months in the future, is completely insane.
You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months.

I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
September 2018, or 2019 (together with forcenet/spoonnet).
And if not, BIP148 is gaining momentum once again so that sounds much more
interesting.

Hampus

2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <

Post by shaolinfry via bitcoin-dev
Someone sent me a copy of the Barry Silbert agreement, an agreement forged
between a select number of participants https://pastebin.com/VuCYteJh
Participants agree to immediately activate Segwit, however, under a
different activation proposal. Since I have spent the last few months
researching various activation strategies of the current BIP141 deployment,
as well as redeployment, I feel I am quite well placed to comment on the
technicalities.
To be clear, the proposal as far as I can see does not activate BIP141,
but is a completely new deployment which would be incompatible with the
BIP141 deployment. I'm not sure how that can be considered "immediate"
activation. Surely immediate activation would just be for miners to start
signalling and segwit would be activated in 4-5 weeks. The proposal seems
to require a lower 80% threshold, I assume because they were unable to
convince 95% of the hashpower to go trigger activation.
There are a few options to activating segwit now, the first being for 95%
of hashrate to signal. The second is for the community to deploy BIP148
UASF which will force miners to signal segwit. Being a UASF it is date
triggered. The third option is a redeployment of segwit on a new bit, but
requires waiting for the existing deployment to time out, because all the
p2p messages and service bits related to segwit must be replaced too (which
is what BIP149 does).
A fourth option, first suggested to me by James Hilliard, was to make
BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
this up a few weeks ago https://github.com/bitcoin/
bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
posting to the ML yet. This effectively lowers the threshold from 95% to
65% as coded, or could be upped to 80% or whatever was preferable.
I think this removes the primary risk of BIP148 causing the creation of
two chains, and gives an improved chance to get segwit activated quickly
(assuming a majority of miners wish to go this route). But hash a primary
disadvantage of still leaving the activation in the hands of miners. If it
doesn't work out, then BIP149 can then be used as proposed, but it'll be
even safer because we'll have futher guaged support.
SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
shaolinfry:segsignal
BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
I think the Barry Silbert agreement is very ill considered, and clearly
lacking peer review from the technical community. Suggestions of a HF in 4
months are completely unrealistic and without technical merits. But more
importantly, closed door agreements between selected participants is not
how to garner consensus to change a $30bn decentralized system. The purpose
of my email is to try and assist in the "immediate activation of segwit"
which only requires hashrate to participate; and to provide some techincal
input since I have done a great deal of research and development into the
topic.
Given the history we've already passed the point where we should be
expecting miners to cooperate in lowering their own fee income with a
capacity increase; but we should be open to all reasonable options in the
interest in moving things forward in a safe and collaborative way.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniele Pinna via bitcoin-dev]

I couldn't agree more. It would require however for the Devs to throw their
weight behind this with a lot of momentum. Spoonnet has been under
development for quite some time now. Counter offering SegWit plus Spoonnet
12-24 months later would be a very progressive stance that I think would
catch the interest of large swaths of the community. I'd be curious to hear
Johnson's opinion on this. How much more testing would his proposal require?

Daniele


----------------------------------------------------------------------

Message: 1
Date: Mon, 22 May 2017 11:23:22 +0200
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
<CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_
Content-Type: text/plain; charset="utf-8"
I'm really happy to see people trying to cooperate to get SegWit activated.
But I'm really unsure about the technicalities about Silbert's proposal.
If we're going to do a hardfork, it makes most sense to assist Johnson in
his spoonnet/forcenet proposals.
Just doing a simple 2MB without fixing anything else is very uninteresting,
and a hardfork without addressing replay protection seems really
unprofessional to me.
And proposing a hardfork in 4 months in the future, is completely insane.
You cannot expect a 100% of all nodes in P2P network to upgrade in 4
months.
I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
September 2018, or 2019 (together with forcenet/spoonnet).
And if not, BIP148 is gaining momentum once again so that sounds much more
interesting.
Hampus
2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <

Post by shaolinfry via bitcoin-dev
Someone sent me a copy of the Barry Silbert agreement, an agreement

forged

Post by shaolinfry via bitcoin-dev
between a select number of participants https://pastebin.com/VuCYteJh
Participants agree to immediately activate Segwit, however, under a
different activation proposal. Since I have spent the last few months
researching various activation strategies of the current BIP141

deployment,

Post by shaolinfry via bitcoin-dev
as well as redeployment, I feel I am quite well placed to comment on the
technicalities.
To be clear, the proposal as far as I can see does not activate BIP141,
but is a completely new deployment which would be incompatible with the
BIP141 deployment. I'm not sure how that can be considered "immediate"
activation. Surely immediate activation would just be for miners to start
signalling and segwit would be activated in 4-5 weeks. The proposal seems
to require a lower 80% threshold, I assume because they were unable to
convince 95% of the hashpower to go trigger activation.
There are a few options to activating segwit now, the first being for 95%
of hashrate to signal. The second is for the community to deploy BIP148
UASF which will force miners to signal segwit. Being a UASF it is date
triggered. The third option is a redeployment of segwit on a new bit, but
requires waiting for the existing deployment to time out, because all the
p2p messages and service bits related to segwit must be replaced too

(which

Post by shaolinfry via bitcoin-dev
is what BIP149 does).
A fourth option, first suggested to me by James Hilliard, was to make
BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
this up a few weeks ago https://github.com/bitcoin/
bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
posting to the ML yet. This effectively lowers the threshold from 95% to
65% as coded, or could be upped to 80% or whatever was preferable.
I think this removes the primary risk of BIP148 causing the creation of
two chains, and gives an improved chance to get segwit activated quickly
(assuming a majority of miners wish to go this route). But hash a primary
disadvantage of still leaving the activation in the hands of miners. If

it

Post by shaolinfry via bitcoin-dev
doesn't work out, then BIP149 can then be used as proposed, but it'll be
even safer because we'll have futher guaged support.
SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
shaolinfry:segsignal
BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
I think the Barry Silbert agreement is very ill considered, and clearly
lacking peer review from the technical community. Suggestions of a HF in

4

Post by shaolinfry via bitcoin-dev
months are completely unrealistic and without technical merits. But more
importantly, closed door agreements between selected participants is not
how to garner consensus to change a $30bn decentralized system. The

purpose

Post by shaolinfry via bitcoin-dev
of my email is to try and assist in the "immediate activation of segwit"
which only requires hashrate to participate; and to provide some

techincal

Post by shaolinfry via bitcoin-dev
input since I have done a great deal of research and development into the
topic.
Given the history we've already passed the point where we should be
expecting miners to cooperate in lowering their own fee income with a
capacity increase; but we should be open to all reasonable options in the
interest in moving things forward in a safe and collaborative way.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tom Zander via bitcoin-dev]

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

[Matt Corallo via bitcoin-dev]

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

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
- 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[James Hilliard via 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

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.

Post by Matt Corallo via bitcoin-dev
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

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
- 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tom Zander via bitcoin-dev]

Post by James Hilliard via bitcoin-dev
It would not be feasible to schedule any HF until one can be
completely sure BIP141 is active

why?

Post by James Hilliard via bitcoin-dev
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.

[Tom Zander via bitcoin-dev]

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.

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.

[James Hilliard via bitcoin-dev]

On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev

Post by Tom Zander via bitcoin-dev

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.

Post by Tom Zander via bitcoin-dev

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.

Post by Tom Zander via bitcoin-dev
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)

Post by Tom Zander via bitcoin-dev
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.

Post by Tom Zander via bitcoin-dev
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Matt Corallo via bitcoin-dev]

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.

Post by James Hilliard via 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
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

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.

Post by Matt Corallo via bitcoin-dev
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

Post by Matt Corallo via bitcoin-dev
you propose, would make the deployment on the incredibly short

timeline

Post by Matt Corallo via bitcoin-dev
Barry et al proposed slightly more realistic, though I would expect

to

Post by Matt Corallo via bitcoin-dev
see hard fork code readily available and well-tested at this point

in

Post by Matt Corallo via bitcoin-dev
order to meet that timeline.
Ultimately, due to their aggressive timeline, the Barry et al

proposal

Post by Matt Corallo via bitcoin-dev
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

Forgive me if this is a dumb question. Suppose that rather than
directly activating segwit, the Silbert/NYC Segwit2MB proposal's

lock-in

Post by Matt Corallo via bitcoin-dev

just triggered BIP141 signaling (plus later HF). Would that avoid
incompatibility with existing BIP141 nodes, and get segwit

activated

Post by Matt Corallo via bitcoin-dev

- Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals

support

Post by Matt Corallo via bitcoin-dev

for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
- If bit 4 support reaches 80%, it locks in two things: the

scheduled HF

Post by Matt Corallo via bitcoin-dev

(conditional on segwit), and *immediately* turning on bit 1

(BIP141

Post by Matt Corallo via bitcoin-dev

support)
I realize this would still leave problems like the aggressive HF
schedule, possible chain split at the HF date between Segwit2MB

nodes

Post by Matt Corallo via bitcoin-dev

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%.

Post by Matt Corallo via bitcoin-dev

But if Segwit2MB support reaches 80%, it seems likely that an

additional

Post by Matt Corallo via bitcoin-dev

15% will support BIP141-without-HF.)
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev