From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4682C0001 for ; Sun, 28 Feb 2021 20:45:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C31684300A for ; Sun, 28 Feb 2021 20:45:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI8Ww57pdF_s for ; Sun, 28 Feb 2021 20:45:48 +0000 (UTC) X-Greylist: delayed 00:07:34 by SQLgrey-1.8.0 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by smtp2.osuosl.org (Postfix) with ESMTPS id 98AE143006 for ; Sun, 28 Feb 2021 20:45:48 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id d12so7579093pfo.7 for ; Sun, 28 Feb 2021 12:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=2ipnH/H8biZlde67aT6GUyuvWu7nVFnRtGqhZWR5rYQ=; b=YUYX02l5Gh1Mj4gTAUgtDNYB3HWaRmE2vFushAHARfU6fOtxEn7iZT15ViYAl0x9PU 1zkXt5AnlKg9v177tDsv7xPakZcbtf1fWq6U8M4J3Sd/7BuQnBivoz0Lsph2WGSOAM67 uDWK8Fbz+R6s+ifNnDL4VpwEFl22cLDD2fewix8/2Zi3G+68eiuf3t68B7f5234g4qfj DQcsx8jyugF0sRVy1v0dBGRlamAtSu1Osi9HHgUQEkNriTLxkw7+x6dF/+OelJj1L15P rx566G2izQ09JQ00LCmxkLZPlzBJj40QsHMxdHKhtzl6McFv3mfzQa5PM/fYsvV+PnF/ pxeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=2ipnH/H8biZlde67aT6GUyuvWu7nVFnRtGqhZWR5rYQ=; b=p+VwjV3+/j9U1yOlU6BqOZRsjyq/9zFbvbcW0Jj3FP/lMbxHvdbara5enCkxgqIDhf PcnIqX6At/ijrnUDnnGr1yI80EdMzSBPZ51X2Ai/Dc9ikmwBcmDcCvsov1lu5cGiSQC2 ai1+9UKL65psdhQbgeTKiXTtjFYf+M1Fjm1xHmM2es4AHRZE96b5RiLRMAkblBZlm8wQ r1LgZ8KIM5DoIWO3ciT+VcmBCeLcbHhnYwN1RtMxNWvRJzkXR2bLL3p4+4/pk/eiKLMP yj3mvfdrMVwH74p0tR2tzwQkpMaFuoKU/Y+lAWoF4VboC+lsn07tV8P91TtdgMZGyrEN 15uw== X-Gm-Message-State: AOAM533A95ZOcGqDNkG7+h8nfIVTOBJdOqwnn5r8iJmf1qnMsbmhD8+P Tfh1JpkrQFHG7T57GwMS/B2xs6LZCaRzzWkD X-Google-Smtp-Source: ABdhPJylDBsiUyH1hlAUDy0UpZHOsNGomw0KZG4BkuC7OplYE7hLU7sz8tSuxRxKJqVwGnWVuaH41A== X-Received: by 2002:a63:fa4d:: with SMTP id g13mr10947981pgk.201.1614544693939; Sun, 28 Feb 2021 12:38:13 -0800 (PST) Received: from ?IPv6:2601:600:9c00:1d0::250e? ([2601:600:9c00:1d0::250e]) by smtp.gmail.com with ESMTPSA id m18sm16142248pfd.206.2021.02.28.12.38.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Feb 2021 12:38:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sun, 28 Feb 2021 12:38:13 -0800 Message-Id: References: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com> In-Reply-To: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com> To: Matt Corallo X-Mailer: iPhone Mail (18D52) X-Mailman-Approved-At: Sun, 28 Feb 2021 21:15:45 +0000 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:45:49 -0000 I think it has been shown that an understanding of reasonableness is not uni= versal, making any assertion about it as a collective goal kind of self-defe= ating. The question is what is achievable, not what is reasonable. I=E2=80=99= m not making any value judgements here. Simply pointing out that anything ot= her than a successful 51% attack will create a split. e > On Feb 28, 2021, at 12:25, Matt Corallo wrote: >=20 > =EF=BB=BFGlad you asked! Yes, your goal here is #4 on the list of goals I l= aid out at [1], which I referenced and specifically addressed each of in the= OP of this thread. >=20 > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0= 17547.html >=20 >> 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 b= e untruthful. But miner signaling provides some level of assurance that it w= ill be successful. This level of assurance is increased by adoption of a hig= her than majority threshold, as has been done in the past. >> Most of the discussion I=E2=80=99ve seen has been focused on who is in ch= arge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - n= obody is in charge. >> The majority of those who mine can choose to enforce censorship any time t= hey want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is g= iven to them by developers or anyone else. They have that power based on the= ir own capital invested. >> Similarly, the economy (those who accept bitcoin) can enforce any rule ch= ange it wants to. And it can do so at any level of participation that wants t= o go along. Anyone can do this, it requires nobody=E2=80=99s permission. Fur= thermore, 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 s= plit, 50% is a much lower bar than 100%. If there is some other objective, i= t=E2=80=99s not clear to me what it is. >> e >>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev wrote: >>>=20 >>> =EF=BB=BF >>> Miners still can generate invalid blocks as a result of SPV mining, and i= t could be profitable to do "bad block enhanced selfish mining" to take adva= ntage of it. >>>=20 >>>=20 >>> Hard to analyze exactly what that looks like, but... >>>=20 >>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrat= e to mine bad blocks would mean 1/4th of the time you could make 20% of the h= ashrate mine bad blocks, overall a > 5% (series expansion) benefit. One coul= d analyze out that the lost hash rate for bad blocks only matters for the fi= rst difficulty adjustment period you're doing this for too, as the hashrate d= rop will be accounted for -- but then a miner can switch back to mining vali= d chain, giving themselves a larger % of hashrate. >>>=20 >>> So it is still possible that an un-upgraded miner will fail part 3, and a= ttempting to accommodate un-upgraded miners leads to some nasty oscillating h= ashrate being optimal. >>>=20 >>>=20 >>> -- >>> @JeremyRubin >>>=20 >>>=20 >>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo > wrote: >>>=20 >>> Note further that mandatory signaling isn't "just" a flag day - unlik= e a Taproot flag day (where miners running >>> Bitcoin >>> Core unmodified today will not generate invalid blocks), a mandatory s= ignaling flag day blatantly ignores goal (3) >>> from >>> my original post - it results in any miner who has not taken active a= ction (and ensured every part of their >>> often-large >>> infrastructure has been correctly reconfigured) generating invalid bl= ocks. >>>=20 >>> 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. >>>=20 >>> Matt >>>=20 >>>> 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, y= et we find ourselves in a situation where a >>> "tiny" >>> > parameter has the potential to cause great network disruption and c= onfusion (rationality is not too useful a >>> concept >>> > here given differing levels of sophistication and information). It i= s therefore much simpler and more likely to be >>> > universally understood by all network participants to just have a f= lag day. It is easier to communicate what users >>> > should do and when. >>> > >>> > This is ultimately not coercive to users because the upgrade for Ta= proot itself is provable and analyzable on >>> its own, >>> > but activation parameters based on what % of economically relevant n= odes are running an upgrade by a certain >>> date are >>> > not. Selecting these sorts of complicated consensus parameters may u= ltimately 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. Manda= tory signaling is effectively 2 flag days -- >>> one for >>> > the signaling rule, 1 for the taproot type. The reason for the 2 we= ek gap between flag day for signaling and >>> flag day >>> > for taproot rules is, more or less, so that nodes who aren't taproo= t ready at the 1st flag day do not end up SPV >>> mining >>> > (using standardness rules in mempool prevents them from mining an i= nvalid 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=3Dtrue code l= eading up to that flag day means that clients >>> would >>> > not be fully compatible with an early activation that could be prop= osed before the flag day is reached. E.g., >>> LOT=3Dtrue >>> > 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 f= or business purposes, software engineering >>> schedules, >>> > etc. I think even with signaling BIP8, it would be possibly superio= r to activate rules at a fixed date (or a >>> quantized >>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe m= ore). >>> > 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possib= le that the rule could not activate, if >>> signaling does >>> > not occur, providing additional stopgap against dev collusion and b= ugs. But BIP-8 can activate immediately (with >>> start >>> > times being proposed 1 month after release?) so we don't have certa= inty around how much time there is for that >>> secondary >>> > review process (read -- I think it isn't that valuable) and if ther= e *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 dead= line 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 t= his 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=3Dtrue so that taproot can still have early= activation if desired. >>> > >>> > Overall I agree with the point that all the contention around LOT, m= akes 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=3Dtrue is the best >>> option >>> > at this time as it allows our flag day to remain compatible with su= ch an early activation. >>> > >>> > I think we can also clearly communicate that LOT=3Dtrue for Taproot= is not a precedent setting occurence for any >>> future >>> > forks (hold me accountable to not using this as precedent this shou= ld 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 >>> >>> > >>>=20 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev