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 0FE9BC000E for ; Sun, 27 Jun 2021 08:47:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0BDDD40153 for ; Sun, 27 Jun 2021 08:47:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.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 A3SOp0Dmgyny for ; Sun, 27 Jun 2021 08:47:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by smtp2.osuosl.org (Postfix) with ESMTPS id CBA174002B for ; Sun, 27 Jun 2021 08:47:19 +0000 (UTC) Received: by mail-yb1-xb34.google.com with SMTP id m9so12794133ybo.5 for ; Sun, 27 Jun 2021 01:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/HvEaCvaxXoIysIrEgLuWK0Hbv6lG1ZI7L6GzzyGsrw=; b=V8F6MYMbG+V4dI5Mn9l89pyIm5Va5cOxxyuJYe10vyCJdfIXPFO5488c3jaZi5R53e c8fb9NbAThzmCjN0IXvPMKkXmBe1JSSMXPUvDYHML56llmxcGGvObZ7h+LhvHhL7/YfX /FGEmdh14o4j9g0aRwB+QOpxHkuRV/UlDfpArOnOYbnc8s3Q3SWBvcDLcV98JaMb+m83 4xI6++AHG1BY/LsbsD/11431nUlja41IVxw5q6sq1g56XcRW9Tyla0+HW16uQyLrOH6e CqWqntNhPamwRo1Utr4GP/3S1lAeQRsu0c2TPr3kpJXeSETk3k+k0cdGx3lYq0dNTMzb hvOQ== 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:cc:content-transfer-encoding; bh=/HvEaCvaxXoIysIrEgLuWK0Hbv6lG1ZI7L6GzzyGsrw=; b=OM4huw/1unxg40VitYC7SHzxXoL3KgsZCtesMLSYcZVF+R8pYrwsV+Vnqhr0gOhO2y mzjdWn3LMVUN4K0IaW4WOzSKvBk3g1Cv5dlcrvnyK0itCUG+bDVrQ3bq8WhvpSxc40r3 ZbMb3TTSlpUn/NsVw/U1sg+Xd/9GEuczQNJFvIF8hnQ/JeSOIVynIaOkMXXUy+FWkoLg 5TGfFyCD237fKaJtyxYsMqyk1sLszyakmGk3LvpI7xkB1Gs7E4HDo82i7H0xTF30cu+v k4oc5tTLFYrUhyRF1ONF3TyEHOd+DbGKTV6TGL1RnMxhI7t5VaZwBbVpwv8/YCVFBABY Typg== X-Gm-Message-State: AOAM530Yj9JUoS5jwOKoY43FzlfJ1uXU7AmK/e/6mq5bDqSoGTzuOaan iRid40SdhbU0KyDBR7MPIwiWfBdvq2abspWf3caxcg== X-Google-Smtp-Source: ABdhPJw7Akc9yHuJTwaRE+WdCazjgJ4EbfkmsapFnfwTRo8+BZ8ildfpxbEzyAXvyIbtsCWcOdow5xEczF1jolqD1ZU= X-Received: by 2002:a25:a365:: with SMTP id d92mr24186211ybi.462.1624783638600; Sun, 27 Jun 2021 01:47:18 -0700 (PDT) MIME-Version: 1.0 References: <99FAC012-22BB-4160-A941-A99FF4D330DF@voskuil.org> In-Reply-To: <99FAC012-22BB-4160-A941-A99FF4D330DF@voskuil.org> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sun, 27 Jun 2021 10:47:06 +0200 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 27 Jun 2021 08:47:21 -0000 If different users want different incompatible things (enough on each side), there's no way to avoid the split. We shouldn't try to avoid such a split. Users decide the rules, not miners nor developers. On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev wrote: > > Ultimately there is only one answer to this question. Get majority hash p= ower support. > > Soft fork enforcement is the same act as any other censorship enforcement= , the difference is only a question of what people want. Given that there i= s no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resolves = this question of conflicting wants, but it is not a democracy, it=E2=80=99s= a market. One votes by trading. > > If one wants to enforce a soft fork (or otherwise censor) this is accompl= ished by mining (or paying others to do so). Anyone can mine, so everyone g= ets a say. Mining is trading capital now for more later. If enough people w= ant to do that, they can enforce a soft fork. It=E2=80=99s time Bitcoiners = stop thinking of miners as other people. Anyone can mine, and that=E2=80=99= s your vote. > > 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 fol= low. This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s o= ne that has been shown to not always pay off. > > e > > > On Jun 26, 2021, at 14:43, Eric Voskuil wrote: > > > > =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D. > > > > Without majority hash power support, activation simply means you are of= f on a chain split. Anyone can of course split off from a chain by changing= a rule (soft or otherwise) at any time, so this is a bit of an empty claim= . > > > > Nobody can stop a person from splitting. The relevant question is how t= o *prevent* a split. And activation without majority hash power certainly d= oes not =E2=80=9Censure=E2=80=9D this. > > > > e > > > >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev wrote: > >> > >> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade e= ntirely. They can > >> still slow it down. > >> > >> It also already has the trinary state you seem to be describing (altho= ugh > >> perhaps this could be better documented in the BIP): users who oppose = the > >> softfork can and should treat the successful signal (whether MASF or U= ASF) as > >> invalid, thereby ensuring they do not follow a chain with the rules in= force. > >> > >> No additional bit is needed, as softforks are coordinated between user= s, NOT > >> miners (who have no particular say in them, aside from their role as a= lso > >> being users). The miner involvement is only out of necessity (to set t= he bit > >> in the header, which users coordinate with) and potentially to acceler= ate > >> activation by protecting upgrade-lagging users. > >> > >> Luke > >> > >> > >>>> 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= solve > >>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue pr= oponents > >>> make the point that lazy miners failing to upgrade in a timely manner= slow > >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse > >>> proponents make the point that LOT=3Dtrue can lead to undesirable for= ks that > >>> might cause a lot of chaos. I believe both points are essentially cor= rect > >>> and have created a proposal > >>> >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both pr= oblems. > >>> > >>> The proposal uses trinary version signaling rather than binary signal= ing. > >>> For any particular prospective soft fork upgrade, this allows for thr= ee > >>> signaling states: > >>> > >>> * Actively support the change. > >>> * Actively oppose the change. > >>> * Not signaling (neither support or oppose). This is the default stat= e. > >>> > >>> Using this additional information, we can release non-contentious upg= rades > >>> much quicker (with a much lower percent of miners signaling support).= For > >>> contentious upgrades, miners who oppose the change are incentivized t= o > >>> update their software to a version that can actively signal oppositio= n to > >>> 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 signal= ing > >>> would be necessary given a particular amount of active opposition > >>> signaling: > >>> > >>> [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 ch= ange > >>> today, its unlikely that less than a majority of miners would support= the > >>> 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 eventu= ally > >>> signal support. > >>> > >>> This both gives an incentive for "lazy" miners to upgrade if they act= ually > >>> oppose the change while at the same time allowing these lazy miners t= o > >>> remain lazy without slowing down the soft fork activation much. > >>> > >>> I think now is the right time to discuss new soft fork upgrade mechan= isms, > >>> when there are no pressing soft fork upgrades ready to deploy. Waitin= g > >>> until we need to deploy a soft fork to discuss this will only delay t= hings > >>> and cause contention again like it did with taproot. > >>> > >>> 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 prop= osal > >>> repo itself. > >>> > >>> Thanks, > >>> BT > >> > >> _______________________________________________ > >> 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