From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 39E22C000E for ; Sat, 26 Jun 2021 22:05:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2900B832A9 for ; Sat, 26 Jun 2021 22:05:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLBqroHaZs_3 for ; Sat, 26 Jun 2021 22:05:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 08D938329A for ; Sat, 26 Jun 2021 22:05:06 +0000 (UTC) Received: by mail-pl1-x62b.google.com with SMTP id c15so6618477pls.13 for ; Sat, 26 Jun 2021 15:05:06 -0700 (PDT) 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=3Uc/46VYoj9PCLunrwEoYHZ/uoCOG/1JIqi0AYqH6Sg=; b=LKskxmcm5yQvwrmK3efBsAJVI+mqWWK3Iga+lYJQYOqdo3N5WRqxL0HQ4B5CfFCeUu /fDlcG+Z7h+Haaf74VJ3z3KHZKtsmvTnXxFg/3Rr7w81qpVsHT4TXu8tbV4h59mBQb+w +b/3MLX0XZTuL4UBoUU3vg46jpDdea8V+Fk4jVtS2dNW8NLU+Kvg9iXm1LLpyEnODPaz 36JCICS5FtxvYTxS4nHQeW/KsfyFtcDiivGgOIvG4z7/h3cK5HX7M1B7yERFkcxuTlkz b/by8Pe79FETzaaYXrVq44m3IgpIjveFjIPNuxop/i5Sjbo6zujAqM97TzQjJo4VIB22 IwOw== 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=3Uc/46VYoj9PCLunrwEoYHZ/uoCOG/1JIqi0AYqH6Sg=; b=lMKYEeDbnQW16edepDgsekR61XT8EUsUlZDWsYoI2tVEzgeqe+VTzTFjBT87bL3l/L VRRSCM2zgarHhk3XPqBdKn6W0rrr/dCKTZuPy13oWEZNxHqTM7zjeRyDhDEJzeWyPEo2 WDdWgwIccoUxiUG2mrgPO7Rqu6YoXTPHHWDr1Kjy5bH25VQVdD+AdjJx4QJV+xGmqhhs xVhcW5/Q4F2q5mnhnzaHX6RXfhCK4WeC4RkiYMsRzM09Zd4IIWFO68QGnjJjH8OMzO2s FXZkHVZ6nAgaEjP2RMMm+HozOSZUL9sRxrQWSxEmwl/6mCJEGpQrO19sylPtLhFxpiKU SArg== X-Gm-Message-State: AOAM532S4z+AhT+r5wK1+TFFACOe9KTJWpbTwkeoq71WD//1rbZk42Yt XAVDMM/ov+3s4H7kHR0GcIb5zA== X-Google-Smtp-Source: ABdhPJz1fTEIb/7eiwHd6FNDaqNwyPzCCjFxUGTcfIR4vmmo9haZHzImjMpJxl9wSefTCQr2saStyQ== X-Received: by 2002:a17:902:e8c2:b029:123:25ba:e443 with SMTP id v2-20020a170902e8c2b029012325bae443mr15410791plg.29.1624745106352; Sat, 26 Jun 2021 15:05:06 -0700 (PDT) Received: from smtpclient.apple ([2601:600:9c00:1d0::437e]) by smtp.gmail.com with ESMTPSA id z3sm9416839pfa.67.2021.06.26.15.05.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Jun 2021 15:05:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sat, 26 Jun 2021 15:05:05 -0700 Message-Id: <99FAC012-22BB-4160-A941-A99FF4D330DF@voskuil.org> References: In-Reply-To: To: Luke Dashjr , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (18F72) Cc: Billy Tetrud Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades 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: Sat, 26 Jun 2021 22:05:08 -0000 Ultimately there is only one answer to this question. Get majority hash powe= r support. Soft fork enforcement is the same act as any other censorship enforcement, t= he difference is only a question of what people want. Given that there is no= collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resolves this q= uestion of conflicting wants, but it is not a democracy, it=E2=80=99s a mark= et. One votes by trading. If one wants to enforce a soft fork (or otherwise censor) this is accomplish= ed by mining (or paying others to do so). Anyone can mine, so everyone gets a= say. Mining is trading capital now for more later. If enough people want to= do that, they can enforce a soft fork. It=E2=80=99s time Bitcoiners stop th= inking of miners as other people. Anyone can mine, and that=E2=80=99s your v= ote. Otherwise, as mentioned below, anyone can start a new coin. But it=E2=80=99s= dishonest to imply that one can do this and all others will surely follow. T= his cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s one that= has been shown to not always pay off. e > On Jun 26, 2021, at 14:43, Eric Voskuil wrote: >=20 > =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D. >=20 > Without majority hash power support, activation simply means you are off o= n a chain split. Anyone can of course split off from a chain by changing a r= ule (soft or otherwise) at any time, so this is a bit of an empty claim. >=20 > Nobody can stop a person from splitting. The relevant question is how to *= prevent* a split. And activation without majority hash power certainly does n= ot =E2=80=9Censure=E2=80=9D this. >=20 > e >=20 >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev wrote: >>=20 >> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade enti= rely. They can=20 >> still slow it down. >>=20 >> It also already has the trinary state you seem to be describing (although= =20 >> perhaps this could be better documented in the BIP): users who oppose the= =20 >> softfork can and should treat the successful signal (whether MASF or UASF)= as=20 >> invalid, thereby ensuring they do not follow a chain with the rules in fo= rce. >>=20 >> No additional bit is needed, as softforks are coordinated between users, N= OT=20 >> miners (who have no particular say in them, aside from their role as also= =20 >> being users). The miner involvement is only out of necessity (to set the b= it=20 >> in the header, which users coordinate with) and potentially to accelerate= =20 >> activation by protecting upgrade-lagging users. >>=20 >> Luke >>=20 >>=20 >>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote: >>> Given the recent controversy over upgrade mechanisms for the >>> non-controversial taproot upgrade, I have been thinking about ways to so= lve >>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue propo= nents >>> make the point that lazy miners failing to upgrade in a timely manner sl= ow >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse >>> proponents make the point that LOT=3Dtrue can lead to undesirable forks t= hat >>> might cause a lot of chaos. I believe both points are essentially correc= t >>> and have created a proposal >>> >> ip-trinary-version-bits.md> for soft fork upgrades that solve both probl= ems. >>>=20 >>> The proposal uses trinary version signaling rather than binary signaling= . >>> For any particular prospective soft fork upgrade, this allows for three >>> signaling states: >>>=20 >>> * Actively support the change. >>> * Actively oppose the change. >>> * Not signaling (neither support or oppose). This is the default state. >>>=20 >>> Using this additional information, we can release non-contentious upgrad= es >>> much quicker (with a much lower percent of miners signaling support). Fo= r >>> contentious upgrades, miners who oppose the change are incentivized to >>> update their software to a version that can actively signal opposition t= o >>> the change. The more opposition there is, the higher the threshold >>> necessary to lock in the upgrade. With the parameters I currently >>> recommended in the proposal, this chart shows how much support signaling= >>> would be necessary given a particular amount of active opposition >>> signaling: >>>=20 >>> [image: thresholdChart.png] >>> If literally no one signals opposition, a 60% threshold should be >>> relatively safe because it is a supermajority amount that is unlikely to= >>> change significantly very quickly (ie if 60% of miners support the chang= e >>> today, its unlikely that less than a majority of miners would support th= e >>> change a year or two from now), and if no one is signaling opposition, >>> chances are that the vast majority of the other 40% would also eventuall= y >>> signal support. >>>=20 >>> This both gives an incentive for "lazy" miners to upgrade if they actual= ly >>> oppose the change while at the same time allowing these lazy miners to >>> remain lazy without slowing down the soft fork activation much. >>>=20 >>> I think now is the right time to discuss new soft fork upgrade mechanism= s, >>> when there are no pressing soft fork upgrades ready to deploy. Waiting >>> until we need to deploy a soft fork to discuss this will only delay thin= gs >>> and cause contention again like it did with taproot. >>>=20 >>> I'm very curious to know what people think of this mechanism. I would >>> appreciate any comments here, or written as github issues on the proposa= l >>> repo itself. >>>=20 >>> Thanks, >>> BT >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev