path: root/be/2f62f9ba9bf85330a7690667e113ae5a3e1e4c

Return-Path: <zachgrw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B19F1C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 06:39:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8180783AA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 06:39:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 9Ah2mRY6pge1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 06:39:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com
 [IPv6:2607:f8b0:4864:20::133])
 by smtp1.osuosl.org (Postfix) with ESMTPS id EB31C83934
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 06:39:52 +0000 (UTC)
Received: by mail-il1-x133.google.com with SMTP id a11so1884651ilf.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 23:39:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=J4eHvHsqhizKxK/pg+euUm3pACclCMM7oml4cV6+FLg=;
 b=lW7gJgYQ3nOFyN7W7fGeMY+CmqAaEi/NfGGJQ2rQwvMH0WEXmwk831odZpCSwUgchL
 aISVAlsp4jFZUkxdgayuq4K4xt2IL/uLmdv2mgKC+NO9Vkl2hx4i2hGIwV6mnfIX9d1+
 xA7CDCAsOPBSCHwnHZj1fLFx14QRdN6gq+ZzhnTLAgFHbja9x2ieairyw8hRnZBvvDIm
 9Pnn4HZohVjuqbJXOYm4yrDMHJ1yHSvGr+xfH14TZfK86iH2kcorZTUjAC9U8d7YlRIg
 //uUp0Cve+NYqBWKxtkYEl/3PGWRhnu/I8/+Ht/vU2rkKeuCm/1avVVPxu4VEfNYytIq
 7DLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=J4eHvHsqhizKxK/pg+euUm3pACclCMM7oml4cV6+FLg=;
 b=aKVX9rL4F9zum6d0RlLL1/+TspRGQx9CL1q1UnTEuBeUysbX7YFSN8vnDZHwqJFQsB
 FYp4FUig1XEPP0+2imTvr5SBR17K/kGxoiAIr+6m/jkC8ar2kOk/Xv7ambzyvRcPgq0j
 WjUK67TxeFkchMqC8hMSMKNxGsA8Ejgq6AAytn7KbEIYaCB33PgY08udoyJyqp4bsmGy
 T4xgRqkDuowZVtMJ7rgl9NwHPbCkMdKgSiS4iFbTmAwpAkGCIG9Ha6tkNMWbWJUJw9xN
 /HpQpfK4EjAcyR/ha0KpApEHNtF2FK6ojVLHGSy8W20xBVZI/OVqIZf/WZPumTL9D4KC
 yqAg==
X-Gm-Message-State: AOAM532hJlYad0M8qsYHRcX/B66tYB0Gh9MPe9dnlfcaGvYqdL2CPSWN
 Nkql/KYTSpZ4b6bgYZdYOtNNtAu6ZzQW1crsPTY2uoNk
X-Google-Smtp-Source: ABdhPJzEwTwb5G3i3YxA6kz1p+w2sVwb4jQ17kBUQOgIio5LDHvFrrAimkGEruDLw20OplwXpd+Z4D1sfvcveJ1G6wM=
X-Received: by 2002:a05:6e02:156a:: with SMTP id
 k10mr25131421ilu.111.1625035191951; 
 Tue, 29 Jun 2021 23:39:51 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
 <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
In-Reply-To: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Wed, 30 Jun 2021 08:39:41 +0200
Message-ID: <CAJ4-pECPi8Hfn6+=-_=dGPejXx9CSnZcJwQAqrw5qd8vavOA5w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="0000000000005d25ae05c5f5fdc3"
X-Mailman-Approved-At: Wed, 30 Jun 2021 08:11:56 +0000
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: Wed, 30 Jun 2021 06:39:55 -0000

--0000000000005d25ae05c5f5fdc3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Majority hash power does have the ability to determine what gets
confirmed.

Miners don=E2=80=99t have the ability to decide whether a block is valid.

Hash power is only recognized as such if it is used for creating a valid
block, i.e., a block that strictly follows all the rules as set by the node
software that transacting users choose to run.

If suddenly 70% of all hash power decided to start mining blocks that are
invalid according to the rules set in the users=E2=80=99 software, then the=
se
invalid blocks will be disregarded. From a user perspective, 70% of all
hash power will seem to have disappeared.

In short, users define what is Bitcoin, not miners. This is fundamental to
being decentralized.



On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
> =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
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define =E2=80=9Ccontrol=E2=80=9D because these statements hinge on=
 that word.
> Nobody =E2=80=9Ccontrols=E2=80=9D the rules of others, nor did anyone cla=
im 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 take=
s
> that decision out of the hands of politicians and places it at the feet o=
f
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate on=
e
> 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 decidin=
g
> them for users more political?
>
>
> No, it=E2=80=99s economic. The largest investment in mining (including hi=
ghest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that other=
s
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstan=
d
> 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 =
better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric@voskuil.org> wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke@dashjr.org> wrote:
>> >
>> > =EF=BB=BFThe only alternative to a split in the problematic scenarios =
are 1)
>> concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> 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 likel=
y a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rule=
s
>> are,
>>
>> There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforce=
s determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. 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 to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn=E2=80=99t about tha=
t. It=E2=80=99s
>> about how one gets others to go along with the new coin, or stay with th=
e
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, whi=
ch is evident in
>> existing splits.
>>
>> e
>>
>> > 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=
 about.
>> That=E2=80=99s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>> >>>
>> >>> =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>
>> wrote:
>> >>>> @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 bitcoi=
n
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometime=
s
>> 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 cha=
in
>> >>>> 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
>> after
>> >>>> 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 ris=
k
>> 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 y=
ou
>> >>>> mean? Do you mean that signaling of opposition in a block can be do=
ne
>> >>>> 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 n=
o
>> >>>>> 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 tha=
t
>> >>>> many users would rather choose the chain with the most support rath=
er
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> users
>> >>>> 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 t=
he
>> >>>> actual deployment period. Neither of these are perfect, but they ar=
e
>> >>>> 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).
>> >>>>
>> >>>> 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 measuri=
ng
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> to do with consistent accuracy, and so I think miner signaling as i=
t
>> has
>> >>>> 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=9Ccompatibil=
ity=E2=80=9D and
>> the
>> >>>>> implication that activation without hash power enforcement does no=
t
>> >>>>> 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 (m=
aybe =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 o=
f.
>> >>>>> This idea that =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> wr=
ote:
>> >>>>>>
>> >>>>>> =EF=BB=BFIf different users want different incompatible things (e=
nough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try t=
o
>> >>>>>> 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 majori=
ty
>> >>>>>>> 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 wa=
nts 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 i=
s
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> mine,
>> >>>>>>> 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 ot=
her
>> 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 sure=
ly
>> >>>>>>> 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 yo=
u
>> >>>>>>>> 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 th=
is
>> >>>>>>>> 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 u=
pgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describin=
g
>> >>>>>>>>> (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 the=
y
>> 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
>> out
>> >>>>>>>>> of necessity (to set the bit in the header, which users
>> coordinate
>> >>>>>>>>> with) and potentially to accelerate activation by protecting
>> >>>>>>>>> upgrade-lagging users.
>> >>>>>>>>>
>> >>>>>>>>> Luke
>> >>>>>>>>>
>> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-d=
ev
>> >>>>>>>>>>> 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
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfalse proponents make the poi=
nt
>> >>>>>>>>>> that LOT=3Dtrue can lead to undesirable forks that might caus=
e a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct a=
nd
>> >>>>>>>>>> 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
>> that
>> >>>>>>>>>> solve both problems.
>> >>>>>>>>>>
>> >>>>>>>>>> The proposal uses trinary version signaling rather than binar=
y
>> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade,
>> this
>> >>>>>>>>>> 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-contentious
>> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppo=
se
>> >>>>>>>>>> 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 lo=
ck
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended i=
n
>> >>>>>>>>>> the proposal, this chart shows how much support signaling wou=
ld
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold shoul=
d
>> 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 fro=
m
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if
>> they
>> >>>>>>>>>> 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 upgrad=
e
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades rea=
dy
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like i=
t
>> >>>>>>>>>> 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 issu=
es
>> >>>>>>>>>> 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
>> >
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000005d25ae05c5f5fdc3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">&gt;=C2=A0<span style=3D"color:rgb(0,0,0)">Majority hash =
power does have the ability to determine what gets confirmed.</span></div><=
div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div dir=
=3D"auto"><span style=3D"color:rgb(0,0,0)">Miners don=E2=80=99t have the ab=
ility to decide whether a block is valid.</span></div><div dir=3D"auto"><sp=
an style=3D"color:rgb(0,0,0)"><br></span></div><div style=3D"background-col=
or:rgba(0,0,0,0)!important;border-color:rgb(255,255,255)!important;color:rg=
b(255,255,255)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Has=
h power is only recognized as such if it is used for creating a valid block=
, i.e., a block that strictly follows all the rules as set by the node soft=
ware that transacting users choose to run.</font></div><div style=3D"backgr=
ound-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><font =
style=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"background-color:=
rgba(0,0,0,0)!important;border-color:rgb(32,33,36)!important;color:rgb(255,=
255,255)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">If sudden=
ly 70% of all hash power decided to start mining blocks that are invalid ac=
cording to the rules set in the users=E2=80=99 software, then these invalid=
 blocks will be disregarded. From a user perspective, 70% of all hash power=
 will seem to have disappeared.</font></div><div style=3D"background-color:=
rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color=
:rgb(0,0,0)"><br></font></div><div style=3D"background-color:rgba(0,0,0,0)!=
important;border-color:rgb(222,223,227)!important;color:rgb(255,255,255)!im=
portant" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">In short, users defi=
ne what is Bitcoin, not miners. This is fundamental to being decentralized.=
</font></div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span>=
</div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;paddin=
g-left:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"auto"><div dir=
=3D"ltr"><br></div><div dir=3D"ltr"><blockquote type=3D"cite">On Jun 29, 20=
21, at 12:28, Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; wrote:<br><br></blo=
ckquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=
=3D"auto">&quot;Confirmation&quot; isn&#39;t needed for softforks.</div></d=
iv></blockquote><div><br></div><div>All transactions require confirmation. =
Splitting does not change this.</div><div><br></div><div>Softforks are not =
compatible without miner enforcement. So soft forking without it has essent=
ially the same effect as hard forking, the chain splits.</div><br><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div dir=3D"auto">Miners controlling conf=
irmation doesn&#39;t mean miners control the rules, they never did.</div></=
div></blockquote><div><br></div><div>Please define =E2=80=9Ccontrol=E2=80=
=9D because these statements hinge on that word. Nobody =E2=80=9Ccontrols=
=E2=80=9D the rules of others, nor did anyone claim that to be the case. Ma=
jority hash power does have the ability to determine what gets confirmed. T=
hat is the central design principle of proof of work. It takes that decisio=
n 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 =
section 11 of the bitcoin paper &quot;even with a majority of hashrate one =
cannot arbitrarily change rules or forge signatures.</div></div></blockquot=
e><div><br></div><div>Never claimed that was the case. One can run any rule=
s that one desires.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><di=
v dir=3D"auto"><div dir=3D"auto">You may say users chosing the rules is &qu=
ot;politicial&quot;. Isn&#39;t miners deciding them for users more politica=
l?</div></div></div></blockquote><div><br></div><div>No, it=E2=80=99s econo=
mic. The largest investment in mining (including highest fees paid to incen=
tivize it) determines censorship resistance.</div><br><blockquote type=3D"c=
ite"><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></div><div>A *person* can run whatever soft=
ware they want. Money requires that others agree (same rules), and to be mo=
ney bitcoin requires confirmation.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">It is extremely disappointi=
ng to see how few developers seem to ubderstand this, or even care about us=
ers deciding or miners not deciding the rules.</div></div></div></blockquot=
e><div><br></div><div>It=E2=80=99s poorly understood because there are so m=
any who should know better making very misleading statements.</div><br><blo=
ckquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">=
How can we expect users to understand bitcoin when most developers don&#39;=
t seem to understand it?</div></div></div></blockquote><div><br></div><div>=
Clearly we cannot.</div></div><div dir=3D"auto"><br><blockquote type=3D"cit=
e"><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_at=
tr">On Tue, Jun 29, 2021, 19:17 Eric Voskuil &lt;<a href=3D"mailto:eric@vos=
kuil.org" target=3D"_blank">eric@voskuil.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204=
,204,204)"><br>
&gt; On Jun 29, 2021, at 10:55, Luke Dashjr &lt;<a href=3D"mailto:luke@dash=
jr.org" rel=3D"noreferrer" target=3D"_blank">luke@dashjr.org</a>&gt; wrote:=
<br>
&gt; <br>
&gt; =EF=BB=BFThe only alternative to a split in the problematic scenarios =
are 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. =
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 exc=
hanges, 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&#39;t agree on what the correct =
rules are, <br>
<br>
There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces d=
etermine 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 centralize=
d, just as with merchanting, is up to individuals.<br>
<br>
&gt; In other words, in this context, accepting a split between disagreeing=
 users <br>
&gt; is the ONLY way Bitcoin can possibly continue as a decentralised curre=
ncy.<br>
<br>
No, it is not. You are proposing splitting as the method of censorship resi=
stance inherent to Bitcoin. Coordinating this split requires coordinated ac=
tion. The whole point of bitcoin is coordinate that action based on mining =
(proof of work). Replacing that with a political process is just a reversio=
n to political money.<br>
<br>
&gt; Making that split as clean and well-defined as possible not only ensur=
es 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. =
It=E2=80=99s about how one gets others to go along with the new coin, or st=
ay with the old. An entirely political process, which is clearly evident fr=
om the campaigns around such attempts.<br>
<br>
&gt; but also minimises the <br>
&gt; risk that the split occurs at all (since the &quot;losing&quot; side n=
eeds to concede, <br>
&gt; rather than passively continue the disagreement ongoing after the atte=
mpted <br>
&gt; protocol change).<br>
<br>
Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, which =
is 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=
=99s 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@jti=
mon.cc&gt; wrote:<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; =EF=BB=BF<br>
&gt;&gt;&gt; I think the option of &quot;permanent failure because miners v=
eto&quot; should<br>
&gt;&gt;&gt; actually be abandoned. No, I don&#39;t think we should avoid s=
plits when<br>
&gt;&gt;&gt; possible, I don&#39;t think we should avoid splits at all cost=
s.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Sun, Jun 27, 2021, 19:12 Billy Tetrud &lt;<a href=3D"ma=
ilto:billy.tetrud@gmail.com" rel=3D"noreferrer" target=3D"_blank">billy.tet=
rud@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 f=
ailure is<br>
&gt;&gt;&gt;&gt; important. It certainly would be ideal to ensure that enou=
gh bitcoin<br>
&gt;&gt;&gt;&gt; users support the upgrade *before* releasing it, however r=
ealistically<br>
&gt;&gt;&gt;&gt; this can never be more than an estimate, and estimates can=
 sometimes be<br>
&gt;&gt;&gt;&gt; wildly wrong. It would be unfortunate if miners had a subs=
tantially<br>
&gt;&gt;&gt;&gt; different estimate of user support than the people putting=
 in the work<br>
&gt;&gt;&gt;&gt; to release bitcoin upgrades. Even if upgrades are never re=
leased before<br>
&gt;&gt;&gt;&gt; it becomes clear that a large supermajority of users want =
the upgrade,<br>
&gt;&gt;&gt;&gt; if miners don&#39;t agree with the estimate a harmful chai=
n split could<br>
&gt;&gt;&gt;&gt; occur. And I agree with Eric that the goal here is to prev=
ent a chain<br>
&gt;&gt;&gt;&gt; split during an upgrade when possible. This includes perma=
nent failure<br>
&gt;&gt;&gt;&gt; of an upgrade when there is unexpectedly large miner oppos=
ition.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; This of course does not prevent a UASF-style deployment to=
 be done after<br>
&gt;&gt;&gt;&gt; an initial failure to deploy occurs. My proposal is essent=
ially a<br>
&gt;&gt;&gt;&gt; mechanism to improve upon the speedy-trial idea, allowing =
for even<br>
&gt;&gt;&gt;&gt; speedier releases (than speedy trial) without adding addit=
ional 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 de=
scribing<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; It sounds like you&#39;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 t=
he<br>
&gt;&gt;&gt;&gt; non-upgraded chain. I agree. However the trinary state in =
my proposal is<br>
&gt;&gt;&gt;&gt; materially different - it is the signaling itself that is =
trinary, not<br>
&gt;&gt;&gt;&gt; just which chain is being followed. This allows others to =
know and make<br>
&gt;&gt;&gt;&gt; programmatic decisions (in software) based on that signali=
ng. I&#39;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 coordina=
ted 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=
 out. Miners<br>
&gt;&gt;&gt;&gt; are needed to set the nVersion in the header. So when you =
say &quot;no<br>
&gt;&gt;&gt;&gt; additional bit is needed&quot;, could you please be cleare=
r as to what you<br>
&gt;&gt;&gt;&gt; mean? Do you mean that signaling of opposition in a block =
can be done<br>
&gt;&gt;&gt;&gt; without any &quot;additional bit&quot;? Or are you just sa=
ying that it is<br>
&gt;&gt;&gt;&gt; redundant to consider what miners might be opposing an upg=
rade?<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&#39;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&#39;s fine. It=
 was painful, but<br>
&gt;&gt;&gt;&gt; there were a significant amount of users that disagreed, a=
nd 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 poss=
ible. Because<br>
&gt;&gt;&gt;&gt; chain splits have a cost, and that cost can be high, its l=
ikely that<br>
&gt;&gt;&gt;&gt; many users would rather choose the chain with the most sup=
port 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 fra=
ction of users<br>
&gt;&gt;&gt;&gt; wants which rules? We don&#39;t have a divining rod to det=
ermine with<br>
&gt;&gt;&gt;&gt; certainty what users want. We can only make polls of vario=
us levels of<br>
&gt;&gt;&gt;&gt; inaccuracy. The methods bitcoin has been using is communit=
y discussion<br>
&gt;&gt;&gt;&gt; and social consensus estimation as well as miner signaling=
 during the<br>
&gt;&gt;&gt;&gt; actual deployment period. Neither of these are perfect, bu=
t they are<br>
&gt;&gt;&gt;&gt; both reasonable enough mechanisms. However, because both o=
f these<br>
&gt;&gt;&gt;&gt; mechanisms are very rough estimates of user sentiment, we =
need to<br>
&gt;&gt;&gt;&gt; consider the possibility that sometimes the estimate may b=
e<br>
&gt;&gt;&gt;&gt; substantially inaccurate when we design deployment procedu=
res. This<br>
&gt;&gt;&gt;&gt; inaccuracy is why we need multiple barriers in place for a=
n upgrade, and<br>
&gt;&gt;&gt;&gt; why we need to have higher thresholds of success (require =
larger<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 incent=
ive (personal<br>
&gt;&gt;&gt;&gt; and probably financial) to do it right. And miners have bo=
th an<br>
&gt;&gt;&gt;&gt; incentive to keep the system healthy, as well as an incent=
ive to mine on<br>
&gt;&gt;&gt;&gt; the chain that the economic majority of users is using. Bu=
t measuring<br>
&gt;&gt;&gt;&gt; the consensus of the bitcoin community can be extraordinar=
ily difficult<br>
&gt;&gt;&gt;&gt; to do with consistent accuracy, and so I think miner signa=
ling as it has<br>
&gt;&gt;&gt;&gt; been used as a second barrier to entry for an upgrade is q=
uite<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 hr=
ef=3D"mailto:eric@voskuil.org" rel=3D"noreferrer" target=3D"_blank">eric@vo=
skuil.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; I have not objected to anyone splitting. As I said, a =
split 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=
=9Ccompatibility=E2=80=9D and the<br>
&gt;&gt;&gt;&gt;&gt; implication that activation without hash power enforce=
ment does not<br>
&gt;&gt;&gt;&gt;&gt; create a split that I object to. People who know bette=
r 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 =
some sort of<br>
&gt;&gt;&gt;&gt;&gt; activation choice with =E2=80=9Censured=E2=80=9D equal=
 outcomes (maybe =E2=80=9Cslowed down=E2=80=9D).<br>
&gt;&gt;&gt;&gt;&gt; There is only a choice between creating a split and ha=
sh power<br>
&gt;&gt;&gt;&gt;&gt; enforcement. Soft forks are rule changes, and thereby =
incompatible -<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 t=
o be called out<br>
&gt;&gt;&gt;&gt;&gt; as such so that people can actually make this decision=
 you speak of.<br>
&gt;&gt;&gt;&gt;&gt; This idea that =E2=80=9Cusers=E2=80=9D decide the rule=
s is not the question. The<br>
&gt;&gt;&gt;&gt;&gt; question is only how to avoid a split. If one does not=
 care 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;jt=
imon@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 incompa=
tible things (enough on<br>
&gt;&gt;&gt;&gt;&gt;&gt; each side), there&#39;s no way to avoid the split.=
 We shouldn&#39;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 =
via bitcoin-dev<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.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 qu=
estion. 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 o=
ther censorship<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; enforcement, the difference is only a question=
 of 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, b=
ut it is not a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; democracy, it=E2=80=99s a market. One votes by=
 trading.<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 otherw=
ise censor) this is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; accomplished by mining (or paying others to do=
 so). Anyone can mine,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; so everyone gets a say. Mining is trading capi=
tal now for more<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; later. If enough people want to do that, they =
can enforce a soft<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; fork. It=E2=80=99s time Bitcoiners stop thinki=
ng 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 star=
t 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 al=
l others will surely<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; follow. This cannot be known, it=E2=80=99s mer=
ely 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 Voskui=
l &lt;<a href=3D"mailto:eric@voskuil.org" rel=3D"noreferrer" target=3D"_bla=
nk">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=9C=
block=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, activ=
ation simply means you<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; are off on a chain split. Anyone can of co=
urse split off from a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; chain by changing a rule (soft or otherwis=
e) 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. T=
he relevant question is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; how to *prevent* a split. And activation w=
ithout 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=
 via bitcoin-dev<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lis=
ts.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 =
miners 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 =
you seem to be describing<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (although perhaps this could be better=
 documented in the BIP):<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; users who oppose the softfork can and =
should treat the successful<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signal (whether MASF or UASF) as inval=
id, thereby ensuring they do<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; not follow a chain with the rules in f=
orce.<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 softfo=
rks are coordinated between<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; users, NOT miners (who have no particu=
lar say in them, aside from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; their role as also being users). The m=
iner involvement is only out<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; of necessity (to set the bit in the he=
ader, which users coordinate<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; with) and potentially to accelerate ac=
tivation 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 =
upgrade 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 bo=
th sides brought up. In short,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; BIP8 LOT=3Dtrue proponents make th=
e point that lazy miners failing<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to upgrade in a timely manner slow=
 down releases of bitcoin<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; upgrades, and BIP9 / BIP8 LOT=3Dfa=
lse proponents make the point<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that LOT=3Dtrue can lead to undesi=
rable forks that might cause a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; lot of chaos. I believe both point=
s 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/=
fresheneesz/bip-trinary-version-signaling/blo" rel=3D"noreferrer noreferrer=
" target=3D"_blank">https://github.com/fresheneesz/bip-trinary-version-sign=
aling/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 =
signaling rather than binary<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signaling. For any particular pros=
pective 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 o=
r 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,=
 we can release non-contentious<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; upgrades much quicker (with a much=
 lower percent of miners<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; signaling support). For contentiou=
s upgrades, miners who oppose<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the change are incentivized to upd=
ate their software to a version<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that can actively signal oppositio=
n to the change. The more<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; opposition there is, the higher th=
e threshold necessary to lock<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; in the upgrade. With the parameter=
s I currently recommended in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the proposal, this chart shows how=
 much support signaling would<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; be necessary given a particular am=
ount 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 opposi=
tion, a 60% threshold should be<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; relatively safe because it is a su=
permajority amount that is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; unlikely to change significantly v=
ery quickly (ie if 60% of<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; miners support the change today, i=
ts unlikely that less than a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; majority of miners would support t=
he change a year or two from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; now), and if no one is signaling o=
pposition, chances are that the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; vast majority of the other 40% wou=
ld 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 &=
quot;lazy&quot; miners to upgrade if they<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; actually oppose the change while a=
t the same time allowing these<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; lazy miners to remain lazy without=
 slowing 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 d=
iscuss new soft fork upgrade<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mechanisms, when there are no pres=
sing soft fork upgrades ready<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to deploy. Waiting until we need t=
o deploy a soft fork to discuss<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; this will only delay things and ca=
use 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&#39;m very curious to know what =
people 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.li=
nuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br>
&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.linuxfound=
ation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/m=
ailman/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></div>_______________________________________________<br=
>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000005d25ae05c5f5fdc3--