From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9B199C0001 for ; Sun, 28 Feb 2021 20:21:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with UTF8SMTP id 897104EBF3 for ; Sun, 28 Feb 2021 20:21:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=mattcorallo.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with UTF8SMTP id jkILxJv8DeR5 for ; Sun, 28 Feb 2021 20:20:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp4.osuosl.org (Postfix) with UTF8SMTPS id 9B29A4EB76 for ; Sun, 28 Feb 2021 20:20:58 +0000 (UTC) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 98CEA4BE347; Sun, 28 Feb 2021 20:20:56 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1614542463; t=1614543656; bh=cFFaR3grN62e0kiINabfVJyP2b2BcX2yYtbOApIt/Ko=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=caIFmORuTdm5DzVthoEWRu1Uu5CEt4fiGElr/Jy+lFR9UOshBneOPAZxBOWwtSJu3 KqF92n/NYp/mZ8NIwcPxKHxRmh2tH6SvXzxb29AJV7kR3ixQ8fHHQ9A8+ERlfI2Ae4 gzx7HItxXjsrQusse5JLjbCPUWPSd7k52nYA3qJIkjtRerR9DqQGeItt/Sx/+p3b4i hqh/DumpqtRUBg+CYxptVWgwdFSE8CymcRKtWN/IfKK0xRiv/LZ9QmrrFP5Vj/jjD/ qTLjT39D+wEC86N0KYpR+/zmAc+Pg9awWXFM1xXnrZnoPdzbGX4wqtqaE8LC+Noweb /9VgTsz61uK7w== 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 References: <202102281720.07392.luke@dashjr.org> <20c5eb39-915d-6af9-5b0a-f488ff40ef3f@mattcorallo.com> From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 20:21:00 -0000 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 > > > On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo > 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 > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > >