From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3DE2AC0001 for ; Sun, 28 Feb 2021 20:25:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with UTF8SMTP id 167F96062C for ; Sun, 28 Feb 2021 20:25:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=mattcorallo.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with UTF8SMTP id ACEqKN2kDwBF for ; Sun, 28 Feb 2021 20:25:19 +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 smtp3.osuosl.org (Postfix) with UTF8SMTPS id B240560622 for ; Sun, 28 Feb 2021 20:25:18 +0000 (UTC) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 4F77A4BE3B3; Sun, 28 Feb 2021 20:25:15 +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=1614543915; bh=ae4V2CGlO5SLh5Reed/3ZLnn1FuZukPqbDV9UsfWY+s=; h=Date:Subject:To:References:From:In-Reply-To:From; b=uHZehjkenpuruXsAxiwneaibB6NNhoae+TDDUglpNTfhHEyGgnIaRU9HgFgK8aKJb uPzwp80PneMcWxQTe1vNkMRRokRNYwyV2l3DLbRpxOI+Siqj4YqKMAZQB6iWbNV9gP j8QmOEEu0OEvNSPNxPDvzZO6kmy6aRDKCA1SpYb7wccWKCWsD9Ou0yi1av3DzzBinE XzANa+KFwrDD3o1C/dtaaYeWYFjk3YDIyIY4ktaF6l91DQiDHJTe1vyg+1P0+j4C07 q+myYvK5RW79XA4hleDWngxJZ4dLuJBhPxqEZgDeavd5RU9HDmAnBMyIvCBQmUKmgV JjAk9szwb6R+w== Message-ID: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com> Date: Sun, 28 Feb 2021 15:25:15 -0500 MIME-Version: 1.0 Content-Language: en-US To: Eric Voskuil , Jeremy , Bitcoin Protocol Discussion References: From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:25:20 -0000 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 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 >> >> > >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev