path: root/34/980fa4acc4ed10db6898609f7565c5f6566d01

Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B7737C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:43:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8B2744031E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:43:59 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.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 fninkbIukRQ8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:43:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [IPv6:2607:f8b0:4864:20::42f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 1F208402BC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:43:57 +0000 (UTC)
Received: by mail-pf1-x42f.google.com with SMTP id d12so2824973pfj.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 14:43:57 -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=kFSbDilUjBVcCp0BNm7OWi+Ky5C6cdOjmyJD0490v4s=;
 b=i14hnmVrW0iYNGJ72BTPQ2YvQ0yH9+XkFbQ/VkeflwSqTgFmQpC3PKA+0hhxX7psxF
 3ILqj2ORgJMQH5yPXkNaFll7mescpXZaILZSmPn62yvoLK3vIua/aJWXbGQuOOovTJki
 FngOlDzd/pFBAprMmhbJn4KJqb5f5AHpcOCIeC3LcY5aGM+PFmaRoK4Zkm0ftMppFRn5
 Ip/5XMWoqp3pLQHWla3UvsG622ZlU9AgmjF1371brZpmSoI2vihM/zx1jAnHS9GscvQW
 9+o2NExbiytY7MX9XRPTHaZakCC8BNFUDbbeR7qeScUMhYL4OhiT+T7KLhyAxs86/2cv
 dtZg==
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=kFSbDilUjBVcCp0BNm7OWi+Ky5C6cdOjmyJD0490v4s=;
 b=lQETPIfXPR2cp2Pd4S8dxQiTnWK7uALiYMLt/mDJOI9X89939jaA9TjcaJlgpVgitX
 SUspW8tbDtGDLFXzbsHXSKQTuZZ+lXeOJjWPt+fVq0aUAk/LLuZRAuExId79c1LX+cRL
 SqLE3PVWNj/PQxflqy7ziPYT40d7a5RQZJqh6/ms6MExpwZ2dA0KRa8KFv8iBN6J8QSf
 lmpKxCj2JS2n+G3K/6KfvoMQIRnzKBzOViDsyRWQHYVGNJaS7UdzU7AGPV52HtIWDb1R
 MSjZmAKhGFSQ6UYDhaMmByFTWgQPhQCy83NbM0jaWW7uxDiN5unNnXpP9l/lgRFqMgkk
 oMFg==
X-Gm-Message-State: AOAM533EyWu8w/Y56hbDD/kUV5izirWp913Hrkrj8PmffPce6K9cUmyD
 OmWDP9VW9AJqfEfjH/qWWkzKjQ==
X-Google-Smtp-Source: ABdhPJzH2UXy/TLuzfsT9stH07Yo1RmD1k5UYR0R0taHamfdWxP34R8Z3+/PuADCn2gINeZQ/KrSAg==
X-Received: by 2002:a62:8647:0:b029:302:4642:ae52 with SMTP id
 x68-20020a6286470000b02903024642ae52mr17077748pfd.7.1624743837322; 
 Sat, 26 Jun 2021 14:43:57 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::437e])
 by smtp.gmail.com with ESMTPSA id y3sm9456358pga.72.2021.06.26.14.43.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 26 Jun 2021 14:43:56 -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: Sat, 26 Jun 2021 14:43:55 -0700
Message-Id: <CB5A45C6-6446-4ECE-AD7D-8F079F8661BF@voskuil.org>
References: <202106262113.05006.luke@dashjr.org>
In-Reply-To: <202106262113.05006.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (18F72)
Cc: 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: Sat, 26 Jun 2021 21:43:59 -0000

For some definitions of =E2=80=9Cblock=E2=80=9D.

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.

Nobody can stop a person from splitting. The relevant question is how to *pr=
event* a split. And activation without majority hash power certainly does no=
t =E2=80=9Censure=E2=80=9D this.

e

> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>=20
> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade entir=
ely. 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 for=
ce.
>=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 sol=
ve
>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue propon=
ents
>> make the point that lazy miners failing to upgrade in a timely manner slo=
w
>> 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 correct=

>> and have created a proposal
>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master=
/b
>> ip-trinary-version-bits.md> for soft fork upgrades that solve both proble=
ms.
>>=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 upgrade=
s
>> 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 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 change=

>> 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 eventually=

>> signal support.
>>=20
>> This both gives an incentive for "lazy" miners to upgrade if they actuall=
y
>> 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 mechanisms=
,
>> 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 thing=
s
>> 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 proposal=

>> repo itself.
>>=20
>> Thanks,
>> BT
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev