Message-ID: <11b00a3a-91ff-54dd-6a48-b6f860dccfb6@mattcorallo.com>
Date: Sun, 28 Feb 2021 15:20:56 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Jeremy <jlrubin@mit.edu>
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
 <202102281720.07392.luke@dashjr.org>
 <c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com>
 <CAD5xwhhRCBa86B0ApZ=VioZngREOh1bth4H=zk69k4xsZc9d0Q@mail.gmail.com>
 <20c5eb39-915d-6af9-5b0a-f488ff40ef3f@mattcorallo.com>
 <CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Precedence: list

SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the 
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make 
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point - 
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only 
needs to forget to reconfigure one out of one hundred pool servers they operate.

Matt

On 2/28/21 15:02, Jeremy 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>
>      >
>