[bitcoin-dev] Trinary Version Signaling for softfork upgrades

[bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud]

[-- Attachment #1.1: Type: text/plain, Size: 2688 bytes --]

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=true proponents
make the point that lazy miners failing to upgrade in a timely manner slow
down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
proponents make the point that LOT=true can lead to undesirable forks that
might cause a lot of chaos. I believe both points are essentially correct
and have created a proposal
<https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/bip-trinary-version-bits.md>
for soft fork upgrades that solve both problems.

The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
update their software to a version that can actively signal opposition to
the change. The more opposition there is, the higher the threshold
necessary to lock in the upgrade. With the parameters I currently
recommended in the proposal, this chart shows how much support signaling
would be necessary given a particular amount of active opposition signaling:

[image: thresholdChart.png]
If literally no one signals opposition, a 60% threshold should be
relatively safe because it is a supermajority amount that is unlikely to
change significantly very quickly (ie if 60% of miners support the change
today, its unlikely that less than a majority of miners would support the
change a year or two from now), and if no one is signaling opposition,
chances are that the vast majority of the other 40% would also eventually
signal support.

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 upgrade mechanisms,
when there are no pressing soft fork upgrades ready to deploy. Waiting
until we need to deploy a soft fork to discuss this will only delay things
and cause contention again like it did with taproot.

I'm very curious to know what people think of this mechanism. I would
appreciate any comments here, or written as github issues on the proposal
repo itself.

Thanks,
BT

[-- Attachment #1.2: Type: text/html, Size: 3069 bytes --]

[-- Attachment #2: thresholdChart.png --]
[-- Type: image/png, Size: 11132 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr]

BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can 
still slow it down.

It also already has the trinary state you seem to be describing (although 
perhaps this could be better documented in the BIP): users who oppose the 
softfork can and should treat the successful signal (whether MASF or UASF) as 
invalid, thereby ensuring they do not follow a chain with the rules in force.

No additional bit is needed, as softforks are coordinated between users, NOT 
miners (who have no particular say in them, aside from their role as also 
being users). The miner involvement is only 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-dev wrote:
> Given the recent controversy over upgrade mechanisms for the
> non-controversial taproot upgrade, I have been thinking about ways to solve
> the problems that both sides brought up. In short, BIP8 LOT=true proponents
> make the point that lazy miners failing to upgrade in a timely manner slow
> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> proponents make the point that LOT=true can lead to undesirable forks that
> might cause a lot of chaos. I believe both points are essentially correct
> and have created a proposal
> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>
> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
> update their software to a version that can actively signal opposition to
> the change. The more opposition there is, the higher the threshold
> necessary to lock in the upgrade. With the parameters I currently
> recommended in the proposal, this chart shows how much support signaling
> would be necessary given a particular amount of active opposition
> signaling:
>
> [image: thresholdChart.png]
> If literally no one signals opposition, a 60% threshold should be
> relatively safe because it is a supermajority amount that is unlikely to
> change significantly very quickly (ie if 60% of miners support the change
> today, its unlikely that less than a majority of miners would support the
> change a year or two from now), and if no one is signaling opposition,
> chances are that the vast majority of the other 40% would also eventually
> signal support.
>
> 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 upgrade mechanisms,
> when there are no pressing soft fork upgrades ready to deploy. Waiting
> until we need to deploy a soft fork to discuss this will only delay things
> and cause contention again like it did with taproot.
>
> I'm very curious to know what people think of this mechanism. I would
> appreciate any comments here, or written as github issues on the proposal
> repo itself.
>
> Thanks,
> BT

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

For some definitions of “block”.

Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.

Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.

e

> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can 
> still slow it down.
> 
> It also already has the trinary state you seem to be describing (although 
> perhaps this could be better documented in the BIP): users who oppose the 
> softfork can and should treat the successful signal (whether MASF or UASF) as 
> invalid, thereby ensuring they do not follow a chain with the rules in force.
> 
> No additional bit is needed, as softforks are coordinated between users, NOT 
> miners (who have no particular say in them, aside from their role as also 
> being users). The miner involvement is only 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-dev wrote:
>> Given the recent controversy over upgrade mechanisms for the
>> non-controversial taproot upgrade, I have been thinking about ways to solve
>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>> make the point that lazy miners failing to upgrade in a timely manner slow
>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>> proponents make the point that LOT=true can lead to undesirable forks that
>> might cause a lot of chaos. I believe both points are essentially correct
>> and have created a proposal
>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>> 
>> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
>> update their software to a version that can actively signal opposition to
>> the change. The more opposition there is, the higher the threshold
>> necessary to lock in the upgrade. With the parameters I currently
>> recommended in the proposal, this chart shows how much support signaling
>> would be necessary given a particular amount of active opposition
>> signaling:
>> 
>> [image: thresholdChart.png]
>> If literally no one signals opposition, a 60% threshold should be
>> relatively safe because it is a supermajority amount that is unlikely to
>> change significantly very quickly (ie if 60% of miners support the change
>> today, its unlikely that less than a majority of miners would support the
>> change a year or two from now), and if no one is signaling opposition,
>> chances are that the vast majority of the other 40% would also eventually
>> signal support.
>> 
>> 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 upgrade mechanisms,
>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>> until we need to deploy a soft fork to discuss this will only delay things
>> and cause contention again like it did with taproot.
>> 
>> I'm very curious to know what people think of this mechanism. I would
>> appreciate any comments here, or written as github issues on the proposal
>> repo itself.
>> 
>> Thanks,
>> BT
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

Ultimately there is only one answer to this question. Get majority hash power support.

Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.

If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.

Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.

e

> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
> 
> For some definitions of “block”.
> 
> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
> 
> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
> 
> e
> 
>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 
>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can 
>> still slow it down.
>> 
>> It also already has the trinary state you seem to be describing (although 
>> perhaps this could be better documented in the BIP): users who oppose the 
>> softfork can and should treat the successful signal (whether MASF or UASF) as 
>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>> 
>> No additional bit is needed, as softforks are coordinated between users, NOT 
>> miners (who have no particular say in them, aside from their role as also 
>> being users). The miner involvement is only 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-dev wrote:
>>> Given the recent controversy over upgrade mechanisms for the
>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>> proponents make the point that LOT=true can lead to undesirable forks that
>>> might cause a lot of chaos. I believe both points are essentially correct
>>> and have created a proposal
>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>> 
>>> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
>>> update their software to a version that can actively signal opposition to
>>> the change. The more opposition there is, the higher the threshold
>>> necessary to lock in the upgrade. With the parameters I currently
>>> recommended in the proposal, this chart shows how much support signaling
>>> would be necessary given a particular amount of active opposition
>>> signaling:
>>> 
>>> [image: thresholdChart.png]
>>> If literally no one signals opposition, a 60% threshold should be
>>> relatively safe because it is a supermajority amount that is unlikely to
>>> change significantly very quickly (ie if 60% of miners support the change
>>> today, its unlikely that less than a majority of miners would support the
>>> change a year or two from now), and if no one is signaling opposition,
>>> chances are that the vast majority of the other 40% would also eventually
>>> signal support.
>>> 
>>> 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 upgrade mechanisms,
>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>> until we need to deploy a soft fork to discuss this will only delay things
>>> and cause contention again like it did with taproot.
>>> 
>>> I'm very curious to know what people think of this mechanism. I would
>>> appreciate any comments here, or written as github issues on the proposal
>>> repo itself.
>>> 
>>> Thanks,
>>> BT
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón]

If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.

On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Ultimately there is only one answer to this question. Get majority hash power support.
>
> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>
> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>
> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>
> e
>
> > On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
> >
> > For some definitions of “block”.
> >
> > Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
> >
> > Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
> >
> > e
> >
> >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
> >> still slow it down.
> >>
> >> It also already has the trinary state you seem to be describing (although
> >> perhaps this could be better documented in the BIP): users who oppose the
> >> softfork can and should treat the successful signal (whether MASF or UASF) as
> >> invalid, thereby ensuring they do not follow a chain with the rules in force.
> >>
> >> No additional bit is needed, as softforks are coordinated between users, NOT
> >> miners (who have no particular say in them, aside from their role as also
> >> being users). The miner involvement is only 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-dev wrote:
> >>> Given the recent controversy over upgrade mechanisms for the
> >>> non-controversial taproot upgrade, I have been thinking about ways to solve
> >>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
> >>> make the point that lazy miners failing to upgrade in a timely manner slow
> >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>> proponents make the point that LOT=true can lead to undesirable forks that
> >>> might cause a lot of chaos. I believe both points are essentially correct
> >>> and have created a proposal
> >>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
> >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
> >>>
> >>> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
> >>> update their software to a version that can actively signal opposition to
> >>> the change. The more opposition there is, the higher the threshold
> >>> necessary to lock in the upgrade. With the parameters I currently
> >>> recommended in the proposal, this chart shows how much support signaling
> >>> would be necessary given a particular amount of active opposition
> >>> signaling:
> >>>
> >>> [image: thresholdChart.png]
> >>> If literally no one signals opposition, a 60% threshold should be
> >>> relatively safe because it is a supermajority amount that is unlikely to
> >>> change significantly very quickly (ie if 60% of miners support the change
> >>> today, its unlikely that less than a majority of miners would support the
> >>> change a year or two from now), and if no one is signaling opposition,
> >>> chances are that the vast majority of the other 40% would also eventually
> >>> signal support.
> >>>
> >>> 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 upgrade mechanisms,
> >>> when there are no pressing soft fork upgrades ready to deploy. Waiting
> >>> until we need to deploy a soft fork to discuss this will only delay things
> >>> and cause contention again like it did with taproot.
> >>>
> >>> I'm very curious to know what people think of this mechanism. I would
> >>> appreciate any comments here, or written as github issues on the proposal
> >>> repo itself.
> >>>
> >>> Thanks,
> >>> BT
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

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 “compatibility” and the implication that activation without hash power enforcement does not create a split that I object to. People who know better should be honest about it.

Far too many people have been led to believe there is some sort of activation choice with “ensured” equal outcomes (maybe “slowed down”). There is only a choice between creating a split and hash power enforcement. Soft forks are rule changes, and thereby incompatible - unless enforced by majority hash power.

The statements below are grossly misleading and need to be called out as such so that people can actually make this decision you speak of. This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
> 
> If different users want different incompatible things (enough on each
> side), there's no way to avoid the split. We shouldn't try to avoid
> such a split.
> Users decide the rules, not miners nor developers.
> 
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 
>> Ultimately there is only one answer to this question. Get majority hash power support.
>> 
>> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>> 
>> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>> 
>> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>> 
>> e
>> 
>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>>> 
>>> For some definitions of “block”.
>>> 
>>> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>> 
>>> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
>>> 
>>> e
>>> 
>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> 
>>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
>>>> still slow it down.
>>>> 
>>>> It also already has the trinary state you seem to be describing (although
>>>> perhaps this could be better documented in the BIP): users who oppose the
>>>> softfork can and should treat the successful signal (whether MASF or UASF) as
>>>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>>>> 
>>>> No additional bit is needed, as softforks are coordinated between users, NOT
>>>> miners (who have no particular say in them, aside from their role as also
>>>> being users). The miner involvement is only 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-dev wrote:
>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>>>> proponents make the point that LOT=true can lead to undesirable forks that
>>>>> might cause a lot of chaos. I believe both points are essentially correct
>>>>> and have created a proposal
>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>>>> 
>>>>> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
>>>>> update their software to a version that can actively signal opposition to
>>>>> the change. The more opposition there is, the higher the threshold
>>>>> necessary to lock in the upgrade. With the parameters I currently
>>>>> recommended in the proposal, this chart shows how much support signaling
>>>>> would be necessary given a particular amount of active opposition
>>>>> signaling:
>>>>> 
>>>>> [image: thresholdChart.png]
>>>>> If literally no one signals opposition, a 60% threshold should be
>>>>> relatively safe because it is a supermajority amount that is unlikely to
>>>>> change significantly very quickly (ie if 60% of miners support the change
>>>>> today, its unlikely that less than a majority of miners would support the
>>>>> change a year or two from now), and if no one is signaling opposition,
>>>>> chances are that the vast majority of the other 40% would also eventually
>>>>> signal support.
>>>>> 
>>>>> 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 upgrade mechanisms,
>>>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>>>> until we need to deploy a soft fork to discuss this will only delay things
>>>>> and cause contention again like it did with taproot.
>>>>> 
>>>>> I'm very curious to know what people think of this mechanism. I would
>>>>> appreciate any comments here, or written as github issues on the proposal
>>>>> repo itself.
>>>>> 
>>>>> Thanks,
>>>>> BT
>>>> 
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 12254 bytes --]

@Luke
> They can still slow it down.

Absolutely. However I think that the option of permanent failure is
important. It certainly would be ideal to ensure that enough bitcoin users
support the upgrade *before* releasing it, however realistically this can
never be more than an estimate, and estimates can sometimes be wildly
wrong. It would be unfortunate if miners had a substantially different
estimate of user support than the people putting in the work to release
bitcoin upgrades. Even if upgrades are never released before it becomes
clear that a large supermajority of users want the upgrade, if miners don't
agree with the estimate a harmful chain split could occur. And I agree with
Eric that the goal here is to prevent a chain split during an upgrade when
possible. This includes permanent failure of an upgrade when there is
unexpectedly large miner opposition.

This of course does not prevent a UASF-style deployment to be done 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 risk of undesired chain
splits.

> [BIP8] already has the trinary state you seem to be describing

It sounds like you're saying the trinary state of BIP8 is A. Follow the
longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
chain. I agree. However the trinary state in my proposal is materially
different - it is the signaling itself that is trinary, not just which
chain is being followed. This allows others to know and make programmatic
decisions (in software) based on that signaling. I'm sure you can agree
that does not exist in BIP8.

> No additional bit is needed, as softforks are coordinated between users,
NOT miners

And yet there is miner involvement, as you rightly pointed out. Miners are
needed to set the nVersion in the header. So when you say "no additional
bit is needed", could you please be clearer as to what you mean? Do you
mean that signaling of opposition in a block can be done without any
"additional bit"? Or are you just saying that it is redundant to consider
what miners might be opposing an upgrade?

@Jorge
> If different users want different incompatible things... there's no way
to avoid the split

I agree. This happened with bcash, and that's fine. It was painful, but
there were a significant amount of users that disagreed, and they have the
chain they want now.

But we generally all want to avoid a chain split when possible. Because
chain splits have a cost, and that cost can be high, its likely that many
users would rather choose the chain with the most support rather than
choosing the chain with their preferred rules.

However, the question here is: how do we estimate what fraction of 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 the actual
deployment period. Neither of these are perfect, but they are both
reasonable enough mechanisms. However, because both of these mechanisms are
very rough estimates of user sentiment, we need to consider the possibility
that sometimes the estimate may be substantially inaccurate when we design
deployment procedures. This inaccuracy is why we need multiple barriers in
place for an upgrade, 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 measuring the consensus of the
bitcoin community can be extraordinarily difficult 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.

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 “compatibility” and the
> implication that activation without hash power enforcement does not create
> a split that I object to. People who know better should be honest about it.
>
> Far too many people have been led to believe there is some sort of
> activation choice with “ensured” equal outcomes (maybe “slowed down”).
> There is only a choice between creating a split and hash power enforcement.
> Soft forks are rule changes, and thereby incompatible - unless enforced by
> majority hash power.
>
> The statements below are grossly misleading and need to be called out as
> such so that people can actually make this decision you speak of. This idea
> that “users” 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ón <jtimon@jtimon.cc> wrote:
> >
> > If different users want different incompatible things (enough on each
> > side), there's no way to avoid the split. We shouldn't try to avoid
> > such a split.
> > Users decide the rules, not miners nor developers.
> >
> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Ultimately there is only one answer to this question. Get majority hash
> power support.
> >>
> >> Soft fork enforcement is the same act as any other censorship
> enforcement, the difference is only a question of what people want. Given
> that there is no collective “we”, those wants differ. Bitcoin resolves this
> question of conflicting wants, but it is not a democracy, it’s a market.
> One votes by trading.
> >>
> >> If one wants to enforce a soft fork (or otherwise censor) this is
> accomplished by mining (or paying others to do so). Anyone can 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’s time
> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
> that’s your vote.
> >>
> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s
> dishonest to imply that one can do this and all others will surely follow.
> This cannot be known, it’s merely a gamble. And it’s one that has been
> shown to not always pay off.
> >>
> >> e
> >>
> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
> >>>
> >>> For some definitions of “block”.
> >>>
> >>> Without majority hash power support, activation simply means you are
> off on a chain split. Anyone can of course split off from a chain by
> changing a rule (soft or otherwise) at any time, so this is a bit of an
> empty claim.
> >>>
> >>> Nobody can stop a person from splitting. The relevant question is how
> to *prevent* a split. And activation without majority hash power certainly
> does not “ensure” this.
> >>>
> >>> e
> >>>
> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>>
> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely.
> They can
> >>>> still slow it down.
> >>>>
> >>>> It also already has the trinary state you seem to be describing
> (although
> >>>> perhaps this could be better documented in the BIP): users who oppose
> the
> >>>> softfork can and should treat the successful signal (whether MASF or
> UASF) as
> >>>> invalid, thereby ensuring they do not follow a chain with the rules
> in force.
> >>>>
> >>>> No additional bit is needed, as softforks are coordinated between
> users, NOT
> >>>> miners (who have no particular say in them, aside from their role as
> also
> >>>> being users). The miner involvement is only 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-dev
> wrote:
> >>>>> Given the recent controversy over upgrade mechanisms for the
> >>>>> non-controversial taproot upgrade, I have been thinking about ways
> to solve
> >>>>> the problems that both sides brought up. In short, BIP8 LOT=true
> proponents
> >>>>> make the point that lazy miners failing to upgrade in a timely
> manner slow
> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>>>> proponents make the point that LOT=true can lead to undesirable
> forks that
> >>>>> might cause a lot of chaos. I believe both points are essentially
> correct
> >>>>> and have created a proposal
> >>>>> <
> https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both
> problems.
> >>>>>
> >>>>> The proposal uses trinary version signaling rather than binary
> 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 oppose the change are incentivized
> to
> >>>>> update their software to a version that can actively signal
> opposition to
> >>>>> the change. The more opposition there is, the higher the threshold
> >>>>> necessary to lock in the upgrade. With the parameters I currently
> >>>>> recommended in the proposal, this chart shows how much support
> signaling
> >>>>> would be necessary given a particular amount of active opposition
> >>>>> signaling:
> >>>>>
> >>>>> [image: thresholdChart.png]
> >>>>> If literally no one signals opposition, a 60% threshold should be
> >>>>> relatively safe because it is a supermajority amount that is
> unlikely to
> >>>>> change significantly very quickly (ie if 60% of miners support the
> change
> >>>>> today, its unlikely that less than a majority of miners would
> support the
> >>>>> change a year or two from now), and if no one is signaling
> opposition,
> >>>>> chances are that the vast majority of the other 40% would also
> eventually
> >>>>> signal support.
> >>>>>
> >>>>> 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 upgrade
> mechanisms,
> >>>>> when there are no pressing soft fork upgrades ready to deploy.
> Waiting
> >>>>> until we need to deploy a soft fork to discuss this will only delay
> things
> >>>>> and cause contention again like it did with taproot.
> >>>>>
> >>>>> I'm very curious to know what people think of this mechanism. I would
> >>>>> appreciate any comments here, or written as github issues on the
> proposal
> >>>>> repo itself.
> >>>>>
> >>>>> Thanks,
> >>>>> BT
> >>>>
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev@lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14955 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 12875 bytes --]

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 bitcoin users
> support the upgrade *before* releasing it, however realistically this can
> never be more than an estimate, and estimates can sometimes be wildly
> wrong. It would be unfortunate if miners had a substantially different
> estimate of user support than the people putting in the work to release
> bitcoin upgrades. Even if upgrades are never released before it becomes
> clear that a large supermajority of users want the upgrade, if miners don't
> agree with the estimate a harmful chain split could occur. And I agree with
> Eric that the goal here is to prevent a chain split during an upgrade when
> possible. This includes permanent failure of an upgrade when there is
> unexpectedly large miner opposition.
>
> This of course does not prevent a UASF-style deployment to be done 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 risk of undesired chain
> splits.
>
> > [BIP8] already has the trinary state you seem to be describing
>
> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
> chain. I agree. However the trinary state in my proposal is materially
> different - it is the signaling itself that is trinary, not just which
> chain is being followed. This allows others to know and make programmatic
> decisions (in software) based on that signaling. I'm sure you can agree
> that does not exist in BIP8.
>
> > No additional bit is needed, as softforks are coordinated between users,
> NOT miners
>
> And yet there is miner involvement, as you rightly pointed out. Miners are
> needed to set the nVersion in the header. So when you say "no additional
> bit is needed", could you please be clearer as to what you mean? Do you
> mean that signaling of opposition in a block can be done without any
> "additional bit"? Or are you just saying that it is redundant to consider
> what miners might be opposing an upgrade?
>
> @Jorge
> > If different users want different incompatible things... there's no way
> to avoid the split
>
> I agree. This happened with bcash, and that's fine. It was painful, but
> there were a significant amount of users that disagreed, and they have the
> chain they want now.
>
> But we generally all want to avoid a chain split when possible. Because
> chain splits have a cost, and that cost can be high, its likely that many
> users would rather choose the chain with the most support rather than
> choosing the chain with their preferred rules.
>
> However, the question here is: how do we estimate what fraction of 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 the actual
> deployment period. Neither of these are perfect, but they are both
> reasonable enough mechanisms. However, because both of these mechanisms are
> very rough estimates of user sentiment, we need to consider the possibility
> that sometimes the estimate may be substantially inaccurate when we design
> deployment procedures. This inaccuracy is why we need multiple barriers in
> place for an upgrade, 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 measuring the consensus
> of the bitcoin community can be extraordinarily difficult 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.
>
> 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 “compatibility” and the
>> implication that activation without hash power enforcement does not create
>> a split that I object to. People who know better should be honest about it.
>>
>> Far too many people have been led to believe there is some sort of
>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>> There is only a choice between creating a split and hash power enforcement.
>> Soft forks are rule changes, and thereby incompatible - unless enforced by
>> majority hash power.
>>
>> The statements below are grossly misleading and need to be called out as
>> such so that people can actually make this decision you speak of. This idea
>> that “users” 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ón <jtimon@jtimon.cc> wrote:
>> >
>> > If different users want different incompatible things (enough on each
>> > side), there's no way to avoid the split. We shouldn't try to avoid
>> > such a split.
>> > Users decide the rules, not miners nor developers.
>> >
>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >> Ultimately there is only one answer to this question. Get majority
>> hash power support.
>> >>
>> >> Soft fork enforcement is the same act as any other censorship
>> enforcement, the difference is only a question of what people want. Given
>> that there is no collective “we”, those wants differ. Bitcoin resolves this
>> question of conflicting wants, but it is not a democracy, it’s a market.
>> One votes by trading.
>> >>
>> >> If one wants to enforce a soft fork (or otherwise censor) this is
>> accomplished by mining (or paying others to do so). Anyone can 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’s time
>> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
>> that’s your vote.
>> >>
>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s
>> dishonest to imply that one can do this and all others will surely follow.
>> This cannot be known, it’s merely a gamble. And it’s one that has been
>> shown to not always pay off.
>> >>
>> >> e
>> >>
>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>> >>>
>> >>> For some definitions of “block”.
>> >>>
>> >>> Without majority hash power support, activation simply means you are
>> off on a chain split. Anyone can of course split off from a chain by
>> changing a rule (soft or otherwise) at any time, so this is a bit of an
>> empty claim.
>> >>>
>> >>> Nobody can stop a person from splitting. The relevant question is how
>> to *prevent* a split. And activation without majority hash power certainly
>> does not “ensure” this.
>> >>>
>> >>> e
>> >>>
>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>
>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely.
>> They can
>> >>>> still slow it down.
>> >>>>
>> >>>> It also already has the trinary state you seem to be describing
>> (although
>> >>>> perhaps this could be better documented in the BIP): users who
>> oppose the
>> >>>> softfork can and should treat the successful signal (whether MASF or
>> UASF) as
>> >>>> invalid, thereby ensuring they do not follow a chain with the rules
>> in force.
>> >>>>
>> >>>> No additional bit is needed, as softforks are coordinated between
>> users, NOT
>> >>>> miners (who have no particular say in them, aside from their role as
>> also
>> >>>> being users). The miner involvement is only 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-dev
>> wrote:
>> >>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>> non-controversial taproot upgrade, I have been thinking about ways
>> to solve
>> >>>>> the problems that both sides brought up. In short, BIP8 LOT=true
>> proponents
>> >>>>> make the point that lazy miners failing to upgrade in a timely
>> manner slow
>> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>> >>>>> proponents make the point that LOT=true can lead to undesirable
>> forks that
>> >>>>> might cause a lot of chaos. I believe both points are essentially
>> correct
>> >>>>> and have created a proposal
>> >>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both
>> problems.
>> >>>>>
>> >>>>> The proposal uses trinary version signaling rather than binary
>> 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 oppose the change are incentivized
>> to
>> >>>>> update their software to a version that can actively signal
>> opposition to
>> >>>>> the change. The more opposition there is, the higher the threshold
>> >>>>> necessary to lock in the upgrade. With the parameters I currently
>> >>>>> recommended in the proposal, this chart shows how much support
>> signaling
>> >>>>> would be necessary given a particular amount of active opposition
>> >>>>> signaling:
>> >>>>>
>> >>>>> [image: thresholdChart.png]
>> >>>>> If literally no one signals opposition, a 60% threshold should be
>> >>>>> relatively safe because it is a supermajority amount that is
>> unlikely to
>> >>>>> change significantly very quickly (ie if 60% of miners support the
>> change
>> >>>>> today, its unlikely that less than a majority of miners would
>> support the
>> >>>>> change a year or two from now), and if no one is signaling
>> opposition,
>> >>>>> chances are that the vast majority of the other 40% would also
>> eventually
>> >>>>> signal support.
>> >>>>>
>> >>>>> 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 upgrade
>> mechanisms,
>> >>>>> when there are no pressing soft fork upgrades ready to deploy.
>> Waiting
>> >>>>> until we need to deploy a soft fork to discuss this will only delay
>> things
>> >>>>> and cause contention again like it did with taproot.
>> >>>>>
>> >>>>> I'm very curious to know what people think of this mechanism. I
>> would
>> >>>>> appreciate any comments here, or written as github issues on the
>> proposal
>> >>>>> repo itself.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> BT
>> >>>>
>> >>>> _______________________________________________
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 15711 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 12825 bytes --]

At least we are now acknowledging that splitting is what it’s about. That’s progress.

e

> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
> 
> 
> 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 bitcoin users support the upgrade *before* releasing it, however realistically this can never be more than an estimate, and estimates can sometimes be wildly wrong. It would be unfortunate if miners had a substantially different estimate of user support than the people putting in the work to release bitcoin upgrades. Even if upgrades are never released before it becomes clear that a large supermajority of users want the upgrade, if miners don't agree with the estimate a harmful chain split could occur. And I agree with Eric that the goal here is to prevent a chain split during an upgrade when possible. This includes permanent failure of an upgrade when there is unexpectedly large miner opposition. 
>> 
>> This of course does not prevent a UASF-style deployment to be done 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 risk of undesired chain splits. 
>> 
>> > [BIP8] already has the trinary state you seem to be describing
>> 
>> It sounds like you're saying the trinary state of BIP8 is A. Follow the longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded chain. I agree. However the trinary state in my proposal is materially different - it is the signaling itself that is trinary, not just which chain is being followed. This allows others to know and make programmatic decisions (in software) based on that signaling. I'm sure you can agree that does not exist in BIP8. 
>> 
>> > No additional bit is needed, as softforks are coordinated between users, NOT miners
>> 
>> And yet there is miner involvement, as you rightly pointed out. Miners are needed to set the nVersion in the header. So when you say "no additional bit is needed", could you please be clearer as to what you mean? Do you mean that signaling of opposition in a block can be done without any "additional bit"? Or are you just saying that it is redundant to consider what miners might be opposing an upgrade? 
>> 
>> @Jorge
>> > If different users want different incompatible things... there's no way to avoid the split
>> 
>> I agree. This happened with bcash, and that's fine. It was painful, but there were a significant amount of users that disagreed, and they have the chain they want now.
>> 
>> But we generally all want to avoid a chain split when possible. Because chain splits have a cost, and that cost can be high, its likely that many users would rather choose the chain with the most support rather than choosing the chain with their preferred rules.
>> 
>> However, the question here is: how do we estimate what fraction of 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 the actual deployment period. Neither of these are perfect, but they are both reasonable enough mechanisms. However, because both of these mechanisms are very rough estimates of user sentiment, we need to consider the possibility that sometimes the estimate may be substantially inaccurate when we design deployment procedures. This inaccuracy is why we need multiple barriers in place for an upgrade, 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 measuring the consensus of the bitcoin community can be extraordinarily difficult 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. 
>> 
>>> 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 “compatibility” and the implication that activation without hash power enforcement does not create a split that I object to. People who know better should be honest about it.
>>> 
>>> Far too many people have been led to believe there is some sort of activation choice with “ensured” equal outcomes (maybe “slowed down”). There is only a choice between creating a split and hash power enforcement. Soft forks are rule changes, and thereby incompatible - unless enforced by majority hash power.
>>> 
>>> The statements below are grossly misleading and need to be called out as such so that people can actually make this decision you speak of. This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>>> > 
>>> > If different users want different incompatible things (enough on each
>>> > side), there's no way to avoid the split. We shouldn't try to avoid
>>> > such a split.
>>> > Users decide the rules, not miners nor developers.
>>> > 
>>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >> 
>>> >> Ultimately there is only one answer to this question. Get majority hash power support.
>>> >> 
>>> >> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>>> >> 
>>> >> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>>> >> 
>>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>>> >> 
>>> >> e
>>> >> 
>>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>>> >>> 
>>> >>> For some definitions of “block”.
>>> >>> 
>>> >>> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>> >>> 
>>> >>> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
>>> >>> 
>>> >>> e
>>> >>> 
>>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >>>> 
>>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
>>> >>>> still slow it down.
>>> >>>> 
>>> >>>> It also already has the trinary state you seem to be describing (although
>>> >>>> perhaps this could be better documented in the BIP): users who oppose the
>>> >>>> softfork can and should treat the successful signal (whether MASF or UASF) as
>>> >>>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>>> >>>> 
>>> >>>> No additional bit is needed, as softforks are coordinated between users, NOT
>>> >>>> miners (who have no particular say in them, aside from their role as also
>>> >>>> being users). The miner involvement is only 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-dev wrote:
>>> >>>>> Given the recent controversy over upgrade mechanisms for the
>>> >>>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>> >>>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>> >>>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>> >>>>> proponents make the point that LOT=true can lead to undesirable forks that
>>> >>>>> might cause a lot of chaos. I believe both points are essentially correct
>>> >>>>> and have created a proposal
>>> >>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>> >>>>> 
>>> >>>>> The proposal uses trinary version signaling rather than binary 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 oppose the change are incentivized to
>>> >>>>> update their software to a version that can actively signal opposition to
>>> >>>>> the change. The more opposition there is, the higher the threshold
>>> >>>>> necessary to lock in the upgrade. With the parameters I currently
>>> >>>>> recommended in the proposal, this chart shows how much support signaling
>>> >>>>> would be necessary given a particular amount of active opposition
>>> >>>>> signaling:
>>> >>>>> 
>>> >>>>> [image: thresholdChart.png]
>>> >>>>> If literally no one signals opposition, a 60% threshold should be
>>> >>>>> relatively safe because it is a supermajority amount that is unlikely to
>>> >>>>> change significantly very quickly (ie if 60% of miners support the change
>>> >>>>> today, its unlikely that less than a majority of miners would support the
>>> >>>>> change a year or two from now), and if no one is signaling opposition,
>>> >>>>> chances are that the vast majority of the other 40% would also eventually
>>> >>>>> signal support.
>>> >>>>> 
>>> >>>>> 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 upgrade mechanisms,
>>> >>>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>> >>>>> until we need to deploy a soft fork to discuss this will only delay things
>>> >>>>> and cause contention again like it did with taproot.
>>> >>>>> 
>>> >>>>> I'm very curious to know what people think of this mechanism. I would
>>> >>>>> appreciate any comments here, or written as github issues on the proposal
>>> >>>>> repo itself.
>>> >>>>> 
>>> >>>>> Thanks,
>>> >>>>> BT
>>> >>>> 
>>> >>>> _______________________________________________
>>> >>>> bitcoin-dev mailing list
>>> >>>> bitcoin-dev@lists.linuxfoundation.org
>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >> _______________________________________________
>>> >> bitcoin-dev mailing list
>>> >> bitcoin-dev@lists.linuxfoundation.org
>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 16135 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr]

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

In other words, in this context, accepting a split between disagreeing users 
is the ONLY way Bitcoin can possibly continue as a decentralised currency. 
Making that split as clean and well-defined as possible not only ensures the 
best opportunity for both sides of the disagreement, 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).

Luke


On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> At least we are now acknowledging that splitting is what it’s about. That’s
> progress.
>
> e
>
> > On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
> >
> > 
> > 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 bitcoin
> >> users support the upgrade *before* releasing it, however realistically
> >> this can never be more than an estimate, and estimates can sometimes be
> >> wildly wrong. It would be unfortunate if miners had a substantially
> >> different estimate of user support than the people putting in the work
> >> to release bitcoin upgrades. Even if upgrades are never released before
> >> it becomes clear that a large supermajority of users want the upgrade,
> >> if miners don't agree with the estimate a harmful chain split could
> >> occur. And I agree with Eric that the goal here is to prevent a chain
> >> split during an upgrade when possible. This includes permanent failure
> >> of an upgrade when there is unexpectedly large miner opposition.
> >>
> >> This of course does not prevent a UASF-style deployment to be done 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 risk of
> >> undesired chain splits.
> >>
> >> > [BIP8] already has the trinary state you seem to be describing
> >>
> >> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> >> longest chain, B. Follow the upgrade chain, or C. follow the
> >> non-upgraded chain. I agree. However the trinary state in my proposal is
> >> materially different - it is the signaling itself that is trinary, not
> >> just which chain is being followed. This allows others to know and make
> >> programmatic decisions (in software) based on that signaling. I'm sure
> >> you can agree that does not exist in BIP8.
> >>
> >> > No additional bit is needed, as softforks are coordinated between
> >> > users, NOT miners
> >>
> >> And yet there is miner involvement, as you rightly pointed out. Miners
> >> are needed to set the nVersion in the header. So when you say "no
> >> additional bit is needed", could you please be clearer as to what you
> >> mean? Do you mean that signaling of opposition in a block can be done
> >> without any "additional bit"? Or are you just saying that it is
> >> redundant to consider what miners might be opposing an upgrade?
> >>
> >> @Jorge
> >>
> >> > If different users want different incompatible things... there's no
> >> > way to avoid the split
> >>
> >> I agree. This happened with bcash, and that's fine. It was painful, but
> >> there were a significant amount of users that disagreed, and they have
> >> the chain they want now.
> >>
> >> But we generally all want to avoid a chain split when possible. Because
> >> chain splits have a cost, and that cost can be high, its likely that
> >> many users would rather choose the chain with the most support rather
> >> than choosing the chain with their preferred rules.
> >>
> >> However, the question here is: how do we estimate what fraction of 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 the
> >> actual deployment period. Neither of these are perfect, but they are
> >> both reasonable enough mechanisms. However, because both of these
> >> mechanisms are very rough estimates of user sentiment, we need to
> >> consider the possibility that sometimes the estimate may be
> >> substantially inaccurate when we design deployment procedures. This
> >> inaccuracy is why we need multiple barriers in place for an upgrade, 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 measuring
> >> the consensus of the bitcoin community can be extraordinarily difficult
> >> 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.
> >>
> >>> 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 “compatibility” and the
> >>> implication that activation without hash power enforcement does not
> >>> create a split that I object to. People who know better should be
> >>> honest about it.
> >>>
> >>> Far too many people have been led to believe there is some sort of
> >>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
> >>> There is only a choice between creating a split and hash power
> >>> enforcement. Soft forks are rule changes, and thereby incompatible -
> >>> unless enforced by majority hash power.
> >>>
> >>> The statements below are grossly misleading and need to be called out
> >>> as such so that people can actually make this decision you speak of.
> >>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
> >>> >
> >>> > If different users want different incompatible things (enough on
> >>> > each side), there's no way to avoid the split. We shouldn't try to
> >>> > avoid such a split.
> >>> > Users decide the rules, not miners nor developers.
> >>> >
> >>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> >>
> >>> >> Ultimately there is only one answer to this question. Get majority
> >>> >> hash power support.
> >>> >>
> >>> >> Soft fork enforcement is the same act as any other censorship
> >>> >> enforcement, the difference is only a question of what people want.
> >>> >> Given that there is no collective “we”, those wants differ. Bitcoin
> >>> >> resolves this question of conflicting wants, but it is not a
> >>> >> democracy, it’s a market. One votes by trading.
> >>> >>
> >>> >> If one wants to enforce a soft fork (or otherwise censor) this is
> >>> >> accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people.
> >>> >> Anyone can mine, and that’s your vote.
> >>> >>
> >>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s
> >>> >> dishonest to imply that one can do this and all others will surely
> >>> >> follow. This cannot be known, it’s merely a gamble. And it’s one
> >>> >> that has been shown to not always pay off.
> >>> >>
> >>> >> e
> >>> >>
> >>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
> >>> >>>
> >>> >>> For some definitions of “block”.
> >>> >>>
> >>> >>> Without majority hash power support, activation simply means you
> >>> >>> are off on a chain split. Anyone can of course split off from a
> >>> >>> chain by changing a rule (soft or otherwise) at any time, so this
> >>> >>> is a bit of an empty claim.
> >>> >>>
> >>> >>> Nobody can stop a person from splitting. The relevant question is
> >>> >>> how to *prevent* a split. And activation without majority hash
> >>> >>> power certainly does not “ensure” this.
> >>> >>>
> >>> >>> e
> >>> >>>
> >>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
> >>> >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> >>>>
> >>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade
> >>> >>>> entirely. They can still slow it down.
> >>> >>>>
> >>> >>>> It also already has the trinary state you seem to be describing
> >>> >>>> (although perhaps this could be better documented in the BIP):
> >>> >>>> users who oppose the softfork can and should treat the successful
> >>> >>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
> >>> >>>> not follow a chain with the rules in force.
> >>> >>>>
> >>> >>>> No additional bit is needed, as softforks are coordinated between
> >>> >>>> users, NOT miners (who have no particular say in them, aside from
> >>> >>>> their role as also being users). The miner involvement is only 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-dev
> >>> >>>>>> wrote:
> >>> >>>>>
> >>> >>>>> Given the recent controversy over upgrade mechanisms for the
> >>> >>>>> non-controversial taproot upgrade, I have been thinking about
> >>> >>>>> ways to solve the problems that both sides brought up. In short,
> >>> >>>>> BIP8 LOT=true proponents make the point that lazy miners failing
> >>> >>>>> to upgrade in a timely manner slow down releases of bitcoin
> >>> >>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
> >>> >>>>> that LOT=true can lead to undesirable forks that might cause a
> >>> >>>>> lot of chaos. I believe both points are essentially correct and
> >>> >>>>> have created a proposal
> >>> >>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
> >>> >>>>> 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 oppose
> >>> >>>>> the change are incentivized to update their software to a version
> >>> >>>>> that can actively signal opposition to the change. The more
> >>> >>>>> opposition there is, the higher the threshold necessary to lock
> >>> >>>>> in the upgrade. With the parameters I currently recommended in
> >>> >>>>> the proposal, this chart shows how much support signaling would
> >>> >>>>> be necessary given a particular amount of active opposition
> >>> >>>>> signaling:
> >>> >>>>>
> >>> >>>>> [image: thresholdChart.png]
> >>> >>>>> If literally no one signals opposition, a 60% threshold should be
> >>> >>>>> relatively safe because it is a supermajority amount that is
> >>> >>>>> unlikely to change significantly very quickly (ie if 60% of
> >>> >>>>> miners support the change today, its unlikely that less than a
> >>> >>>>> majority of miners would support the change a year or two from
> >>> >>>>> now), and if no one is signaling opposition, chances are that the
> >>> >>>>> vast majority of the other 40% would also eventually signal
> >>> >>>>> support.
> >>> >>>>>
> >>> >>>>> 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 upgrade
> >>> >>>>> mechanisms, when there are no pressing soft fork upgrades ready
> >>> >>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
> >>> >>>>> this will only delay things and cause contention again like it
> >>> >>>>> did with taproot.
> >>> >>>>>
> >>> >>>>> I'm very curious to know what people think of this mechanism. I
> >>> >>>>> would appreciate any comments here, or written as github issues
> >>> >>>>> on the proposal repo itself.
> >>> >>>>>
> >>> >>>>> Thanks,
> >>> >>>>> BT
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> bitcoin-dev mailing list
> >>> >>>> bitcoin-dev@lists.linuxfoundation.org
> >>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>> >>
> >>> >> _______________________________________________
> >>> >> bitcoin-dev mailing list
> >>> >> bitcoin-dev@lists.linuxfoundation.org
> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

> On Jun 29, 2021, at 10:55, Luke Dashjr <luke@dashjr.org> wrote:
> 
> The 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 “better” than the other. The largest merchants are likely 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 rules are, 

There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s 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 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 “needs to” concede once a split has occurred, which 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’s about. That’s
>> progress.
>> 
>> e
>> 
>>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
>>> 
>>> 
>>> 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 bitcoin
>>>> users support the upgrade *before* releasing it, however realistically
>>>> this can never be more than an estimate, and estimates can sometimes be
>>>> wildly wrong. It would be unfortunate if miners had a substantially
>>>> different estimate of user support than the people putting in the work
>>>> to release bitcoin upgrades. Even if upgrades are never released before
>>>> it becomes clear that a large supermajority of users want the upgrade,
>>>> if miners don't agree with the estimate a harmful chain split could
>>>> occur. And I agree with Eric that the goal here is to prevent a chain
>>>> split during an upgrade when possible. This includes permanent failure
>>>> of an upgrade when there is unexpectedly large miner opposition.
>>>> 
>>>> This of course does not prevent a UASF-style deployment to be done 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 risk of
>>>> undesired chain splits.
>>>> 
>>>>> [BIP8] already has the trinary state you seem to be describing
>>>> 
>>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the
>>>> longest chain, B. Follow the upgrade chain, or C. follow the
>>>> non-upgraded chain. I agree. However the trinary state in my proposal is
>>>> materially different - it is the signaling itself that is trinary, not
>>>> just which chain is being followed. This allows others to know and make
>>>> programmatic decisions (in software) based on that signaling. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>> 
>>>>> No additional bit is needed, as softforks are coordinated between
>>>>> users, NOT miners
>>>> 
>>>> And yet there is miner involvement, as you rightly pointed out. Miners
>>>> are needed to set the nVersion in the header. So when you say "no
>>>> additional bit is needed", could you please be clearer as to what you
>>>> mean? Do you mean that signaling of opposition in a block can be done
>>>> without any "additional bit"? Or are you just saying that it is
>>>> redundant to consider what miners might be opposing an upgrade?
>>>> 
>>>> @Jorge
>>>> 
>>>>> If different users want different incompatible things... there's no
>>>>> way to avoid the split
>>>> 
>>>> I agree. This happened with bcash, and that's fine. It was painful, but
>>>> there were a significant amount of users that disagreed, and they have
>>>> the chain they want now.
>>>> 
>>>> But we generally all want to avoid a chain split when possible. Because
>>>> chain splits have a cost, and that cost can be high, its likely that
>>>> many users would rather choose the chain with the most support rather
>>>> than choosing the chain with their preferred rules.
>>>> 
>>>> However, the question here is: how do we estimate what fraction of 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 the
>>>> actual deployment period. Neither of these are perfect, but they are
>>>> both reasonable enough mechanisms. However, because both of these
>>>> mechanisms are very rough estimates of user sentiment, we need to
>>>> consider the possibility that sometimes the estimate may be
>>>> substantially inaccurate when we design deployment procedures. This
>>>> inaccuracy is why we need multiple barriers in place for an upgrade, 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 measuring
>>>> the consensus of the bitcoin community can be extraordinarily difficult
>>>> 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.
>>>> 
>>>>> 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 “compatibility” and the
>>>>> implication that activation without hash power enforcement does not
>>>>> create a split that I object to. People who know better should be
>>>>> honest about it.
>>>>> 
>>>>> Far too many people have been led to believe there is some sort of
>>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>>>>> There is only a choice between creating a split and hash power
>>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>>>>> unless enforced by majority hash power.
>>>>> 
>>>>> The statements below are grossly misleading and need to be called out
>>>>> as such so that people can actually make this decision you speak of.
>>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>>>>>> 
>>>>>> If different users want different incompatible things (enough on
>>>>>> each side), there's no way to avoid the split. We shouldn't try to
>>>>>> avoid such a split.
>>>>>> Users decide the rules, not miners nor developers.
>>>>>> 
>>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>>> 
>>>>>>> Ultimately there is only one answer to this question. Get majority
>>>>>>> hash power support.
>>>>>>> 
>>>>>>> Soft fork enforcement is the same act as any other censorship
>>>>>>> enforcement, the difference is only a question of what people want.
>>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
>>>>>>> resolves this question of conflicting wants, but it is not a
>>>>>>> democracy, it’s a market. One votes by trading.
>>>>>>> 
>>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>>>>>>> accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people.
>>>>>>> Anyone can mine, and that’s your vote.
>>>>>>> 
>>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But it’s
>>>>>>> dishonest to imply that one can do this and all others will surely
>>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>>>>>>> that has been shown to not always pay off.
>>>>>>> 
>>>>>>> e
>>>>>>> 
>>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>>>>>>>> 
>>>>>>>> For some definitions of “block”.
>>>>>>>> 
>>>>>>>> Without majority hash power support, activation simply means you
>>>>>>>> are off on a chain split. Anyone can of course split off from a
>>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>>>>>>>> is a bit of an empty claim.
>>>>>>>> 
>>>>>>>> Nobody can stop a person from splitting. The relevant question is
>>>>>>>> how to *prevent* a split. And activation without majority hash
>>>>>>>> power certainly does not “ensure” this.
>>>>>>>> 
>>>>>>>> e
>>>>>>>> 
>>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>>>>> 
>>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>>>>>>>>> entirely. They can still slow it down.
>>>>>>>>> 
>>>>>>>>> It also already has the trinary state you seem to be describing
>>>>>>>>> (although perhaps this could be better documented in the BIP):
>>>>>>>>> users who oppose the softfork can and should treat the successful
>>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
>>>>>>>>> not follow a chain with the rules in force.
>>>>>>>>> 
>>>>>>>>> No additional bit is needed, as softforks are coordinated between
>>>>>>>>> users, NOT miners (who have no particular say in them, aside from
>>>>>>>>> their role as also being users). The miner involvement is only 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-dev
>>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>>>>>>>>>> ways to solve the problems that both sides brought up. In short,
>>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners failing
>>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>>>>>>>>>> have created a proposal
>>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
>>>>>>>>>> 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 oppose
>>>>>>>>>> the change are incentivized to update their software to a version
>>>>>>>>>> that can actively signal opposition to the change. The more
>>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>>>>>>>>>> the proposal, this chart shows how much support signaling would
>>>>>>>>>> be necessary given a particular amount of active opposition
>>>>>>>>>> signaling:
>>>>>>>>>> 
>>>>>>>>>> [image: thresholdChart.png]
>>>>>>>>>> If literally no one signals opposition, a 60% threshold should be
>>>>>>>>>> relatively safe because it is a supermajority amount that is
>>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>>>>>>>>>> miners support the change today, its unlikely that less than a
>>>>>>>>>> majority of miners would support the change a year or two from
>>>>>>>>>> now), and if no one is signaling opposition, chances are that the
>>>>>>>>>> vast majority of the other 40% would also eventually signal
>>>>>>>>>> support.
>>>>>>>>>> 
>>>>>>>>>> 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 upgrade
>>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
>>>>>>>>>> this will only delay things and cause contention again like it
>>>>>>>>>> did with taproot.
>>>>>>>>>> 
>>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>>>>>>>>>> would appreciate any comments here, or written as github issues
>>>>>>>>>> on the proposal repo itself.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> BT
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 17506 bytes --]

"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.

You may say users chosing the rules is "politicial". Isn't miners deciding
them for users more political? Whatever you call it, it is still how free
software works: users decide what to run.
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.
How can we expect users to understand bitcoin when most developers don't
seem to understand it?

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:
> >
> > The 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 “better” than
> the other. The largest merchants are likely 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 rules
> are,
>
> There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s
> 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 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 “needs to” concede once a split has occurred, which 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’s about.
> That’s
> >> progress.
> >>
> >> e
> >>
> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
> >>>
> >>> 
> >>> 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 bitcoin
> >>>> users support the upgrade *before* releasing it, however realistically
> >>>> this can never be more than an estimate, and estimates can sometimes
> be
> >>>> wildly wrong. It would be unfortunate if miners had a substantially
> >>>> different estimate of user support than the people putting in the work
> >>>> to release bitcoin upgrades. Even if upgrades are never released
> before
> >>>> it becomes clear that a large supermajority of users want the upgrade,
> >>>> if miners don't agree with the estimate a harmful chain split could
> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
> >>>> split during an upgrade when possible. This includes permanent failure
> >>>> of an upgrade when there is unexpectedly large miner opposition.
> >>>>
> >>>> This of course does not prevent a UASF-style deployment to be done
> 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 risk
> of
> >>>> undesired chain splits.
> >>>>
> >>>>> [BIP8] already has the trinary state you seem to be describing
> >>>>
> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
> the
> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
> >>>> non-upgraded chain. I agree. However the trinary state in my proposal
> is
> >>>> materially different - it is the signaling itself that is trinary, not
> >>>> just which chain is being followed. This allows others to know and
> make
> >>>> programmatic decisions (in software) based on that signaling. I'm sure
> >>>> you can agree that does not exist in BIP8.
> >>>>
> >>>>> No additional bit is needed, as softforks are coordinated between
> >>>>> users, NOT miners
> >>>>
> >>>> And yet there is miner involvement, as you rightly pointed out. Miners
> >>>> are needed to set the nVersion in the header. So when you say "no
> >>>> additional bit is needed", could you please be clearer as to what you
> >>>> mean? Do you mean that signaling of opposition in a block can be done
> >>>> without any "additional bit"? Or are you just saying that it is
> >>>> redundant to consider what miners might be opposing an upgrade?
> >>>>
> >>>> @Jorge
> >>>>
> >>>>> If different users want different incompatible things... there's no
> >>>>> way to avoid the split
> >>>>
> >>>> I agree. This happened with bcash, and that's fine. It was painful,
> but
> >>>> there were a significant amount of users that disagreed, and they have
> >>>> the chain they want now.
> >>>>
> >>>> But we generally all want to avoid a chain split when possible.
> Because
> >>>> chain splits have a cost, and that cost can be high, its likely that
> >>>> many users would rather choose the chain with the most support rather
> >>>> than choosing the chain with their preferred rules.
> >>>>
> >>>> However, the question here is: how do we estimate what fraction of
> 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 the
> >>>> actual deployment period. Neither of these are perfect, but they are
> >>>> both reasonable enough mechanisms. However, because both of these
> >>>> mechanisms are very rough estimates of user sentiment, we need to
> >>>> consider the possibility that sometimes the estimate may be
> >>>> substantially inaccurate when we design deployment procedures. This
> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
> 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 measuring
> >>>> the consensus of the bitcoin community can be extraordinarily
> difficult
> >>>> 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.
> >>>>
> >>>>> 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 “compatibility” and
> the
> >>>>> implication that activation without hash power enforcement does not
> >>>>> create a split that I object to. People who know better should be
> >>>>> honest about it.
> >>>>>
> >>>>> Far too many people have been led to believe there is some sort of
> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
> down”).
> >>>>> There is only a choice between creating a split and hash power
> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
> >>>>> unless enforced by majority hash power.
> >>>>>
> >>>>> The statements below are grossly misleading and need to be called out
> >>>>> as such so that people can actually make this decision you speak of.
> >>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
> >>>>>>
> >>>>>> If different users want different incompatible things (enough on
> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
> >>>>>> avoid such a split.
> >>>>>> Users decide the rules, not miners nor developers.
> >>>>>>
> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>>>>>
> >>>>>>> Ultimately there is only one answer to this question. Get majority
> >>>>>>> hash power support.
> >>>>>>>
> >>>>>>> Soft fork enforcement is the same act as any other censorship
> >>>>>>> enforcement, the difference is only a question of what people want.
> >>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
> >>>>>>> resolves this question of conflicting wants, but it is not a
> >>>>>>> democracy, it’s a market. One votes by trading.
> >>>>>>>
> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
> 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’s time Bitcoiners stop thinking of miners as other people.
> >>>>>>> Anyone can mine, and that’s your vote.
> >>>>>>>
> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
> it’s
> >>>>>>> dishonest to imply that one can do this and all others will surely
> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
> >>>>>>> that has been shown to not always pay off.
> >>>>>>>
> >>>>>>> e
> >>>>>>>
> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org>
> wrote:
> >>>>>>>>
> >>>>>>>> For some definitions of “block”.
> >>>>>>>>
> >>>>>>>> Without majority hash power support, activation simply means you
> >>>>>>>> are off on a chain split. Anyone can of course split off from a
> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
> >>>>>>>> is a bit of an empty claim.
> >>>>>>>>
> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
> >>>>>>>> how to *prevent* a split. And activation without majority hash
> >>>>>>>> power certainly does not “ensure” this.
> >>>>>>>>
> >>>>>>>> e
> >>>>>>>>
> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
> >>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>>>>>>>
> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
> >>>>>>>>> entirely. They can still slow it down.
> >>>>>>>>>
> >>>>>>>>> It also already has the trinary state you seem to be describing
> >>>>>>>>> (although perhaps this could be better documented in the BIP):
> >>>>>>>>> users who oppose the softfork can and should treat the successful
> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
> do
> >>>>>>>>> not follow a chain with the rules in force.
> >>>>>>>>>
> >>>>>>>>> No additional bit is needed, as softforks are coordinated between
> >>>>>>>>> users, NOT miners (who have no particular say in them, aside from
> >>>>>>>>> their role as also being users). The miner involvement is only
> 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-dev
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
> >>>>>>>>>> ways to solve the problems that both sides brought up. In short,
> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners failing
> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
> >>>>>>>>>> have created a proposal
> >>>>>>>>>> <
> https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
> >>>>>>>>>> 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 oppose
> >>>>>>>>>> the change are incentivized to update their software to a
> version
> >>>>>>>>>> that can actively signal opposition to the change. The more
> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
> >>>>>>>>>> the proposal, this chart shows how much support signaling would
> >>>>>>>>>> be necessary given a particular amount of active opposition
> >>>>>>>>>> signaling:
> >>>>>>>>>>
> >>>>>>>>>> [image: thresholdChart.png]
> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
> be
> >>>>>>>>>> relatively safe because it is a supermajority amount that is
> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
> >>>>>>>>>> miners support the change today, its unlikely that less than a
> >>>>>>>>>> majority of miners would support the change a year or two from
> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
> the
> >>>>>>>>>> vast majority of the other 40% would also eventually signal
> >>>>>>>>>> support.
> >>>>>>>>>>
> >>>>>>>>>> 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 upgrade
> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
> discuss
> >>>>>>>>>> this will only delay things and cause contention again like it
> >>>>>>>>>> did with taproot.
> >>>>>>>>>>
> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
> >>>>>>>>>> would appreciate any comments here, or written as github issues
> >>>>>>>>>> on the proposal repo itself.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> BT
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> bitcoin-dev mailing list
> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> bitcoin-dev mailing list
> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

[-- Attachment #2: Type: text/html, Size: 24824 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 18931 bytes --]


> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon@jtimon.cc> wrote:
> 
> 
> "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 “control” because these statements hinge on that word. Nobody “controls” 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 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’s economic. The largest investment in mining (including highest 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 others agree (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’s 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:
>> > 
>> > The 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 “better” than the other. The largest merchants are likely 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 rules are, 
>> 
>> There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s 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 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 “needs to” concede once a split has occurred, which 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’s about. That’s
>> >> progress.
>> >> 
>> >> e
>> >> 
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
>> >>> 
>> >>> 
>> >>> 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 bitcoin
>> >>>> users support the upgrade *before* releasing it, however realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released before
>> >>>> it becomes clear that a large supermajority of users want the upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>> 
>> >>>> This of course does not prevent a UASF-style deployment to be done 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 risk of
>> >>>> undesired chain splits.
>> >>>> 
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>> 
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my proposal is
>> >>>> materially different - it is the signaling itself that is trinary, not
>> >>>> just which chain is being followed. This allows others to know and make
>> >>>> programmatic decisions (in software) based on that signaling. I'm sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>> 
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>> 
>> >>>> And yet there is miner involvement, as you rightly pointed out. Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>> 
>> >>>> @Jorge
>> >>>> 
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>> 
>> >>>> I agree. This happened with bcash, and that's fine. It was painful, but
>> >>>> there were a significant amount of users that disagreed, and they have
>> >>>> the chain they want now.
>> >>>> 
>> >>>> But we generally all want to avoid a chain split when possible. Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>> 
>> >>>> However, the question here is: how do we estimate what fraction of 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 the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade, 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 measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily difficult
>> >>>> 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.
>> >>>> 
>> >>>>> 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 “compatibility” and the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>> 
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>> 
>> >>>>> The statements below are grossly misleading and need to be called out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>> >>>>>> 
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>> 
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>> 
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>> 
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people want.
>> >>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>> 
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can 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’s time Bitcoiners stop thinking of miners as other people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>> 
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>> 
>> >>>>>>> e
>> >>>>>>> 
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>> >>>>>>>> 
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>> 
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>> 
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>> 
>> >>>>>>>> e
>> >>>>>>>> 
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>>> 
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>> 
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>> 
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside from
>> >>>>>>>>> their role as also being users). The miner involvement is only 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-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>> 
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
>> >>>>>>>>>> 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 oppose
>> >>>>>>>>>> the change are incentivized to update their software to a version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>> 
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>> 
>> >>>>>>>>>> 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 upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>> 
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>> 
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>> 
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>> 
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > 

[-- Attachment #2: Type: text/html, Size: 26865 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 22188 bytes --]

@Jorge

>I don't think we should avoid splits at all costs.

I absolutely agree that we shouldn't avoid splits at all costs. There are
some costs too high to pay to avoid a split. If an economic majority
started wanting to increase bitcoin's blocksize to 1 GB next year, we
should absolutely hard fork away from that mess with a minority chain.

>  I don't think we should avoid splits when possible,

I want to see why exactly we disagree about avoiding chain splits "when
possible". Are you really saying that we should just hard fork every time
instead of soft fork? Should we even bother to get widespread buy in at
all, or should we just release the software, hardfork away, and let anyone
that wants to follow us follow us later? Are you not at all worried about
the costs associated with an increased orphan rate and reorg rate? Are you
not worried that an update might happen too fast and that a significant
fraction of people that could have come along with us to the new update
might be left behind because they didn't have time to evaluate the
changed rules?

Do you agree that, in a conversation about rule changes, some people want
it their way no matter what and will hardfork to get the rules they want,
and some people want it their way, but only if enough other people agree to
follow those rules too? Some people might want a rule change, but aren't
willing to follow, say, a 20% minority fork. Perhaps their personal cut-off
is 40% or 50% or 75% or 90%. Do you agree those people exist?

If you do, then I don't understand why you disagree that we should avoid
chain splits even "when possible". Maybe you could elaborate as to what you
mean there.

@Luke

Are you in agreement with Jorge here that we should not even attempt to
avoid chain splits?

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

There is not simply a binary "do or do not". There is also timing.
Non-contentious changes can happen fast. Contentious changes need more time
for discussion, preparation, or coordination, even if the eventual outcome
is the same. Do you disagree that timing issues can be
important, that delays can be useful and help to avoid chain splits? Do you
agree that miners have a (large) incentive to follow the economic majority?
Is the goal here to do what the economic majority wants, or some other
group? If so, do you think we have an accurate way of measuring what the
economic majority wants? Will that mechanism continue to be accurate into
the future?

I'm asking these questions to try and figure out why we disagree here.

On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil <eric@voskuil.org> wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon@jtimon.cc> wrote:
>
> 
> "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 “control” because these statements hinge on that word.
> Nobody “controls” 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 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’s economic. The largest investment in mining (including highest
> 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 others
> agree (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’s 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:
>> >
>> > The 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
>> “better” than the other. The largest merchants are likely 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 rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s
>> 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 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 “needs to” concede once a split has occurred, which 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’s about.
>> That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
>> >>>
>> >>> 
>> >>> 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 bitcoin
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes
>> be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the
>> work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released
>> before
>> >>>> it becomes clear that a large supermajority of users want the
>> upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent
>> failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done
>> 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 risk
>> of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
>> the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my
>> proposal is
>> >>>> materially different - it is the signaling itself that is trinary,
>> not
>> >>>> just which chain is being followed. This allows others to know and
>> make
>> >>>> programmatic decisions (in software) based on that signaling. I'm
>> sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out.
>> Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful,
>> but
>> >>>> there were a significant amount of users that disagreed, and they
>> have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible.
>> Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> 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 the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
>> 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 measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> 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.
>> >>>>
>> >>>>> 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 “compatibility” and
>> the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
>> down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called
>> out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people
>> want.
>> >>>>>>> Given that there is no collective “we”, those wants differ.
>> Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> 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’s time Bitcoiners stop thinking of miners as other
>> people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
>> it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the
>> successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
>> do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated
>> between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside
>> from
>> >>>>>>>>> their role as also being users). The miner involvement is only
>> 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-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In
>> short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
>> >>>>>>>>>> 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 oppose
>> >>>>>>>>>> the change are incentivized to update their software to a
>> version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
>> be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> 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 upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 30461 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[eric]

[-- Attachment #1: Type: text/plain, Size: 6178 bytes --]

All good questions.

 

> Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants?

 

It’s important that people understand that “economic” does not refer to people interested in, HODLing, coding, or selling Bitcoin. It is only those who are *presently accepting* it. We refer to these as “economic nodes”. Those are the people with the economic power to reject coin that they consider invalid. Only their validation is of any economic consequence in the event of a split. I see no reason to assume that the economy is any less centralized than mining is pooled. Today the support of the economy would be best measured by meeting with exchange operators. If they did not go along, any unenforced soft fork (split) would isolate everyone who thought they could continue to trade their coin on exchanges.

 

I’d also question the use of the term “majority”. It applies to hash power, by design, but not to the economy. A split of any size is possible, requiring no majority. All it requires is other people to trade with.

 

Exchanges are highly regulated and compliant institutions. Mining operations are heavily pooled. Neither of these is inherently better than the other. Everyone can have a say by being a miner or being a merchant. Subeconomies can split, majority hash power can censor (which is the exact mechanism of soft fork enforcement). These ideas are straightforward and hardly worthy of debate. The interesting question is how one gets others to go along with his new coin. Make no mistake, any rule change (soft or hard) is a new coin. If hash power doesn’t enforce the new rules of a soft fork, the chain is split just as if it was a hard fork.

 

I’m sure people will continue to try and devise ways to figure out who wants to come along, to try and convince people (including exchanges and miners) to do so, to reassure them that everyone else will “have to”, and to mislead them about the actual behavior and risks. We’ve seen permanent splits, and we’ve seen hash power enforced soft forks. We’re likely to see more of both. But as core devs we have a responsibility to inform people, honestly, and let them decide. My only beef with this whole process has been that a widespread belief had formed, supported by far too many core devs (and even embedded in the text of deployed BIPs), that soft forks are inherently “backward compatible”. This is unequivocally not true. The only such compatibility is majority hash power enforcement of a soft fork. This is not a matter of opinion, it’s the core innovation of Bitcoin. Proof of Work settles the question of who has authority to order transactions. Majority hash power has that authority. Merchants can split again and again, but their miners will still have that authority. If one wants a say, one can mine.

 

e

 

From: Billy Tetrud <billy.tetrud@gmail.com> 
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric@voskuil.org>
Cc: Jorge Timón <jtimon@jtimon.cc>; Luke Dashjr <luke@dashjr.org>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

 

@Jorge

 

>I don't think we should avoid splits at all costs.

 

I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain. 

 

>  I don't think we should avoid splits when possible, 

 

I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules?

 

Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist? 

 

If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there. 

 

@Luke

 

Are you in agreement with Jorge here that we should not even attempt to avoid chain splits? 

 

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

 

There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future? 

 

I'm asking these questions to try and figure out why we disagree here.


[-- Attachment #2: Type: text/html, Size: 9376 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Zac Greenwood]

[-- Attachment #1: Type: text/plain, Size: 20294 bytes --]

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

Miners don’t 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’ software, then these
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ón <jtimon@jtimon.cc> wrote:
>
> 
> "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 “control” because these statements hinge on that word.
> Nobody “controls” 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 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’s economic. The largest investment in mining (including highest
> 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 others
> agree (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’s 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:
>> >
>> > The 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
>> “better” than the other. The largest merchants are likely 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 rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s
>> 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 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 “needs to” concede once a split has occurred, which 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’s about.
>> That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
>> >>>
>> >>> 
>> >>> 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 bitcoin
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes
>> be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the
>> work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released
>> before
>> >>>> it becomes clear that a large supermajority of users want the
>> upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent
>> failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done
>> 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 risk
>> of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
>> the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my
>> proposal is
>> >>>> materially different - it is the signaling itself that is trinary,
>> not
>> >>>> just which chain is being followed. This allows others to know and
>> make
>> >>>> programmatic decisions (in software) based on that signaling. I'm
>> sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out.
>> Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful,
>> but
>> >>>> there were a significant amount of users that disagreed, and they
>> have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible.
>> Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> 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 the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
>> 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 measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> 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.
>> >>>>
>> >>>>> 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 “compatibility” and
>> the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
>> down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called
>> out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people
>> want.
>> >>>>>>> Given that there is no collective “we”, those wants differ.
>> Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> 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’s time Bitcoiners stop thinking of miners as other
>> people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
>> it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the
>> successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
>> do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated
>> between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside
>> from
>> >>>>>>>>> their role as also being users). The miner involvement is only
>> 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-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In
>> short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
>> >>>>>>>>>> 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 oppose
>> >>>>>>>>>> the change are incentivized to update their software to a
>> version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
>> be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> 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 upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 29704 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 20000 bytes --]

"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:

1) bugs
2) coordination mistakes
3) people wanting different rules.

Let me give an example. Let's say all users want change A.

Only 60% miners want it.
When it activates with LOT=true, will this cause a split?

Well, not necessarily. Since all users will be on the chain with change A,
all miners will quickly abandon that useless chain and start building on
the one that actually pays them.

Do you agree that's what would happen in this example given the assumptions?


On Tue, Jun 29, 2021, 20:44 Eric Voskuil <eric@voskuil.org> wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon@jtimon.cc> wrote:
>
> 
> "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 “control” because these statements hinge on that word.
> Nobody “controls” 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 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’s economic. The largest investment in mining (including highest
> 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 others
> agree (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’s 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:
>> >
>> > The 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
>> “better” than the other. The largest merchants are likely 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 rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces 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’t about that. It’s
>> 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 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 “needs to” concede once a split has occurred, which 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’s about.
>> That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon@jtimon.cc> wrote:
>> >>>
>> >>> 
>> >>> 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 bitcoin
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes
>> be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the
>> work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released
>> before
>> >>>> it becomes clear that a large supermajority of users want the
>> upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent
>> failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done
>> 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 risk
>> of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
>> the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my
>> proposal is
>> >>>> materially different - it is the signaling itself that is trinary,
>> not
>> >>>> just which chain is being followed. This allows others to know and
>> make
>> >>>> programmatic decisions (in software) based on that signaling. I'm
>> sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out.
>> Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful,
>> but
>> >>>> there were a significant amount of users that disagreed, and they
>> have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible.
>> Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> 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 the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
>> 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 measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> 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.
>> >>>>
>> >>>>> 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 “compatibility” and
>> the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
>> down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called
>> out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” 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ón <jtimon@jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people
>> want.
>> >>>>>>> Given that there is no collective “we”, those wants differ.
>> Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> 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’s time Bitcoiners stop thinking of miners as other
>> people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
>> it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the
>> successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
>> do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated
>> between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside
>> from
>> >>>>>>>>> their role as also being users). The miner involvement is only
>> 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-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In
>> short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/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 binary
>> >>>>>>>>>> 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 oppose
>> >>>>>>>>>> the change are incentivized to update their software to a
>> version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
>> be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> 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 upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 28434 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[eric]

> From: Jorge Timón <jtimon@jtimon.cc> 

>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?

There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

"Backward compatibility
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features."

The explanation is however incomplete. If majority hash power does not enforce the new rules, the above is incorrect. Granted the word "operate" is vague, but clearly what is intended is that "non-upgraded" nodes will not be on a different coin. But in fact they would be. The underlying presumption is that BIP141 is not only signaled, but enforced by majority hash power.

>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.

#3 (and possibly #4) is what we're talking about, so it's not at all clear why you said "no".

People change their rules, because #3. If majority hash power does not enforce this (soft) change, it's a chain split.

> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=true, will this cause a split?

No, regardless of percentage adoption. You've proposed that it' is majority hash power enforced.

Furthermore, the term compatibility (see above) implies that not everyone (your impossible presumption of 100%) is aligned.

This is not a debatable subject as far as I'm concerned, but it's worth discussion for those who aren't familiar.

e

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]

@Jorge
> I disagree...  I would oppose such a change no matter what other users or
miners say.

I don't know why you think we disagree on that point. I agree that I would
oppose a change to 1GB blocks no matter what other users or miners say. You
must have misunderstood me there.

>>  Are you really saying that we should just hard fork every time instead
of soft fork?
> No

So what are you advocating for then, exactly?

>> Are you not at all worried about the costs associated with an increased
orphan rate and reorg rate?
> Orphan blocks are bad, yes, not sure what the point of your question is.

The point is that if we just deployed with BIP8 LOT=true (as that seems to
be the kind of thing you're advocating for) and only 60% of miners had
upgraded to the new update by the time it activates, orphans and reorg rate
and depths would greatly increase. The point of the question is: shouldn't
we avoid that "when possible"?

> What do you think of bip99?

I haven't read it before, but after reading it, it seems like a reasonable
discussion of possibilities and types of forks. It looks like you advocated
that "miner voting" is appropriate for some of the types of forks. And yet,
from the way you're talking in this thread, it sounds like you don't think
any consensus rule change deployment should consider miner signaling. So
I'm confused because it seems like the things you're saying here conflict
with some of the things you wrote in BIP99.

What specifically did you want me to get out of BIP99 in this context?

@Eric
> I’d also question the use of the term “majority”

I just want to clarify that by "economic majority" I mean a set of users
that presently accept more than 50% of the volume of payments in a given
period of time. I definitely agree that no majority of any kind is needed
for a split.


On Wed, Jun 30, 2021 at 2:52 AM <eric@voskuil.org> wrote:

> > From: Jorge Timón <jtimon@jtimon.cc>
>
> >> "Soft forks aren’t compatible without miner enforcement"
> > Compatible with what?
>
> There is a good summary of what is meant by this term in BIP141:
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
>
> "Backward compatibility
> As a soft fork, older software will continue to operate without
> modification. Non-upgraded nodes, however, will not see nor validate the
> witness data and will consider all witness programs as anyone-can-spend
> scripts (except a few edge cases where the witness programs are equal to 0,
> which the script must fail). Wallets should always be wary of
> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
> are strongly encouraged to upgrade in order to take advantage of the new
> features."
>
> The explanation is however incomplete. If majority hash power does not
> enforce the new rules, the above is incorrect. Granted the word "operate"
> is vague, but clearly what is intended is that "non-upgraded" nodes will
> not be on a different coin. But in fact they would be. The underlying
> presumption is that BIP141 is not only signaled, but enforced by majority
> hash power.
>
> >> "Soft forks without miner support cause splits".
> > No, what causes splits are 3 things:
> >
> > 1) bugs
> > 2) coordination mistakes
> > 3) people wanting different rules.
>
> #3 (and possibly #4) is what we're talking about, so it's not at all clear
> why you said "no".
>
> People change their rules, because #3. If majority hash power does not
> enforce this (soft) change, it's a chain split.
>
> > Let me give an example. Let's say all users want change A.
> >
> > Only 60% miners want it.
> > When it activates with LOT=true, will this cause a split?
>
> No, regardless of percentage adoption. You've proposed that it' is
> majority hash power enforced.
>
> Furthermore, the term compatibility (see above) implies that not everyone
> (your impossible presumption of 100%) is aligned.
>
> This is not a debatable subject as far as I'm concerned, but it's worth
> discussion for those who aren't familiar.
>
> e
>
>

[-- Attachment #2: Type: text/html, Size: 5327 bytes --]

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 5868 bytes --]

It feels like this discussion has gotten a bit off topic. The proposal is
intended to provide a best-of-both-worlds middleground between BIP8 and
BIP9. It would be nice if we could bring it back to a discussion of my
proposal in the context of other existing deployment plans (BIP8, BIP9,
taproot's hybrid deployment, even flag days).

The main relevant actually to my proposal that have been mentioned, as far
as I can tell, is that Luke opined that explicit signaling of opposition
was unnecessary, because he thinks we shouldn't try to avoid chain splits
when there's any opposition. Jorge agreed that we shouldn't try to avoid
chain splits. But I don't really understand what either of you (Luke or
Jorge) are actually proposing is better than using my proposal. Are you
proposing LOT=true be added as an option to my proposal? Are you proposing
that we should always use a LOT=true style flag day, and not even consider
the option of permanent failure for a deployment? Or are you simply saying
that miner opposition is never relevant or useful to know during a
deployment?

Everything else has been only tenuously related:

* Who "controls" or "defines" bitcoin"?
* Who "controls" what happens during a deployment?
* Should we deploy based on miner signaling at all?

If there's so much to discuss on these philosophical points, maybe it makes
sense to branch that off into a separate thread. I'd appreciate it if we
can reconnect this discussion with the proposal this thread is about.



On Wed, Jun 30, 2021 at 12:30 PM Billy Tetrud <billy.tetrud@gmail.com>
wrote:

> @Jorge
> > I disagree...  I would oppose such a change no matter what other users
> or miners say.
>
> I don't know why you think we disagree on that point. I agree that I would
> oppose a change to 1GB blocks no matter what other users or miners say. You
> must have misunderstood me there.
>
> >>  Are you really saying that we should just hard fork every time
> instead of soft fork?
> > No
>
> So what are you advocating for then, exactly?
>
> >> Are you not at all worried about the costs associated with an
> increased orphan rate and reorg rate?
> > Orphan blocks are bad, yes, not sure what the point of your question is.
>
> The point is that if we just deployed with BIP8 LOT=true (as that seems to
> be the kind of thing you're advocating for) and only 60% of miners had
> upgraded to the new update by the time it activates, orphans and reorg rate
> and depths would greatly increase. The point of the question is: shouldn't
> we avoid that "when possible"?
>
> > What do you think of bip99?
>
> I haven't read it before, but after reading it, it seems like a reasonable
> discussion of possibilities and types of forks. It looks like you advocated
> that "miner voting" is appropriate for some of the types of forks. And yet,
> from the way you're talking in this thread, it sounds like you don't think
> any consensus rule change deployment should consider miner signaling. So
> I'm confused because it seems like the things you're saying here conflict
> with some of the things you wrote in BIP99.
>
> What specifically did you want me to get out of BIP99 in this context?
>
> @Eric
> > I’d also question the use of the term “majority”
>
> I just want to clarify that by "economic majority" I mean a set of users
> that presently accept more than 50% of the volume of payments in a given
> period of time. I definitely agree that no majority of any kind is needed
> for a split.
>
>
> On Wed, Jun 30, 2021 at 2:52 AM <eric@voskuil.org> wrote:
>
>> > From: Jorge Timón <jtimon@jtimon.cc>
>>
>> >> "Soft forks aren’t compatible without miner enforcement"
>> > Compatible with what?
>>
>> There is a good summary of what is meant by this term in BIP141:
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
>>
>> "Backward compatibility
>> As a soft fork, older software will continue to operate without
>> modification. Non-upgraded nodes, however, will not see nor validate the
>> witness data and will consider all witness programs as anyone-can-spend
>> scripts (except a few edge cases where the witness programs are equal to 0,
>> which the script must fail). Wallets should always be wary of
>> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
>> are strongly encouraged to upgrade in order to take advantage of the new
>> features."
>>
>> The explanation is however incomplete. If majority hash power does not
>> enforce the new rules, the above is incorrect. Granted the word "operate"
>> is vague, but clearly what is intended is that "non-upgraded" nodes will
>> not be on a different coin. But in fact they would be. The underlying
>> presumption is that BIP141 is not only signaled, but enforced by majority
>> hash power.
>>
>> >> "Soft forks without miner support cause splits".
>> > No, what causes splits are 3 things:
>> >
>> > 1) bugs
>> > 2) coordination mistakes
>> > 3) people wanting different rules.
>>
>> #3 (and possibly #4) is what we're talking about, so it's not at all
>> clear why you said "no".
>>
>> People change their rules, because #3. If majority hash power does not
>> enforce this (soft) change, it's a chain split.
>>
>> > Let me give an example. Let's say all users want change A.
>> >
>> > Only 60% miners want it.
>> > When it activates with LOT=true, will this cause a split?
>>
>> No, regardless of percentage adoption. You've proposed that it' is
>> majority hash power enforced.
>>
>> Furthermore, the term compatibility (see above) implies that not everyone
>> (your impossible presumption of 100%) is aligned.
>>
>> This is not a debatable subject as far as I'm concerned, but it's worth
>> discussion for those who aren't familiar.
>>
>> e
>>
>>

[-- Attachment #2: Type: text/html, Size: 7410 bytes --]