path: root/b9/c3282d430bd041c2095e985d8e61198c5795c3

Return-Path: <eric@voskuil.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3DAD1C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 19:44:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 158CB83716
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 19:44:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 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 Qm2PiyqoEi-o
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 19:44:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com
 [IPv6:2607:f8b0:4864:20::1032])
 by smtp1.osuosl.org (Postfix) with ESMTPS id ABA3883A5E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 19:44:11 +0000 (UTC)
Received: by mail-pj1-x1032.google.com with SMTP id n11so242596pjo.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 12:44:11 -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=2TP4X3uUnyEQ9sC6C/aULkjeEYfFUnyq2RtDLkxZ4Kk=;
 b=AtUgT8BfUQT5fOnrYJV3lwgtWOoIM0pVlvKDG5D58YJD55IONoCdBs5msXDwoA/w7u
 QlL/mAhC96+RGG/PoexUAo9L4N9kHglAQ18DByatmTMp8sAHbe63kgqnO/dPvTMHvYeM
 mYlC/QZtVuaD8sr+vncS0JCxc9MsivHYNXou2XcaDNDH7BXva+THlGiV/ib9oaziUHE9
 Zowsi6AALvOC6K+ynnqkvBtteLNVf3otDQk8QDhufN+jAvtIW6dze+mCz8yyuTp6Cl+V
 wZsZ9jI3nOniqBEwV1akNXedbVTMGUMwUuhJfp2kYoI070mNMBgKr+BhKg75Fk+cNzvw
 rygg==
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=2TP4X3uUnyEQ9sC6C/aULkjeEYfFUnyq2RtDLkxZ4Kk=;
 b=dDJ7eShC817y5fXFbTCcPFVnZdemezXO+9LveAqLZrWghbSwzn8G376zKhAKK2ksZL
 I7vRdp1ZTscDO8MMNzupr7VHyYG/dvgNOmRp0wXFNHPXztsLl6MpiQbCGgvB1eEm2muk
 3HyjLPXpoJczDHti58xMn/Bu1d3swujmRg0xPd2uHILs6GCl6ozdvVWwCc9yGKhldOMT
 JEHznELGf8hky9Rb5hkHoSIzskVN+u60J0Kl5D2ODsFMVIEF/uTA5T9mWSzBUw2Fg3cx
 VG/irFpD70GTSDCT0ltc1/mcSswGoDyDH5yuwj7hphStea9orV5j+MeXx+s8zUA/kc9U
 bM4Q==
X-Gm-Message-State: AOAM533U3xoDXITARaW23sgrwO/kf7cs3eqvDdKgO/a8/yPo7SDYRgxt
 AptUo9clG9Gc/AnalXQg0RH+iBNLyZcUzACr
X-Google-Smtp-Source: ABdhPJxKsdldz7qQNdAKpaM+tNHv7ytOyTYVPUzTmxBNrcwQq79BcbNpothO1H5qcExkWAurg0WDGA==
X-Received: by 2002:a17:90a:ea8b:: with SMTP id
 h11mr532120pjz.122.1624995850771; 
 Tue, 29 Jun 2021 12:44:10 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::da55])
 by smtp.gmail.com with ESMTPSA id a20sm8436976pfo.190.2021.06.29.12.44.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 29 Jun 2021 12:44:10 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 29 Jun 2021 12:44:09 -0700
Message-Id: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
In-Reply-To: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: iPhone Mail (18F72)
X-Mailman-Approved-At: Tue, 29 Jun 2021 21:16:54 +0000
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 19:44:14 -0000


--Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Jun 29, 2021, at 12:28, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>=20
> =EF=BB=BF
> "Confirmation" isn't needed for softforks.

All transactions require confirmation. Splitting does not change this.

Softforks are not compatible without miner enforcement. So soft forking with=
out it has essentially the same effect as hard forking, the chain splits.

> Miners controlling confirmation doesn't mean miners control the rules, the=
y never did.

Please define =E2=80=9Ccontrol=E2=80=9D because these statements hinge on th=
at word. Nobody =E2=80=9Ccontrols=E2=80=9D the rules of others, nor did anyo=
ne claim that to be the case. Majority hash power does have the ability to d=
etermine what gets confirmed. That is the central design principle of proof o=
f work. It takes that decision out of the hands of politicians and places it=
 at the feet of the market.

> Read section 11 of the bitcoin paper "even with a majority of hashrate one=
 cannot arbitrarily change rules or forge signatures.

Never claimed that was the case. One can run any rules that one desires.

> You may say users chosing the rules is "politicial". Isn't miners deciding=
 them for users more political?

No, it=E2=80=99s economic. The largest investment in mining (including highe=
st fees paid to incentivize it) determines censorship resistance.

> Whatever you call it, it is still how free software works: users decide wh=
at to run.

A *person* can run whatever software they want. Money requires that others a=
gree (same rules), and to be money bitcoin requires confirmation.

> It is extremely disappointing to see how few developers seem to ubderstand=
 this, or even care about users deciding or miners not deciding the rules.

It=E2=80=99s poorly understood because there are so many who should know bet=
ter making very misleading statements.

> How can we expect users to understand bitcoin when most developers don't s=
eem to understand it?

Clearly we cannot.

> It is really sad.
>=20
>> On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke@dashjr.org> wrote:
>> >=20
>> > =EF=BB=BFThe only alternative to a split in the problematic scenarios a=
re 1) concede=20
>> > centralised miner control over the network,
>>=20
>> Miners control confirmation, entirely.
>>=20
>> This is the nature of bitcoin. And merchants control validation, entirely=
. Anyone can be a miner or a merchant. Neither is inherently =E2=80=9Cbetter=
=E2=80=9D than the other. The largest merchants are likely a handful of exch=
anges, likely at least as centralized as miners are pooled.
>>=20
>> Splitting does not change this.
>>=20
>> > and 2) have inconsistent=20
>> > enforcement of rules by users who don't agree on what the correct rules=
 are,=20
>>=20
>> There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces=
 determine what network he chooses to participate in.
>>=20
>> > again leading to centralised miner control over the network.
>>=20
>> Leading to? Miners control confirmation, always. Whether that is centrali=
zed, just as with merchanting, is up to individuals.
>>=20
>> > In other words, in this context, accepting a split between disagreeing u=
sers=20
>> > is the ONLY way Bitcoin can possibly continue as a decentralised curren=
cy.
>>=20
>> No, it is not. You are proposing splitting as the method of censorship re=
sistance inherent to Bitcoin. Coordinating this split requires coordinated a=
ction. The whole point of bitcoin is coordinate that action based on mining (=
proof of work). Replacing that with a political process is just a reversion t=
o political money.
>>=20
>> > Making that split as clean and well-defined as possible not only ensure=
s the=20
>> > best opportunity for both sides of the disagreement,
>>=20
>> Trivially accomplished, just change a rule. This isn=E2=80=99t about that=
. It=E2=80=99s about how one gets others to go along with the new coin, or s=
tay with the old. An entirely political process, which is clearly evident fr=
om the campaigns around such attempts.
>>=20
>> > but also minimises the=20
>> > risk that the split occurs at all (since the "losing" side needs to con=
cede,=20
>> > rather than passively continue the disagreement ongoing after the attem=
pted=20
>> > protocol change).
>>=20
>> Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, whic=
h is evident in existing splits.
>>=20
>> e
>>=20
>> > Luke
>> >=20
>> >=20
>> >> 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 a=
bout. That=E2=80=99s
>> >> progress.
>> >>=20
>> >> e
>> >>=20
>> >>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
>> >>>=20
>> >>> =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.
>> >>>=20
>> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud@gmail.com> wr=
ote:
>> >>>> @Luke
>> >>>>=20
>> >>>>> They can still slow it down.
>> >>>>=20
>> >>>> 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 realistical=
ly
>> >>>> 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 wo=
rk
>> >>>> to release bitcoin upgrades. Even if upgrades are never released bef=
ore
>> >>>> it becomes clear that a large supermajority of users want the upgrad=
e,
>> >>>> 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 chai=
n
>> >>>> split during an upgrade when possible. This includes permanent failu=
re
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>=20
>> >>>> This of course does not prevent a UASF-style deployment to be done a=
fter
>> >>>> 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.
>> >>>>=20
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>=20
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow t=
he
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my proposa=
l is
>> >>>> materially different - it is the signaling itself that is trinary, n=
ot
>> >>>> just which chain is being followed. This allows others to know and m=
ake
>> >>>> programmatic decisions (in software) based on that signaling. I'm su=
re
>> >>>> you can agree that does not exist in BIP8.
>> >>>>=20
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>=20
>> >>>> And yet there is miner involvement, as you rightly pointed out. Mine=
rs
>> >>>> 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 yo=
u
>> >>>> mean? Do you mean that signaling of opposition in a block can be don=
e
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>=20
>> >>>> @Jorge
>> >>>>=20
>> >>>>> If different users want different incompatible things... there's no=

>> >>>>> way to avoid the split
>> >>>>=20
>> >>>> I agree. This happened with bcash, and that's fine. It was painful, b=
ut
>> >>>> there were a significant amount of users that disagreed, and they ha=
ve
>> >>>> the chain they want now.
>> >>>>=20
>> >>>> But we generally all want to avoid a chain split when possible. Beca=
use
>> >>>> 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 rathe=
r
>> >>>> than choosing the chain with their preferred rules.
>> >>>>=20
>> >>>> However, the question here is: how do we estimate what fraction of u=
sers
>> >>>> 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 o=
f
>> >>>> inaccuracy. The methods bitcoin has been using is community discussi=
on
>> >>>> and social consensus estimation as well as miner signaling during th=
e
>> >>>> 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,=
 and
>> >>>> why we need to have higher thresholds of success (require larger
>> >>>> supermajorities in both consensus and miner signaling).
>> >>>>=20
>> >>>> Developers obviously care about bitcoin and have an incentive (perso=
nal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to min=
e on
>> >>>> the chain that the economic majority of users is using. But measurin=
g
>> >>>> the consensus of the bitcoin community can be extraordinarily diffic=
ult
>> >>>> to do with consistent accuracy, and so I think miner signaling as it=
 has
>> >>>> been used as a second barrier to entry for an upgrade is quite
>> >>>> appropriate.
>> >>>>=20
>> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@voskuil.org> wro=
te:
>> >>>>> I have not objected to anyone splitting. As I said, a split is alwa=
ys
>> >>>>> possible, and of course has been done on a large scale. It is only t=
he
>> >>>>> misleading statements about inherent soft fork =E2=80=9Ccompatibili=
ty=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.
>> >>>>>=20
>> >>>>> 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 (ma=
ybe =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.
>> >>>>>=20
>> >>>>> The statements below are grossly misleading and need to be called o=
ut
>> >>>>> 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 q=
uestion. The
>> >>>>> question is only how to avoid a split. If one does not care he can
>> >>>>> split at any time, no discussion required.
>> >>>>>=20
>> >>>>> e
>> >>>>>=20
>> >>>>>> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>> >>>>>>=20
>> >>>>>> =EF=BB=BFIf different users want different incompatible things (en=
ough 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.
>> >>>>>>=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 majorit=
y
>> >>>>>>> hash power support.
>> >>>>>>>=20
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people wan=
t.
>> >>>>>>> Given that there is no collective =E2=80=9Cwe=E2=80=9D, those wan=
ts differ. Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it=E2=80=99s a market. One votes by trading.
>> >>>>>>>=20
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is=

>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can mi=
ne,
>> >>>>>>> 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 oth=
er people.
>> >>>>>>> Anyone can mine, and that=E2=80=99s your vote.
>> >>>>>>>=20
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But i=
t=E2=80=99s
>> >>>>>>> dishonest to imply that one can do this and all others will surel=
y
>> >>>>>>> follow. This cannot be known, it=E2=80=99s merely a gamble. And i=
t=E2=80=99s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>=20
>> >>>>>>> e
>> >>>>>>>=20
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrot=
e:
>> >>>>>>>>=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 thi=
s
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>=20
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question i=
s
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does 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@lists.linuxfoundation.org> wrote:
>> >>>>>>>>>=20
>> >>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an up=
grade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>=20
>> >>>>>>>>> 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 successf=
ul
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they=
 do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>=20
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated betwe=
en
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside fr=
om
>> >>>>>>>>> their role as also being users). The miner involvement is only o=
ut
>> >>>>>>>>> of necessity (to set the bit in the header, which users coordin=
ate
>> >>>>>>>>> with) and potentially to accelerate activation by protecting
>> >>>>>>>>> upgrade-lagging users.
>> >>>>>>>>>=20
>> >>>>>>>>> Luke
>> >>>>>>>>>=20
>> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-de=
v
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>=20
>> >>>>>>>>>> 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 shor=
t,
>> >>>>>>>>>> BIP8 LOT=3Dtrue proponents make the point that lazy miners fai=
ling
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfalse proponents make the poin=
t
>> >>>>>>>>>> that LOT=3Dtrue can lead to undesirable forks that might cause=
 a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct an=
d
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/=
blo
>> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades t=
hat
>> >>>>>>>>>> solve both problems.
>> >>>>>>>>>>=20
>> >>>>>>>>>> The proposal uses trinary version signaling rather than binary=

>> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade, t=
his
>> >>>>>>>>>> allows for three signaling states:
>> >>>>>>>>>>=20
>> >>>>>>>>>> * Actively support the change.
>> >>>>>>>>>> * Actively oppose the change.
>> >>>>>>>>>> * Not signaling (neither support or oppose). This is the defau=
lt
>> >>>>>>>>>> state.
>> >>>>>>>>>>=20
>> >>>>>>>>>> Using this additional information, we can release non-contenti=
ous
>> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppos=
e
>> >>>>>>>>>> the change are incentivized to update their software to a vers=
ion
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to loc=
k
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in=

>> >>>>>>>>>> the proposal, this chart shows how much support signaling woul=
d
>> >>>>>>>>>> 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 t=
he
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>=20
>> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if t=
hey
>> >>>>>>>>>> actually oppose the change while at the same time allowing the=
se
>> >>>>>>>>>> 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 read=
y
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to disc=
uss
>> >>>>>>>>>> this will only delay things 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 issue=
s
>> >>>>>>>>>> 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
>> >>>>>>>=20
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >=20

--Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
><blockquote type=3D"cite">On Jun 29, 2021, at 12:28, Jorge Tim=C3=B3n &lt;j=
timon@jtimon.cc&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cit=
e"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">"Confirmation" isn't needed f=
or softforks.</div></div></blockquote><div><br></div><div>All transactions r=
equire confirmation. Splitting does not change this.</div><div><br></div><di=
v>Softforks are not compatible without miner enforcement. So soft forking wi=
thout it has essentially the same effect as hard forking, the chain splits.<=
/div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"auto">Miners=
 controlling confirmation doesn't mean miners control the rules, they never d=
id.</div></div></blockquote><div><br></div><div>Please define =E2=80=9Ccontr=
ol=E2=80=9D because these statements hinge on that word. Nobody =E2=80=9Ccon=
trols=E2=80=9D the rules of others, nor did anyone claim that to be the case=
. Majority hash power does have the ability to determine what gets confirmed=
. That is the central design principle of proof of work. It takes that decis=
ion out of the hands of politicians and places it at the feet of the market.=
</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"auto">Read s=
ection 11 of the bitcoin paper "even with a majority of hashrate one cannot a=
rbitrarily change rules or forge signatures.</div></div></blockquote><div><b=
r></div><div>Never claimed that was the case. One can run any rules that one=
 desires.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"au=
to"><div dir=3D"auto">You may say users chosing the rules is "politicial". I=
sn't miners deciding them for users more political?</div></div></div></block=
quote><div><br></div><div>No, it=E2=80=99s economic. The largest investment i=
n mining (including highest fees paid to incentivize it) determines censorsh=
ip resistance.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D=
"auto"><div dir=3D"auto">Whatever you call it, it is still how free software=
 works: users decide what to run.</div></div></div></blockquote><div><br></d=
iv><div>A *person* can run whatever software they want. Money requires that o=
thers agree (same rules), and to be money bitcoin requires confirmation.</di=
v><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D=
"auto">It is extremely disappointing to see how few developers seem to ubder=
stand this, or even care about users deciding or miners not deciding the rul=
es.</div></div></div></blockquote><div><br></div><div>It=E2=80=99s poorly un=
derstood because there are so many who should know better making very mislea=
ding statements.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div di=
r=3D"auto"><div dir=3D"auto">How can we expect users to understand bitcoin w=
hen most developers don't seem to understand it?</div></div></div></blockquo=
te><div><br></div><div>Clearly we cannot.</div><br><blockquote type=3D"cite"=
><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">It is really sad.</div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Tue, Jun 29, 2021, 19:17 Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.=
org">eric@voskuil.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<br>
&gt; On Jun 29, 2021, at 10:55, Luke Dashjr &lt;<a href=3D"mailto:luke@dashj=
r.org" target=3D"_blank" rel=3D"noreferrer">luke@dashjr.org</a>&gt; wrote:<b=
r>
&gt; <br>
&gt; =EF=BB=BFThe only alternative to a split in the problematic scenarios a=
re 1) concede <br>
&gt; centralised miner control over the network,<br>
<br>
Miners control confirmation, entirely.<br>
<br>
This is the nature of bitcoin. And merchants control validation, entirely. A=
nyone can be a miner or a merchant. Neither is inherently =E2=80=9Cbetter=E2=
=80=9D than the other. The largest merchants are likely a handful of exchang=
es, likely at least as centralized as miners are pooled.<br>
<br>
Splitting does not change this.<br>
<br>
&gt; and 2) have inconsistent <br>
&gt; enforcement of rules by users who don't agree on what the correct rules=
 are, <br>
<br>
There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces de=
termine what network he chooses to participate in.<br>
<br>
&gt; again leading to centralised miner control over the network.<br>
<br>
Leading to? Miners control confirmation, always. Whether that is centralized=
, just as with merchanting, is up to individuals.<br>
<br>
&gt; In other words, in this context, accepting a split between disagreeing u=
sers <br>
&gt; is the ONLY way Bitcoin can possibly continue as a decentralised curren=
cy.<br>
<br>
No, it is not. You are proposing splitting as the method of censorship resis=
tance inherent to Bitcoin. Coordinating this split requires coordinated acti=
on. The whole point of bitcoin is coordinate that action based on mining (pr=
oof of work). Replacing that with a political process is just a reversion to=
 political money.<br>
<br>
&gt; Making that split as clean and well-defined as possible not only ensure=
s the <br>
&gt; best opportunity for both sides of the disagreement,<br>
<br>
Trivially accomplished, just change a rule. This isn=E2=80=99t about that. I=
t=E2=80=99s about how one gets others to go along with the new coin, or stay=
 with the old. An entirely political process, which is clearly evident from t=
he campaigns around such attempts.<br>
<br>
&gt; but also minimises the <br>
&gt; risk that the split occurs at all (since the "losing" side needs to con=
cede, <br>
&gt; rather than passively continue the disagreement ongoing after the attem=
pted <br>
&gt; protocol change).<br>
<br>
Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, which i=
s evident in existing splits.<br>
<br>
e<br>
<br>
&gt; Luke<br>
&gt; <br>
&gt; <br>
&gt;&gt; On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:<br>
&gt;&gt; At least we are now acknowledging that splitting is what it=E2=80=99=
s about. That=E2=80=99s<br>
&gt;&gt; progress.<br>
&gt;&gt; <br>
&gt;&gt; e<br>
&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n &lt;jtimon@jtim=
on.cc&gt; wrote:<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; =EF=BB=BF<br>
&gt;&gt;&gt; I think the option of "permanent failure because miners veto" s=
hould<br>
&gt;&gt;&gt; actually be abandoned. No, I don't think we should avoid splits=
 when<br>
&gt;&gt;&gt; possible, I don't think we should avoid splits at all costs.<br=
>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Sun, Jun 27, 2021, 19:12 Billy Tetrud &lt;<a href=3D"mai=
lto:billy.tetrud@gmail.com" target=3D"_blank" rel=3D"noreferrer">billy.tetru=
d@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; @Luke<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; They can still slow it down.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; Absolutely. However I think that the option of permanent fa=
ilure is<br>
&gt;&gt;&gt;&gt; important. It certainly would be ideal to ensure that enoug=
h bitcoin<br>
&gt;&gt;&gt;&gt; users support the upgrade *before* releasing it, however re=
alistically<br>
&gt;&gt;&gt;&gt; this can never be more than an estimate, and estimates can s=
ometimes be<br>
&gt;&gt;&gt;&gt; wildly wrong. It would be unfortunate if miners had a subst=
antially<br>
&gt;&gt;&gt;&gt; different estimate of user support than the people putting i=
n the work<br>
&gt;&gt;&gt;&gt; to release bitcoin upgrades. Even if upgrades are never rel=
eased before<br>
&gt;&gt;&gt;&gt; it becomes clear that a large supermajority of users want t=
he upgrade,<br>
&gt;&gt;&gt;&gt; if miners don't agree with the estimate a harmful chain spl=
it could<br>
&gt;&gt;&gt;&gt; occur. And I agree with Eric that the goal here is to preve=
nt a chain<br>
&gt;&gt;&gt;&gt; split during an upgrade when possible. This includes perman=
ent failure<br>
&gt;&gt;&gt;&gt; of an upgrade when there is unexpectedly large miner opposi=
tion.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; This of course does not prevent a UASF-style deployment to b=
e done after<br>
&gt;&gt;&gt;&gt; an initial failure to deploy occurs. My proposal is essenti=
ally a<br>
&gt;&gt;&gt;&gt; mechanism to improve upon the speedy-trial idea, allowing f=
or even<br>
&gt;&gt;&gt;&gt; speedier releases (than speedy trial) without adding additi=
onal risk of<br>
&gt;&gt;&gt;&gt; undesired chain splits.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; [BIP8] already has the trinary state you seem to be des=
cribing<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; It sounds like you're saying the trinary state of BIP8 is A=
. Follow the<br>
&gt;&gt;&gt;&gt; longest chain, B. Follow the upgrade chain, or C. follow th=
e<br>
&gt;&gt;&gt;&gt; non-upgraded chain. I agree. However the trinary state in m=
y proposal is<br>
&gt;&gt;&gt;&gt; materially different - it is the signaling itself that is t=
rinary, not<br>
&gt;&gt;&gt;&gt; just which chain is being followed. This allows others to k=
now and make<br>
&gt;&gt;&gt;&gt; programmatic decisions (in software) based on that signalin=
g. I'm sure<br>
&gt;&gt;&gt;&gt; you can agree that does not exist in BIP8.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; No additional bit is needed, as softforks are coordinat=
ed between<br>
&gt;&gt;&gt;&gt;&gt; users, NOT miners<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; And yet there is miner involvement, as you rightly pointed o=
ut. Miners<br>
&gt;&gt;&gt;&gt; are needed to set the nVersion in the header. So when you s=
ay "no<br>
&gt;&gt;&gt;&gt; additional bit is needed", could you please be clearer as t=
o what you<br>
&gt;&gt;&gt;&gt; mean? Do you mean that signaling of opposition in a block c=
an be done<br>
&gt;&gt;&gt;&gt; without any "additional bit"? Or are you just saying that i=
t is<br>
&gt;&gt;&gt;&gt; redundant to consider what miners might be opposing an upgr=
ade?<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; @Jorge<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; If different users want different incompatible things..=
. there's no<br>
&gt;&gt;&gt;&gt;&gt; way to avoid the split<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; I agree. This happened with bcash, and that's fine. It was p=
ainful, but<br>
&gt;&gt;&gt;&gt; there were a significant amount of users that disagreed, an=
d they have<br>
&gt;&gt;&gt;&gt; the chain they want now.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; But we generally all want to avoid a chain split when possi=
ble. Because<br>
&gt;&gt;&gt;&gt; chain splits have a cost, and that cost can be high, its li=
kely that<br>
&gt;&gt;&gt;&gt; many users would rather choose the chain with the most supp=
ort rather<br>
&gt;&gt;&gt;&gt; than choosing the chain with their preferred rules.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; However, the question here is: how do we estimate what frac=
tion of users<br>
&gt;&gt;&gt;&gt; wants which rules? We don't have a divining rod to determin=
e with<br>
&gt;&gt;&gt;&gt; certainty what users want. We can only make polls of variou=
s levels of<br>
&gt;&gt;&gt;&gt; inaccuracy. The methods bitcoin has been using is community=
 discussion<br>
&gt;&gt;&gt;&gt; and social consensus estimation as well as miner signaling d=
uring the<br>
&gt;&gt;&gt;&gt; actual deployment period. Neither of these are perfect, but=
 they are<br>
&gt;&gt;&gt;&gt; both reasonable enough mechanisms. However, because both of=
 these<br>
&gt;&gt;&gt;&gt; mechanisms are very rough estimates of user sentiment, we n=
eed to<br>
&gt;&gt;&gt;&gt; consider the possibility that sometimes the estimate may be=
<br>
&gt;&gt;&gt;&gt; substantially inaccurate when we design deployment procedur=
es. This<br>
&gt;&gt;&gt;&gt; inaccuracy is why we need multiple barriers in place for an=
 upgrade, and<br>
&gt;&gt;&gt;&gt; why we need to have higher thresholds of success (require l=
arger<br>
&gt;&gt;&gt;&gt; supermajorities in both consensus and miner signaling).<br>=

&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; Developers obviously care about bitcoin and have an incenti=
ve (personal<br>
&gt;&gt;&gt;&gt; and probably financial) to do it right. And miners have bot=
h an<br>
&gt;&gt;&gt;&gt; incentive to keep the system healthy, as well as an incenti=
ve to mine on<br>
&gt;&gt;&gt;&gt; the chain that the economic majority of users is using. But=
 measuring<br>
&gt;&gt;&gt;&gt; the consensus of the bitcoin community can be extraordinari=
ly difficult<br>
&gt;&gt;&gt;&gt; to do with consistent accuracy, and so I think miner signal=
ing as it has<br>
&gt;&gt;&gt;&gt; been used as a second barrier to entry for an upgrade is qu=
ite<br>
&gt;&gt;&gt;&gt; appropriate.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil &lt;<a hre=
f=3D"mailto:eric@voskuil.org" target=3D"_blank" rel=3D"noreferrer">eric@vosk=
uil.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; I have not objected to anyone splitting. As I said, a s=
plit is always<br>
&gt;&gt;&gt;&gt;&gt; possible, and of course has been done on a large scale.=
 It is only the<br>
&gt;&gt;&gt;&gt;&gt; misleading statements about inherent soft fork =E2=80=9C=
compatibility=E2=80=9D and the<br>
&gt;&gt;&gt;&gt;&gt; implication that activation without hash power enforcem=
ent does not<br>
&gt;&gt;&gt;&gt;&gt; create a split that I object to. People who know better=
 should be<br>
&gt;&gt;&gt;&gt;&gt; honest about it.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; Far too many people have been led to believe there is s=
ome sort of<br>
&gt;&gt;&gt;&gt;&gt; activation choice with =E2=80=9Censured=E2=80=9D equal o=
utcomes (maybe =E2=80=9Cslowed down=E2=80=9D).<br>
&gt;&gt;&gt;&gt;&gt; There is only a choice between creating a split and has=
h power<br>
&gt;&gt;&gt;&gt;&gt; enforcement. Soft forks are rule changes, and thereby i=
ncompatible -<br>
&gt;&gt;&gt;&gt;&gt; unless enforced by majority hash power.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; The statements below are grossly misleading and need to=
 be called out<br>
&gt;&gt;&gt;&gt;&gt; as such so that people can actually make this decision y=
ou speak of.<br>
&gt;&gt;&gt;&gt;&gt; This idea that =E2=80=9Cusers=E2=80=9D decide the rules=
 is not the question. The<br>
&gt;&gt;&gt;&gt;&gt; question is only how to avoid a split. If one does not c=
are he can<br>
&gt;&gt;&gt;&gt;&gt; split at any time, no discussion required.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt; On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n &lt;jti=
mon@jtimon.cc&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt; =EF=BB=BFIf different users want different incompat=
ible things (enough on<br>
&gt;&gt;&gt;&gt;&gt;&gt; each side), there's no way to avoid the split. We s=
houldn't try to<br>
&gt;&gt;&gt;&gt;&gt;&gt; avoid such a split.<br>
&gt;&gt;&gt;&gt;&gt;&gt; Users decide the rules, not miners nor developers.<=
br>
&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil v=
ia bitcoin-dev<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Ultimately there is only one answer to this que=
stion. Get majority<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; hash power support.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Soft fork enforcement is the same act as any ot=
her censorship<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; enforcement, the difference is only a question o=
f what people want.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Given that there is no collective =E2=80=9Cwe=E2=
=80=9D, those wants differ. Bitcoin<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; resolves this question of conflicting wants, bu=
t it is not a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; democracy, it=E2=80=99s a market. One votes by t=
rading.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; If one wants to enforce a soft fork (or otherwi=
se censor) this is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; accomplished by mining (or paying others to do s=
o). Anyone can mine,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; so everyone gets a say. Mining is trading capit=
al now for more<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; later. If enough people want to do that, they c=
an enforce a soft<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; fork. It=E2=80=99s time Bitcoiners stop thinkin=
g of miners as other people.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Anyone can mine, and that=E2=80=99s your vote.<=
br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Otherwise, as mentioned below, anyone can start=
 a new coin. But it=E2=80=99s<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; dishonest to imply that one can do this and all=
 others will surely<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; follow. This cannot be known, it=E2=80=99s mere=
ly a gamble. And it=E2=80=99s one<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; that has been shown to not always pay off.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Jun 26, 2021, at 14:43, Eric Voskuil=
 &lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank" rel=3D"noreferrer=
">eric@voskuil.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =EF=BB=BFFor some definitions of =E2=80=9Cb=
lock=E2=80=9D.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Without majority hash power support, activa=
tion simply means you<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; are off on a chain split. Anyone can of cou=
rse split off from a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; chain by changing a rule (soft or otherwise=
) at any time, so this<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; is a bit of an empty claim.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Nobody can stop a person from splitting. Th=
e relevant question is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; how to *prevent* a split. And activation wi=
thout majority hash<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; power certainly does not =E2=80=9Censure=E2=
=80=9D this.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Jun 26, 2021, at 14:13, Luke Dashjr v=
ia bitcoin-dev<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =EF=BB=BFBIP8 LOT=3DTrue just ensures m=
iners cannot block an upgrade<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; entirely. They can still slow it down.<=
br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; It also already has the trinary state y=
ou seem to be describing<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (although perhaps this could be better d=
ocumented in the BIP):<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; users who oppose the softfork can and s=
hould treat the successful<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signal (whether MASF or UASF) as invali=
d, thereby ensuring they do<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; not follow a chain with the rules in fo=
rce.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; No additional bit is needed, as softfor=
ks are coordinated between<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; users, NOT miners (who have no particul=
ar say in them, aside from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; their role as also being users). The mi=
ner involvement is only out<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; of necessity (to set the bit in the hea=
der, which users coordinate<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; with) and potentially to accelerate act=
ivation by protecting<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; upgrade-lagging users.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Luke<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Saturday 26 June 2021 20:21:=
52 Billy Tetrud via bitcoin-dev<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Given the recent controversy over u=
pgrade mechanisms for the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; non-controversial taproot upgrade, I=
 have been thinking about<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ways to solve the problems that bot=
h sides brought up. In short,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; BIP8 LOT=3Dtrue proponents make the=
 point that lazy miners failing<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to upgrade in a timely manner slow d=
own releases of bitcoin<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; upgrades, and BIP9 / BIP8 LOT=3Dfal=
se proponents make the point<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that LOT=3Dtrue can lead to undesir=
able forks that might cause a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; lot of chaos. I believe both points=
 are essentially correct and<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; have created a proposal<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"https://github.com/f=
resheneesz/bip-trinary-version-signaling/blo" rel=3D"noreferrer noreferrer" t=
arget=3D"_blank">https://github.com/fresheneesz/bip-trinary-version-signalin=
g/blo</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; b/master/b ip-trinary-version-bits.=
md&gt; for soft fork upgrades that<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; solve both problems.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; The proposal uses trinary version s=
ignaling rather than binary<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signaling. For any particular prosp=
ective soft fork upgrade, this<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; allows for three signaling states:<=
br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; * Actively support the change.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; * Actively oppose the change.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; * Not signaling (neither support or=
 oppose). This is the default<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; state.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Using this additional information, w=
e can release non-contentious<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; upgrades much quicker (with a much l=
ower percent of miners<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signaling support). For contentious=
 upgrades, miners who oppose<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the change are incentivized to upda=
te their software to a version<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that can actively signal opposition=
 to the change. The more<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; opposition there is, the higher the=
 threshold necessary to lock<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; in the upgrade. With the parameters=
 I currently recommended in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the proposal, this chart shows how m=
uch support signaling would<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; be necessary given a particular amo=
unt of active opposition<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signaling:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; [image: thresholdChart.png]<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; If literally no one signals opposit=
ion, a 60% threshold should be<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; relatively safe because it is a sup=
ermajority amount that is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; unlikely to change significantly ve=
ry quickly (ie if 60% of<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; miners support the change today, it=
s unlikely that less than a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; majority of miners would support th=
e change a year or two from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; now), and if no one is signaling op=
position, chances are that the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; vast majority of the other 40% woul=
d also eventually signal<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; support.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; This both gives an incentive for "l=
azy" miners to upgrade if they<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; actually oppose the change while at=
 the same time allowing these<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; lazy miners to remain lazy without s=
lowing down the soft fork<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; activation much.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I think now is the right time to di=
scuss new soft fork upgrade<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mechanisms, when there are no press=
ing soft fork upgrades ready<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to deploy. Waiting until we need to=
 deploy a soft fork to discuss<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; this will only delay things and cau=
se contention again like it<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; did with taproot.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I'm very curious to know what peopl=
e think of this mechanism. I<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; would appreciate any comments here,=
 or written as github issues<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; on the proposal repo itself.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; BT<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________=
________<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.lin=
uxfoundation.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><b=
r>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________=
<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfounda=
tion.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249--