From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98E27C0001 for ; 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 ; 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 ; 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 ; Thu, 4 Mar 2021 19:12:54 +0000 (UTC) Received: by mail-pl1-x62d.google.com with SMTP id d8so6279217plg.10 for ; 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: In-Reply-To: From: Erik Aronesty Date: Thu, 4 Mar 2021 13:40:18 -0500 Message-ID: To: John Rand , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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