Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-04 📝 Original message:Appologies as I've ...
📅 Original date posted:2021-03-04
📝 Original message:Appologies as I've rearranged your comments in my reply.
On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
>
> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>
> After a normal and successful Core update with LOT=false, we will have
> more data showing broad community support for the
> > taproot upgrade in hand.
>
> I think this is one of the strongest arguments against a flag day
> activation, but, as I described in more detail in the
> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
> aren't there enough already.
>
I agree with you. I also think we have plenty of evidence to proceed with
taproot and could proceed with a PR for such a flag day activation. If
there is support for it to be merged, that would be fantastic. I think we
should proceed along these lines forthwith.
However, the existence and/or release of a flag day activation code does
not in of itself preclude concurrently developing and/or releasing a BIP8
LOT=false deployment. Activating taproot is "idempotent" after all. We
could even do a Core release with a flag day activation while we continue
to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having
a flag day activation code merged would take a lot of pressure off further
BIP8 LOT=false work.
As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state,
then running BIP8 LOT=false alongside a flag day activation at timeout may
be the way to go. Once a flag day deployment is released, the LOT=true
people would have their guaranteed activation and would be less interested
in an alternative client. And without a MUST_SIGNAL state, I believe the
LOT=false deployment won't lead any hashpower that is following
standardness rules to create invalid blocks.
> > In the next release, 6 months later or so, Core could then confidently
> deploy a BIP8 LOT=true
>
> Could you clarify what an acceptable timeline is, then? Six months from
> release of new consensus rules to activation (in
> the case of a one-year original window) seems incredibly agressive for a
> flag-day activation, let alone one with
> forced-signaling, which would require significantly higher level of
> adoption to avoid network split risk. In such a
> world, we'd probably get Taproot faster with a flag day from day one.
>
Whatever timeline people are in favour of. I think having a year or more
between the LOT=true or flag day more and the anticipated second release
date is fair myself.
That would suggest a 2-year timeout from the start to give plenty of room.
Of course, if we start with a flag day from the start then we can just do 1
year and we don't need a second deployment.
We could also do a "Let’s see what happens" with a short 3 or 4-month
deployment and still do a follow up activation if that is more agreeable.
That would give a net of about 1.5 years or so because we don't need to
anticipate the second relase date.
I'm good with whatever, and I'm happy to make more concrete suggestions if
that is necessary. I think there exist acceptable timelines here.
> > client, should it prove to be necessary. A second Core deployment of
> LOT=true would mitigate some of the concerns with
> > LOT=false, but still provide a period beforehand to objective actions
> taken by the community in support of taproot. We
> > don't even have to have agreement today on a second deployment of
> LOT=true after 6 months to start the process of a
> > LOT=false deployment. The later deployment will almost certainly be
> moot, and we will have 6 months to spend debating
> > the LOT=true deployment versus doing a flag day activation or something
> else.
>
> That was precisely the original goal with the LOT=false movement - do
> something easy and avoid having to hash out all
> the technical details of a second deployment. Sadly, that's no longer
> tennable as a number of people are publicly
> committed to deploying LOT=true software on the network ASAP.
>
First things last:
> Even today, I still think that starting with BIP8 LOT=false is, generally
> speaking, considered a reasonably safe
> > activation method in the sense that I think it will be widely considered
> as a "not wholly unacceptable" approach to
> > activation.
>
> How do you propose avoiding divergent consensus rules on the network,
> something which a number of commentors on this
> list have publicly committed to?
>
Firstly, it is an open network. Anyone can join and run whatever consensus
rules they want. People have run divergent consensus rules on the network
in the past and it will continue to do so in the future.
It is troublesome when it happens in mass, but it isn't fatal. We can't
prevent it, and we should continue working to keep the protocol robust in
the face of it.
And we certainly shouldn't be bullied by anyone who comes threatening their
own soft-fork.
Even simply doing nothing may not prevent divergent consensus from
appearing on the network. Playing conservative isn't playing it safe
because there is nothing more conservative than doing nothing, which isn't
guaranteed to be safe in this sense.
Secondly, for the specific concern of people running BIP8 LOT=true clients,
we could start with "Let’s see what happens" with a short 3 or 4 month
signaling period. A short enough signaling period is not "hijackable". We
could add a longer LOCKED_IN period if there are worries about getting
enough nodes upgraded in time for activation. I see other options as well.
I keep being told that miners are ready and willing to activate, and
taproot will probably activate in two months. All we have to do is get
something out the door that does that. If taproot activates in two months,
great. If it fails to activate we will learn so much in so little time.
UASF's will get to say "I told you so" without waiting a year. Users will
get to take active, meaningful and observable steps to demonstrate their
desire for a taproot upgrade. Very little time will be wasted, in
particular we don't have to finish debating how best to handle the unlikely
scenario where taproot doesn't activate right away for whatever reason that
is, an scenario that isn't even likely to occur.
I'm still very optimistic. I see multiple plausible and potentially
acceptable paths towards activation still open and we don't even have to
choose only one. I can hardly wait to look at the forthcoming PRs for
these possibilities.
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/c752f684/attachment.html>;
📝 Original message:Appologies as I've rearranged your comments in my reply.
On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
>
> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>
> After a normal and successful Core update with LOT=false, we will have
> more data showing broad community support for the
> > taproot upgrade in hand.
>
> I think this is one of the strongest arguments against a flag day
> activation, but, as I described in more detail in the
> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
> aren't there enough already.
>
I agree with you. I also think we have plenty of evidence to proceed with
taproot and could proceed with a PR for such a flag day activation. If
there is support for it to be merged, that would be fantastic. I think we
should proceed along these lines forthwith.
However, the existence and/or release of a flag day activation code does
not in of itself preclude concurrently developing and/or releasing a BIP8
LOT=false deployment. Activating taproot is "idempotent" after all. We
could even do a Core release with a flag day activation while we continue
to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having
a flag day activation code merged would take a lot of pressure off further
BIP8 LOT=false work.
As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state,
then running BIP8 LOT=false alongside a flag day activation at timeout may
be the way to go. Once a flag day deployment is released, the LOT=true
people would have their guaranteed activation and would be less interested
in an alternative client. And without a MUST_SIGNAL state, I believe the
LOT=false deployment won't lead any hashpower that is following
standardness rules to create invalid blocks.
> > In the next release, 6 months later or so, Core could then confidently
> deploy a BIP8 LOT=true
>
> Could you clarify what an acceptable timeline is, then? Six months from
> release of new consensus rules to activation (in
> the case of a one-year original window) seems incredibly agressive for a
> flag-day activation, let alone one with
> forced-signaling, which would require significantly higher level of
> adoption to avoid network split risk. In such a
> world, we'd probably get Taproot faster with a flag day from day one.
>
Whatever timeline people are in favour of. I think having a year or more
between the LOT=true or flag day more and the anticipated second release
date is fair myself.
That would suggest a 2-year timeout from the start to give plenty of room.
Of course, if we start with a flag day from the start then we can just do 1
year and we don't need a second deployment.
We could also do a "Let’s see what happens" with a short 3 or 4-month
deployment and still do a follow up activation if that is more agreeable.
That would give a net of about 1.5 years or so because we don't need to
anticipate the second relase date.
I'm good with whatever, and I'm happy to make more concrete suggestions if
that is necessary. I think there exist acceptable timelines here.
> > client, should it prove to be necessary. A second Core deployment of
> LOT=true would mitigate some of the concerns with
> > LOT=false, but still provide a period beforehand to objective actions
> taken by the community in support of taproot. We
> > don't even have to have agreement today on a second deployment of
> LOT=true after 6 months to start the process of a
> > LOT=false deployment. The later deployment will almost certainly be
> moot, and we will have 6 months to spend debating
> > the LOT=true deployment versus doing a flag day activation or something
> else.
>
> That was precisely the original goal with the LOT=false movement - do
> something easy and avoid having to hash out all
> the technical details of a second deployment. Sadly, that's no longer
> tennable as a number of people are publicly
> committed to deploying LOT=true software on the network ASAP.
>
First things last:
> Even today, I still think that starting with BIP8 LOT=false is, generally
> speaking, considered a reasonably safe
> > activation method in the sense that I think it will be widely considered
> as a "not wholly unacceptable" approach to
> > activation.
>
> How do you propose avoiding divergent consensus rules on the network,
> something which a number of commentors on this
> list have publicly committed to?
>
Firstly, it is an open network. Anyone can join and run whatever consensus
rules they want. People have run divergent consensus rules on the network
in the past and it will continue to do so in the future.
It is troublesome when it happens in mass, but it isn't fatal. We can't
prevent it, and we should continue working to keep the protocol robust in
the face of it.
And we certainly shouldn't be bullied by anyone who comes threatening their
own soft-fork.
Even simply doing nothing may not prevent divergent consensus from
appearing on the network. Playing conservative isn't playing it safe
because there is nothing more conservative than doing nothing, which isn't
guaranteed to be safe in this sense.
Secondly, for the specific concern of people running BIP8 LOT=true clients,
we could start with "Let’s see what happens" with a short 3 or 4 month
signaling period. A short enough signaling period is not "hijackable". We
could add a longer LOCKED_IN period if there are worries about getting
enough nodes upgraded in time for activation. I see other options as well.
I keep being told that miners are ready and willing to activate, and
taproot will probably activate in two months. All we have to do is get
something out the door that does that. If taproot activates in two months,
great. If it fails to activate we will learn so much in so little time.
UASF's will get to say "I told you so" without waiting a year. Users will
get to take active, meaningful and observable steps to demonstrate their
desire for a taproot upgrade. Very little time will be wasted, in
particular we don't have to finish debating how best to handle the unlikely
scenario where taproot doesn't activate right away for whatever reason that
is, an scenario that isn't even likely to occur.
I'm still very optimistic. I see multiple plausible and potentially
acceptable paths towards activation still open and we don't even have to
choose only one. I can hardly wait to look at the forthcoming PRs for
these possibilities.
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/c752f684/attachment.html>;