Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-06 📝 Original message:Replies inline. Several ...
📅 Original date posted:2021-03-06
📝 Original message:Replies inline. Several sections removed, where I basically agree.
On 3/4/21 08:47, Russell O'Connor wrote:
> Appologies as I've rearranged your comments in my reply.
> 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.
Hmm, while this is certainly true at a technical level, it adds a lot of complexity both in terms of discussion, and for
users - "I already upgraded to Taproot, why did I just see a fork with an invalid Taproot spend?".
> 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.
This is indeed a significant improvement over BIP 8 in my opinion. However, as I pointed out on a Reddit discussion with
Aaron, I'm still incredibly worried about users pushing for some UASF-style forced-signaling guerilla faster-activation.
It may absolutely be the case that Taproot activates quickly or that such users are a tiny minority of transacting.
However, as we saw with BIP 148/UASF, even a tiny minority of transacting users can set the tone and claim victory over
how a soft-fork activates. I worry that even your approach here runs the risk of yet further normalization of consensus
rule diversity on the network.
Maybe my worry is overblown, and I'm certainly not going to try to solely stand in the way on this one, but now that
we're stuck in yet another overblown debate, we might as well take it as an opportunity to reinforce the idea that
consensus rule diversity runs the risk of consensus failure, and isn't a reasonable risk.
>
> > 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.
Apologies. I should have phrased my comment better. My worry, at a broad level is that
(a) people have taken the events around the Segwit BIP 148 UASF to mean that a very small minority of users can (and
maybe should) push consensus rules through threats of breaking consensus and
(b) there is a very vocal group today which is reinforcing this belief by ignoring the complex context around Segwit and
behaving similarly with regards to Taproot.
Indeed, there is nothing we can, or should, do to actively prevent people from running their own software which
interprets Bitcoin's consensus rules in...creative ways. But that isn't to say there is no use worrying about it. 95% of
Bitcoin users aren't aware that this debate is even happening. Of the remaining 5%, 90% haven't had the time to research
and think deeply enough to form an opinion. Our responsibility is to the 99.5% of users.
Sure, individuals running different consensus rules won't cause immediate harm to others, but the net effect of many
users doing so and especially the community normalizing such behavior very significantly can. Ill-informed transactors
running such software (including wallet providers with users who were unaware of the events) can be screwed out of their
Bitcoin. This outcome very well could have occurred in the case of the BIP 148 UASF, and repeating the same pattern many
times will not help to de-risk that.
> 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.
Indeed. The obvious most conservative action is not activating Taproot at all. Obviously this is unlikely to solve the
issue :).
> 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.
Potentially indeed. Though I'm not so sure that several months represents a period that is not "hijackable", given the
speed at which someone can hack together naive activation code.
> 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.
Indeed, I've always suggested a miner activation window first to "learn something" about the state of it. However, I do
think we've passed the point where that should be a chief concern. The strength and diversity of public statements in
support of Taproot as a change to the network is rather overwhelming.
> 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.
I agree :).
📝 Original message:Replies inline. Several sections removed, where I basically agree.
On 3/4/21 08:47, Russell O'Connor wrote:
> Appologies as I've rearranged your comments in my reply.
> 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.
Hmm, while this is certainly true at a technical level, it adds a lot of complexity both in terms of discussion, and for
users - "I already upgraded to Taproot, why did I just see a fork with an invalid Taproot spend?".
> 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.
This is indeed a significant improvement over BIP 8 in my opinion. However, as I pointed out on a Reddit discussion with
Aaron, I'm still incredibly worried about users pushing for some UASF-style forced-signaling guerilla faster-activation.
It may absolutely be the case that Taproot activates quickly or that such users are a tiny minority of transacting.
However, as we saw with BIP 148/UASF, even a tiny minority of transacting users can set the tone and claim victory over
how a soft-fork activates. I worry that even your approach here runs the risk of yet further normalization of consensus
rule diversity on the network.
Maybe my worry is overblown, and I'm certainly not going to try to solely stand in the way on this one, but now that
we're stuck in yet another overblown debate, we might as well take it as an opportunity to reinforce the idea that
consensus rule diversity runs the risk of consensus failure, and isn't a reasonable risk.
>
> > 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.
Apologies. I should have phrased my comment better. My worry, at a broad level is that
(a) people have taken the events around the Segwit BIP 148 UASF to mean that a very small minority of users can (and
maybe should) push consensus rules through threats of breaking consensus and
(b) there is a very vocal group today which is reinforcing this belief by ignoring the complex context around Segwit and
behaving similarly with regards to Taproot.
Indeed, there is nothing we can, or should, do to actively prevent people from running their own software which
interprets Bitcoin's consensus rules in...creative ways. But that isn't to say there is no use worrying about it. 95% of
Bitcoin users aren't aware that this debate is even happening. Of the remaining 5%, 90% haven't had the time to research
and think deeply enough to form an opinion. Our responsibility is to the 99.5% of users.
Sure, individuals running different consensus rules won't cause immediate harm to others, but the net effect of many
users doing so and especially the community normalizing such behavior very significantly can. Ill-informed transactors
running such software (including wallet providers with users who were unaware of the events) can be screwed out of their
Bitcoin. This outcome very well could have occurred in the case of the BIP 148 UASF, and repeating the same pattern many
times will not help to de-risk that.
> 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.
Indeed. The obvious most conservative action is not activating Taproot at all. Obviously this is unlikely to solve the
issue :).
> 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.
Potentially indeed. Though I'm not so sure that several months represents a period that is not "hijackable", given the
speed at which someone can hack together naive activation code.
> 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.
Indeed, I've always suggested a miner activation window first to "learn something" about the state of it. However, I do
think we've passed the point where that should be a chief concern. The strength and diversity of public statements in
support of Taproot as a change to the network is rather overwhelming.
> 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.
I agree :).