Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo <lf-lists@mattcorallo.com>]

Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically 
addressed each of in the OP of this thread.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

On 2/28/21 15:19, Eric Voskuil wrote:
> In the attempt to change consensus rules there is a simple set of choices:
> 
> 1) hard fork: creates a chain split
> 2) soft fork: creates a chain split
> 3) 51% attack: does not create a chain split
> 
> The presumption being that one can never assume 100% explicit adoption of any rule change.
> 
> A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some 
> level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than 
> majority threshold, as has been done in the past.
> 
> Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine 
> and/or accept bitcoin - nobody is in charge.
> 
> The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. 
> No power is given to them by developers or anyone else. They have that power based on their own capital invested.
> 
> Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level 
> of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is 
> possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
> 
> But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If 
> there is some other objective, it’s not clear to me what it is.
> 
> e
> 
>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 
>> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block 
>> enhanced selfish mining" to take advantage of it.
>>
>>
>> Hard to analyze exactly what that looks like, but...
>>
>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the 
>> time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze 
>> out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this 
>> for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving 
>> themselves a larger % of hashrate.
>>
>> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners 
>> leads to some nasty oscillating hashrate being optimal.
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>>
>>
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-lists@mattcorallo.com>> wrote:
>>
>>     Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running
>>     Bitcoin
>>     Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3)
>>     from
>>     my original post - it results in any miner who has not taken active action (and ensured every part of their
>>     often-large
>>     infrastructure has been correctly reconfigured) generating invalid blocks.
>>
>>     As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>>     already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>
>>     Matt
>>
>>     On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>     > I agree with much of the logic presented by Matt here.
>>     >
>>     > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
>>     "tiny"
>>     > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a
>>     concept
>>     > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>>     > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>>     > should do and when.
>>     >
>>     > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on
>>     its own,
>>     > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain
>>     date are
>>     > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
>>     cooptable
>>     > consensus process than something more straightforward.
>>     >
>>     >
>>     > That said, a few points strike me as worth delving into.
>>     >
>>     >
>>     > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
>>     one for
>>     > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and
>>     flag day
>>     > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
>>     mining
>>     > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>>     > ensure the tip is valid).
>>     > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
>>     would
>>     > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
>>     LOT=true
>>     > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>>     > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
>>     is/was
>>     > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
>>     schedules,
>>     > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
>>     quantized
>>     > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>>     > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
>>     signaling does
>>     > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
>>     start
>>     > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
>>     secondary
>>     > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>>     > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
>>     reward). So I
>>     > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard
>>     fork if
>>     > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>>     > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>>     > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
>>     flag
>>     > day, to do that via LOT=true so that taproot can still have early activation if desired.
>>     >
>>     > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>>     > closer to a flag day might not be so bad either for future forks as well.
>>     >
>>     > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
>>     option
>>     > at this time as it allows our flag day to remain compatible with such an early activation.
>>     >
>>     > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
>>     future
>>     > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>>     > parameters).
>>     >
>>     >
>>     > _______________________________________________
>>     > bitcoin-dev mailing list
>>     > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>     <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