diff options
| author | Eric Voskuil <eric@voskuil.org> | 2021-06-27 02:21:58 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-27 09:22:01 +0000 |
| commit | 9382a418338e8acedf65ef6bd03033775dcc75c3 (patch) | |
| tree | 2a016433ab08e048afa37aac1ad2a2ad4a27cae1 | |
| parent | 0391f41afd01a99f3f770c3156161293cc2e3615 (diff) | |
| download | pi-bitcoindev-9382a418338e8acedf65ef6bd03033775dcc75c3.tar.gz pi-bitcoindev-9382a418338e8acedf65ef6bd03033775dcc75c3.zip | |
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
| -rw-r--r-- | 3f/5483ab0fc1b747120e65e9352722611fb908a9 | 279 |
1 files changed, 279 insertions, 0 deletions
diff --git a/3f/5483ab0fc1b747120e65e9352722611fb908a9 b/3f/5483ab0fc1b747120e65e9352722611fb908a9 new file mode 100644 index 000000000..471e6a664 --- /dev/null +++ b/3f/5483ab0fc1b747120e65e9352722611fb908a9 @@ -0,0 +1,279 @@ +Return-Path: <eric@voskuil.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 8C8A9C000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 09:22:01 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 748A9401BD + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 09:22:01 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.899 +X-Spam-Level: +X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] + 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 jX7CHKql0_32 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 09:22:00 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com + [IPv6:2607:f8b0:4864:20::42c]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 2083540165 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 09:22:00 +0000 (UTC) +Received: by mail-pf1-x42c.google.com with SMTP id k6so11428143pfk.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 02:22:00 -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=MdSAAsnnCm3dWv1ZzuM67jkAS5RdJUo03E7+KHT+4ZM=; + b=xqDbdDXhjDcYE4F1ahhTnznVYlOeCTXHWoCQuy6/dLS6gUye+2rBSaxrdSS86xNAqG + dcCTihyfvhrZtMCyTX9t9NZ+ndEXP+KN2Al+RB8WCILQ2oJc+6G2CMu9o87PUAobnQMa + xSYcE4SMheXFCR+VbLUigT8vwVrxPM+ztrCMWkes3BGex8ikUEUmcLlw3wkrAo72Q/pq + oQT1JxRYTJGx/PEKBh0Hxy7bL3J1NQ7f51MMZq6hjtRcTlnmCDzcIxVGoAsTkYTaiE0/ + k9GiZCn0N03q53pM7to7XK6YuIt/W6FiOROm6hGXxLvpEr0ozee3TDmfpKPyKlYFBwx9 + 1ThA== +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=MdSAAsnnCm3dWv1ZzuM67jkAS5RdJUo03E7+KHT+4ZM=; + b=kQGDA9o750fS5r5QKtkd5nL6h9rP3VfNzr1ONxiIGkmWwHH2+PASF/308HRqVl2uE8 + 2XsJgTlteWjoGr21b01KQZBbO1VoKR+s9KbVqvxzHNML57ejh753+ey9GkWI5Or03yOs + xV1Dp3TRtUUnoac4CXYcvg8ovrBnv5OqthT/TQMVNQYHVbpiBFtj89he/QOX7aDGUhtQ + pu51v2qs/b9auNtr8ohBKViFgiICiljnEGXDPC9XMRk95lslDAJhFOQBPGc32tMFdb8L + MrZMELVMSbGjvaEyEDAWRoDoOXIUR4lktXcUyJ2/KnsnTtOrojHPQYePHA1KeH7/KZcg + en0g== +X-Gm-Message-State: AOAM532gdanAp4tCEBO0elp0xPgFZYnxbsbS5xaGcyaS0vIgzsYEL3Qt + E3Sx4IS5l0L+Xp8q+5OJnP1BvyJnxDDq+oGu +X-Google-Smtp-Source: ABdhPJyNQnIQimFHJum+M7nw4v/kvCflWv2/2Jdrw1DsYrfjiA+5MfEHOJqejhzkXVlCpgrZTeIPuA== +X-Received: by 2002:a63:5fd4:: with SMTP id + t203mr18050007pgb.401.1624785719256; + Sun, 27 Jun 2021 02:21:59 -0700 (PDT) +Received: from smtpclient.apple ([2601:600:9c00:1d0::437e]) + by smtp.gmail.com with ESMTPSA id o20sm10126614pjq.57.2021.06.27.02.21.58 + (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); + Sun, 27 Jun 2021 02:21:58 -0700 (PDT) +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +From: Eric Voskuil <eric@voskuil.org> +Mime-Version: 1.0 (1.0) +Date: Sun, 27 Jun 2021 02:21:58 -0700 +Message-Id: <E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org> +References: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com> +In-Reply-To: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com> +To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc> +X-Mailer: iPhone Mail (18F72) +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Billy Tetrud <billy.tetrud@gmail.com> +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 <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: Sun, 27 Jun 2021 09:22:01 -0000 + +I have not objected to anyone splitting. As I said, a split is always possib= +le, and of course has been done on a large scale. It is only the misleading s= +tatements about inherent soft fork =E2=80=9Ccompatibility=E2=80=9D and the i= +mplication that activation without hash power enforcement does not create a s= +plit that I object to. People who know better should be honest about it. + +Far too many people have been led to believe there is some sort of activatio= +n choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslowe= +d down=E2=80=9D). There is only a choice between creating a split and hash p= +ower enforcement. Soft forks are rule changes, and thereby incompatible - un= +less enforced by majority hash power. + +The statements below are grossly misleading and need to be called out as suc= +h so that people can actually make this decision you speak of. This idea tha= +t =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The question= + is only how to avoid a split. If one does not care he can split at any time= +, no discussion required. + +e + +> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote: +>=20 +> =EF=BB=BFIf different users want different incompatible things (enough on e= +ach +> 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. +>=20 +>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev +>> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>=20 +>> Ultimately there is only one answer to this question. Get majority hash p= +ower support. +>>=20 +>> 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 is= + no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resolves th= +is question of conflicting wants, but it is not a democracy, it=E2=80=99s a m= +arket. One votes by trading. +>>=20 +>> 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 ge= +ts a say. Mining is trading capital now for more later. If enough people wan= +t to do that, they can enforce a soft fork. It=E2=80=99s time Bitcoiners sto= +p thinking of miners as other people. Anyone can mine, and that=E2=80=99s yo= +ur vote. +>>=20 +>> Otherwise, as mentioned below, anyone can start a new coin. But it=E2=80=99= +s dishonest to imply that one can do this and all others will surely follow.= + This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s one th= +at has been shown to not always pay off. +>>=20 +>> e +>>=20 +>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> 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= + 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. +>>>=20 +>>> Nobody can stop a person from splitting. The relevant question is how to= + *prevent* a split. And activation without majority hash power certainly doe= +s not =E2=80=9Censure=E2=80=9D this. +>>>=20 +>>> e +>>>=20 +>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lis= +ts.linuxfoundation.org> wrote: +>>>>=20 +>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade en= +tirely. They can +>>>> still slow it down. +>>>>=20 +>>>> It also already has the trinary state you seem to be describing (althou= +gh +>>>> perhaps this could be better documented in the BIP): users who oppose t= +he +>>>> softfork can and should treat the successful signal (whether MASF or UA= +SF) as +>>>> invalid, thereby ensuring they do not follow a chain with the rules in f= +orce. +>>>>=20 +>>>> No additional bit is needed, as softforks are coordinated between users= +, NOT +>>>> miners (who have no particular say in them, aside from their role as al= +so +>>>> being users). The miner involvement is only out of necessity (to set th= +e bit +>>>> in the header, which users coordinate with) and potentially to accelera= +te +>>>> 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 s= +olve +>>>>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue pro= +ponents +>>>>> make the point that lazy miners failing to upgrade in a timely manner s= +low +>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse +>>>>> proponents make the point that LOT=3Dtrue can lead to undesirable fork= +s that +>>>>> might cause a lot of chaos. I believe both points are essentially corr= +ect +>>>>> and have created a proposal +>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/mas= +ter/b +>>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both pro= +blems. +>>>>>=20 +>>>>> The proposal uses trinary version signaling rather than binary signali= +ng. +>>>>> For any particular prospective soft fork upgrade, this allows for thre= +e +>>>>> 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 upgr= +ades +>>>>> much quicker (with a much lower percent of miners signaling support). = +For +>>>>> contentious upgrades, miners who oppose the change are incentivized to= + +>>>>> update their software to a version that can actively signal opposition= + 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 signali= +ng +>>>>> 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 t= +o +>>>>> change significantly very quickly (ie if 60% of miners support the cha= +nge +>>>>> today, its unlikely that less than a majority of miners would support t= +he +>>>>> 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 eventua= +lly +>>>>> signal support. +>>>>>=20 +>>>>> This both gives an incentive for "lazy" miners to upgrade if they actu= +ally +>>>>> 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 mechani= +sms, +>>>>> 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 th= +ings +>>>>> 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 propo= +sal +>>>>> repo itself. +>>>>>=20 +>>>>> Thanks, +>>>>> BT +>>>>=20 +>>>> _______________________________________________ +>>>> 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 + |