diff options
| author | Erik Aronesty <erik@q32.com> | 2021-03-04 13:40:18 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-04 19:12:55 +0000 |
| commit | 7f56a26257302721ed68622f2f74b40ea646c358 (patch) | |
| tree | ae48fba12c98fbacd9161c3e407533dccf1a1c2c | |
| parent | 0b7ddacf27b76683bf23de9f19a7b70dc1edca5f (diff) | |
| download | pi-bitcoindev-7f56a26257302721ed68622f2f74b40ea646c358.tar.gz pi-bitcoindev-7f56a26257302721ed68622f2f74b40ea646c358.zip | |
Re: [bitcoin-dev] MASF=true + LOT=informational
| -rw-r--r-- | 88/b1214fa2b33ba3f39fbac83ae2b6f8753b1aab | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/88/b1214fa2b33ba3f39fbac83ae2b6f8753b1aab b/88/b1214fa2b33ba3f39fbac83ae2b6f8753b1aab new file mode 100644 index 000000000..26ccb04ee --- /dev/null +++ b/88/b1214fa2b33ba3f39fbac83ae2b6f8753b1aab @@ -0,0 +1,207 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 98E27C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Mar 2021 19:12:55 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 94DDB4EBB7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Mar 2021 19:12:55 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: 0.25 +X-Spam-Level: +X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 + tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, + HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, + SPF_PASS=-0.001] autolearn=no autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id N8QvUT8OJnnz + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Mar 2021 19:12:54 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com + [IPv6:2607:f8b0:4864:20::62d]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 53A554D107 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Mar 2021 19:12:54 +0000 (UTC) +Received: by mail-pl1-x62d.google.com with SMTP id d8so6279217plg.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 04 Mar 2021 11:12:54 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=q32-com.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :content-transfer-encoding; + bh=a//42yBi6WI3kn5SYuVOrmX5G7LEhVF72WfkswjsQMM=; + b=VJiMJGJht+4HwG94iaO5vOGepnudhfZTGc04i0vEl0lxYGbvhF13CFTIWN5dsM+rF/ + C5UkTGRLVQNcUGpuyAnDwCu5IaobxG2qdywzt8+3gL/3Lf79wJQvP9StQFGValvtuDHQ + M3p6/A6XURTVuuO/56Terf5GzVM1cdgw/MgIr/VhnJghPykfmn6ZZWgbDlaDMoEBmpJj + sSJ3eO9c9alnvsNAjARl1QnF2135ktoXMIDET3XtI+sikPwFPYaTgMksnZhLgCn3bbWm + vT59upPxbpJAfhsMAV+ugT1JzQf11vYqugi7TcLRzRaGh+UgLfaBlD2oQ2rH2mm6gZ5t + 6YLg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:content-transfer-encoding; + bh=a//42yBi6WI3kn5SYuVOrmX5G7LEhVF72WfkswjsQMM=; + b=CMiBHh9LwdQ6eMvTewqWYW6CyCM+xRyKpnkbpnOqAxnlM2heRNAmdt7i3iDh7MJazS + qrI56AwkIu7DDjdMl94owib+99PKRPkOB+AECWCnn44jHnRLADDIw4zY90wY5XgjDrqy + xliYUtgNFty5bqKdOI2k3yDLBFz0AsMbZSHemsr20kOBtRAF696PrOWqSkr3iQxOHxKw + +2Xo3T5I8NjsMoVvzX/mtTDPW46VKqegJGqKp9Yjy7cXac4dpd4MgYUmIb4r89jOI+59 + kIE3gQHNk6m/lXgzHpIxWCrcLE3BH0L4Zzj66cWIk0FRCJLdeoYhzC7sRr4vgJobLWM3 + lx8A== +X-Gm-Message-State: AOAM531YeFYMQ02wgN0Qy47v+BvrwV28dBRv4iTMoE6EbVA8UbYZVajb + KKb037pbFvnND8mtETP5Cl/j0CAIAGsgRjkbK71+dkqxbQjp0BY= +X-Google-Smtp-Source: ABdhPJzfZ8QJa5uMT8azzfRe7VZ5MSVoTeaUJLjLgnyZzY4UvR7SK31Wl5txAM8V2u89OMCfqLx2YYMa6xVKgoNJ9nA= +X-Received: by 2002:a62:38c8:0:b029:1ef:21ba:aba3 with SMTP id + f191-20020a6238c80000b02901ef21baaba3mr3363493pfa.24.1614883229433; Thu, 04 + Mar 2021 10:40:29 -0800 (PST) +MIME-Version: 1.0 +References: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com> +In-Reply-To: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com> +From: Erik Aronesty <erik@q32.com> +Date: Thu, 4 Mar 2021 13:40:18 -0500 +Message-ID: <CAJowKg+Bs7HyrOH8ANs3nXxQ5mtmRnfHrHoRNL=hfOm+JTSuQA@mail.gmail.com> +To: John Rand <johnqrand@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Mailman-Approved-At: Thu, 04 Mar 2021 19:31:22 +0000 +Subject: Re: [bitcoin-dev] MASF=true + LOT=informational +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 04 Mar 2021 19:12:55 -0000 + +And of course: + +1) MASF=3Dtrue + LOT=3Deventually true + +Using a declining activation threshold over time gives miners control +only over the timing of activation, not the eventuality. This is +essentially the same as LOT=3Dtrue, however, it has a greater chance of +activation without requiring intervening releases or changes to the +code. + +On Thu, Mar 4, 2021 at 1:15 PM John Rand via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> With reference to considerations https://lists.linuxfoundation.org/piperm= +ail/bitcoin-dev/2021-March/018555.html and motivation to find consensus on = +incrementally improving Bitcoin soft-fork activation mechanisms. (TL;DR Co= +nsensus is important for the activation mechanism as there are more soft-fo= +rks that Bitcoin will need. We need to incrementally improve activation me= +chanisms. It could become critical that Bitcoin prevails in achieving a fu= +ture upgrade even against powerful interests.) +> +> These activation configurations have been discussed with rationales. +> +> 1) MASF=3Dtrue + LOT=3Dfalse +> +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= +380.html +> +> Try LOT=3Dfalse first, with a potential to change to LOT=3Dtrue if pools = +and miners were to unreasonably delay MASF activation. (By later deploying= + a revised activation mechanism with LOT=3Dtrue or other.) +> +> Arguments against have included a major concern about perpetuating the ri= +sk demonstrated by the BIP 141 / BIP 9 with potential for misuse and misund= +erstanding of a normative mechanism as a political veto. Such veto can be = +overridden by the market, but the forced need to do so increases drama and = +risk. +> +> Arguments in favor include being defensive to avoid misinterpretation abo= +ut developer control, and being considered and incremental in starting with= + a safe conservative approach https://old.reddit.com/r/Bitcoin/comments/lcj= +hl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/ +> +> Though it should be acknowledged and taken into account that disagreement= + and potential for partly incompatible clients with different activation co= +nfiguration, changes the risk calculation for LOT=3Dfalse. So that LOT=3Df= +alse may not be safer in practice, and does not wash reference client devel= +opers hands of contributing to the combined risk. +> +> 2) MASF=3Dtrue + LOT=3Dtrue +> +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545= +.html +> +> Arguments in favor, inverse of above. But if LOT=3Dtrue is a hidden flag= + in bitcoin reference code, or released by another project, then misinterpr= +etation of developer control is avoided. +> +> Would there be consensus for the reference implementation doing nothing, = +and signal intent to follow the market if a non-contentious LOT=3Dtrue gain= +s traction? With explicit communication of this intent and reason for init= +ial non-inclusion. +> +> There were also concerns about offending miners. This concern seems dubi= +ous to many, given pools indicated ~90% support https://taprootactivation.c= +om/ and are less detail oriented. But also BIP 148/ BIP 91 sequence events= + was enormously dangerous and worth minor social cohesion to avoid as a cat= +egory of risk. +> +> Against the realism of developer control, if there were a market need to = +reject a soft-fork, that can also be done with a UASF. But UASF is dramati= +c and the signaling direction against should be reserved for the low probab= +ility outcome. +> +> 3) MASF=3Dfalse + LOT=3Dinformational +> +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= +495.html +> +> No miner activation. This is interesting in using the non-standardness p= +art of schnorr to activate at a flag height without normative signaling in = +version bits. But the combined removal in this proposal of (normative sign= +aled) MASF is problematic for the needless delay it creates. +> +> It seems probable that the delay itself would motivate users to switch to= + clients with MASF+UASF (LOT=3Dtrue) in protest. It is true that schnorr r= +equires wallet work, but that overlooks the philosophical nature of the rej= +ection of unneeded delay and empirical evidence shows rather conclusively t= +hat ecosystem players are predominantly selectively lazy and only work on B= +itcoin infrastructure upgrades after the fact. +> +> Subsequent posts on the thread with this proposal discuss that informatio= +nal signaling be substituted so that users and the market can benefit from = +the information about miner intent. As it is non-normative it seems hard t= +o argue against: more information is better. +> +> 4) MASF=3Dtrue + LOT=3Dinformational +> +> From the above it would be interesting to see discussion of a combination= + of MASF=3Dtrue (same mechanism as 1 or 2) with LOT=3Dinformational (mechan= +ism from 3). Where, again, informational means signaling is provided but i= +n an optional and informational sense, that is not normative for consensus = +code, but to inform the ecosystem about a hashrate verified opt-in assertio= +n of readiness from pools. In some way that could be more reliable in sign= +aling a willing readiness rather than a UASF under duress mandatory signal. +> +> Consider also with 2 or 4) alike (or 1 after switching to 2), in the even= +t that activation were unreasonably delayed, forced miner signaling from 2)= + could be argued to be less reliable as the mechanism for signaling on pool= +s has no automated link to fullnode software version. In the MASF delay ev= +entuality, where the flag height is relied upon, users and services would b= +e well advised to ensure they are running schnorr validating fullnodes, and= + for SPV users to verify their wallet relies on schnorr upgraded fullnodes. +> +> John R +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |