path: root/0a/afa57b1cf680991212637bbd45409199874933

Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9D828C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 17:55:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8C420403EE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 17:55:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level: 
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dashjr.org
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 2m7_otfpib9r
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 17:55:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
 by smtp2.osuosl.org (Postfix) with ESMTP id BE77C40100
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 17:55:15 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.209])
 (Authenticated sender: luke-jr)
 by zinan.dashjr.org (Postfix) with ESMTPSA id 9878738A002A;
 Tue, 29 Jun 2021 17:55:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
 t=1624989313; bh=ZGtBQ2valVcNhlsVo0LknhHDkMjSArB+Bbel+dzUkHo=;
 h=From:To:Subject:Date:Cc:References:In-Reply-To;
 b=lAXWDOR99VJeFhAeUMXVc3xzAKPmVdKuL7pK5VYzS9+Pjsmc0fht1pdcC0KAxirtC
 y2uW8O9Q5FvZQvaGlk2Ur3sQ3zJmmt1lclwMfA4y+bD7tYFQ+xBa9S6E0C1aRXx/eR
 xPyJpW9QkqH0NaNfcAf245E3XP3464R9bVda2tQQ=
From: Luke Dashjr <luke@dashjr.org>
To: Eric Voskuil <eric@voskuil.org>
Date: Tue, 29 Jun 2021 17:55:11 +0000
User-Agent: KMail/1.9.10
References: <CABm2gDqQm0_JnddJ2AKbDnNTGV0kYm-zOqtyZFn2=GHRb2cY2g@mail.gmail.com>
 <4E02C43C-D5D9-489E-9D94-4BF2DCB92496@voskuil.org>
In-Reply-To: <4E02C43C-D5D9-489E-9D94-4BF2DCB92496@voskuil.org>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <202106291755.11926.luke@dashjr.org>
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: Tue, 29 Jun 2021 17:55:17 -0000

The only alternative to a split in the problematic scenarios are 1) concede=
=20
centralised miner control over the network, and 2) have inconsistent=20
enforcement of rules by users who don't agree on what the correct rules are=
,=20
again leading to centralised miner control over the network.

In other words, in this context, accepting a split between disagreeing user=
s=20
is the ONLY way Bitcoin can possibly continue as a decentralised currency.=
=20
Making that split as clean and well-defined as possible not only ensures th=
e=20
best opportunity for both sides of the disagreement, but also minimises the=
=20
risk that the split occurs at all (since the "losing" side needs to concede=
,=20
rather than passively continue the disagreement ongoing after the attempted=
=20
protocol change).

Luke


On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> At least we are now acknowledging that splitting is what it=E2=80=99s abo=
ut. That=E2=80=99s
> progress.
>
> e
>
> > On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> >
> > =EF=BB=BF
> > I think the option of "permanent failure because miners veto" should
> > actually be abandoned. No, I don't think we should avoid splits when
> > possible, I don't think we should avoid splits at all costs.
> >
> >> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud@gmail.com> wrot=
e:
> >> @Luke
> >>
> >> > They can still slow it down.
> >>
> >> Absolutely. However I think that the option of permanent failure is
> >> important. It certainly would be ideal to ensure that enough bitcoin
> >> users support the upgrade *before* releasing it, however realistically
> >> this can never be more than an estimate, and estimates can sometimes be
> >> wildly wrong. It would be unfortunate if miners had a substantially
> >> different estimate of user support than the people putting in the work
> >> to release bitcoin upgrades. Even if upgrades are never released before
> >> it becomes clear that a large supermajority of users want the upgrade,
> >> if miners don't agree with the estimate a harmful chain split could
> >> occur. And I agree with Eric that the goal here is to prevent a chain
> >> split during an upgrade when possible. This includes permanent failure
> >> of an upgrade when there is unexpectedly large miner opposition.
> >>
> >> This of course does not prevent a UASF-style deployment to be done aft=
er
> >> an initial failure to deploy occurs. My proposal is essentially a
> >> mechanism to improve upon the speedy-trial idea, allowing for even
> >> speedier releases (than speedy trial) without adding additional risk of
> >> undesired chain splits.
> >>
> >> > [BIP8] already has the trinary state you seem to be describing
> >>
> >> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> >> longest chain, B. Follow the upgrade chain, or C. follow the
> >> non-upgraded chain. I agree. However the trinary state in my proposal =
is
> >> materially different - it is the signaling itself that is trinary, not
> >> just which chain is being followed. This allows others to know and make
> >> programmatic decisions (in software) based on that signaling. I'm sure
> >> you can agree that does not exist in BIP8.
> >>
> >> > No additional bit is needed, as softforks are coordinated between
> >> > users, NOT miners
> >>
> >> And yet there is miner involvement, as you rightly pointed out. Miners
> >> are needed to set the nVersion in the header. So when you say "no
> >> additional bit is needed", could you please be clearer as to what you
> >> mean? Do you mean that signaling of opposition in a block can be done
> >> without any "additional bit"? Or are you just saying that it is
> >> redundant to consider what miners might be opposing an upgrade?
> >>
> >> @Jorge
> >>
> >> > If different users want different incompatible things... there's no
> >> > way to avoid the split
> >>
> >> I agree. This happened with bcash, and that's fine. It was painful, but
> >> there were a significant amount of users that disagreed, and they have
> >> the chain they want now.
> >>
> >> But we generally all want to avoid a chain split when possible. Because
> >> chain splits have a cost, and that cost can be high, its likely that
> >> many users would rather choose the chain with the most support rather
> >> than choosing the chain with their preferred rules.
> >>
> >> However, the question here is: how do we estimate what fraction of use=
rs
> >> wants which rules? We don't have a divining rod to determine with
> >> certainty what users want. We can only make polls of various levels of
> >> inaccuracy. The methods bitcoin has been using is community discussion
> >> and social consensus estimation as well as miner signaling during the
> >> actual deployment period. Neither of these are perfect, but they are
> >> both reasonable enough mechanisms. However, because both of these
> >> mechanisms are very rough estimates of user sentiment, we need to
> >> consider the possibility that sometimes the estimate may be
> >> substantially inaccurate when we design deployment procedures. This
> >> inaccuracy is why we need multiple barriers in place for an upgrade, a=
nd
> >> why we need to have higher thresholds of success (require larger
> >> supermajorities in both consensus and miner signaling).
> >>
> >> Developers obviously care about bitcoin and have an incentive (personal
> >> and probably financial) to do it right. And miners have both an
> >> incentive to keep the system healthy, as well as an incentive to mine =
on
> >> the chain that the economic majority of users is using. But measuring
> >> the consensus of the bitcoin community can be extraordinarily difficult
> >> to do with consistent accuracy, and so I think miner signaling as it h=
as
> >> been used as a second barrier to entry for an upgrade is quite
> >> appropriate.
> >>
> >>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@voskuil.org> wrote:
> >>> I have not objected to anyone splitting. As I said, a split is always
> >>> possible, and of course has been done on a large scale. It is only the
> >>> misleading statements about inherent soft fork =E2=80=9Ccompatibility=
=E2=80=9D and the
> >>> implication that activation without hash power enforcement does not
> >>> create a split 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
> >>> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (mayb=
e =E2=80=9Cslowed down=E2=80=9D).
> >>> There is only a choice between creating a split and hash power
> >>> enforcement. Soft forks are rule changes, and thereby incompatible -
> >>> unless enforced by majority hash power.
> >>>
> >>> The statements below are grossly misleading and need to be called out
> >>> as such so that people can actually make this decision you speak of.
> >>> This idea that =E2=80=9Cusers=E2=80=9D decide the rules is not the qu=
estion. 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> wrot=
e:
> >>> >
> >>> > =EF=BB=BFIf different users want different incompatible things (eno=
ugh 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
> >>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> >>
> >>> >> Ultimately there is only one answer to this question. Get majority
> >>> >> hash power 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 is no collective =E2=80=9Cwe=E2=80=9D, those want=
s 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
> >>> >> accomplished by mining (or paying others to do so). Anyone can min=
e,
> >>> >> 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 thinking of miners as othe=
r people.
> >>> >> Anyone can mine, and that=E2=80=99s 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
> >>> >> follow. This 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 <eric@voskuil.org> wrote:
> >>> >>>
> >>> >>> =EF=BB=BFFor 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 *prevent* a split. And activation without majority hash
> >>> >>> power certainly does not =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:
> >>> >>>>
> >>> >>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upg=
rade
> >>> >>>> entirely. They can still slow it down.
> >>> >>>>
> >>> >>>> It also already has the trinary state you seem to be describing
> >>> >>>> (although perhaps this could be better documented in the BIP):
> >>> >>>> users who oppose the softfork can and should treat the successful
> >>> >>>> signal (whether MASF or UASF) 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
> >>> >>>> users, NOT miners (who have no particular say in them, aside from
> >>> >>>> their role as also being users). The miner involvement is only o=
ut
> >>> >>>> of necessity (to set the bit in the header, which users coordina=
te
> >>> >>>> with) and potentially to accelerate 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 proponents make the point that lazy miners fail=
ing
> >>> >>>>> 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 forks that 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/b=
lo
> >>> >>>>>b/master/b ip-trinary-version-bits.md> for soft fork upgrades th=
at
> >>> >>>>> solve both problems.
> >>> >>>>>
> >>> >>>>> The proposal uses trinary version signaling rather than binary
> >>> >>>>> signaling. For any particular prospective soft fork upgrade, th=
is
> >>> >>>>> allows for three signaling states:
> >>> >>>>>
> >>> >>>>> * Actively support the change.
> >>> >>>>> * Actively oppose the change.
> >>> >>>>> * Not signaling (neither support or oppose). This is the default
> >>> >>>>> state.
> >>> >>>>>
> >>> >>>>> Using this additional information, we can release non-contentio=
us
> >>> >>>>> upgrades 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 versi=
on
> >>> >>>>> 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:
> >>> >>>>>
> >>> >>>>> [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 t=
he
> >>> >>>>> vast majority of the other 40% would also eventually signal
> >>> >>>>> support.
> >>> >>>>>
> >>> >>>>> This both gives an incentive for "lazy" miners to upgrade if th=
ey
> >>> >>>>> actually oppose the change while at the same time allowing these
> >>> >>>>> lazy miners to remain lazy without slowing down the soft fork
> >>> >>>>> activation much.
> >>> >>>>>
> >>> >>>>> 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 discu=
ss
> >>> >>>>> this will only delay things 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 proposal 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