public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Trinary Version Signaling for softfork upgrades
@ 2021-06-26 20:21 Billy Tetrud
  2021-06-26 21:13 ` Luke Dashjr
  0 siblings, 1 reply; 20+ messages in thread
From: Billy Tetrud @ 2021-06-26 20:21 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion


[-- 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 --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

• * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
    2021-06-26 20:21 [bitcoin-dev] Trinary Version Signaling for softfork upgrades Billy Tetrud
  @ 2021-06-26 21:13 ` Luke Dashjr
    2021-06-26 21:43   ` Eric Voskuil
    0 siblings, 1 reply; 20+ messages in thread
  From: Luke Dashjr @ 2021-06-26 21:13 UTC (permalink / raw)
    To: bitcoin-dev, Billy Tetrud
  
  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
  
  
  
  ^ permalink raw reply	[flat|nested] 20+ messages in thread

• • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
      2021-06-26 21:13 ` Luke Dashjr
    @ 2021-06-26 21:43   ` Eric Voskuil
      2021-06-26 22:05     ` Eric Voskuil
      0 siblings, 1 reply; 20+ messages in thread
    From: Eric Voskuil @ 2021-06-26 21:43 UTC (permalink / raw)
      To: Luke Dashjr, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
    
    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
    
    
    ^ permalink raw reply	[flat|nested] 20+ messages in thread

  • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
        2021-06-26 21:43   ` Eric Voskuil
      @ 2021-06-26 22:05     ` Eric Voskuil
        2021-06-27  8:47       ` Jorge Timón
        0 siblings, 1 reply; 20+ messages in thread
      From: Eric Voskuil @ 2021-06-26 22:05 UTC (permalink / raw)
        To: Luke Dashjr, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
      
      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
      
      
      ^ permalink raw reply	[flat|nested] 20+ messages in thread

    • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
          2021-06-26 22:05     ` Eric Voskuil
        @ 2021-06-27  8:47       ` Jorge Timón
          2021-06-27  9:21         ` Eric Voskuil
          0 siblings, 1 reply; 20+ messages in thread
        From: Jorge Timón @ 2021-06-27  8:47 UTC (permalink / raw)
          To: Eric Voskuil, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
        
        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
        
        
        ^ permalink raw reply	[flat|nested] 20+ messages in thread

      • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
            2021-06-27  8:47       ` Jorge Timón
          @ 2021-06-27  9:21         ` Eric Voskuil
            2021-06-27 18:11           ` Billy Tetrud
            0 siblings, 1 reply; 20+ messages in thread
          From: Eric Voskuil @ 2021-06-27  9:21 UTC (permalink / raw)
            To: Jorge Timón; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
          
          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
          
          
          ^ permalink raw reply	[flat|nested] 20+ messages in thread

        • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
              2021-06-27  9:21         ` Eric Voskuil
            @ 2021-06-27 18:11           ` Billy Tetrud
              2021-06-29  8:32             ` Jorge Timón
              0 siblings, 1 reply; 20+ messages in thread
            From: Billy Tetrud @ 2021-06-27 18:11 UTC (permalink / raw)
              To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
            
            [-- 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 --]
            
            ^ permalink raw reply	[flat|nested] 20+ messages in thread

          • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                2021-06-27 18:11           ` Billy Tetrud
              @ 2021-06-29  8:32             ` Jorge Timón
                2021-06-29  8:44               ` Eric Voskuil
                0 siblings, 1 reply; 20+ messages in thread
              From: Jorge Timón @ 2021-06-29  8:32 UTC (permalink / raw)
                To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
              
              [-- 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 --]
              
              ^ permalink raw reply	[flat|nested] 20+ messages in thread

            • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                  2021-06-29  8:32             ` Jorge Timón
                @ 2021-06-29  8:44               ` Eric Voskuil
                  2021-06-29 17:55                 ` Luke Dashjr
                  0 siblings, 1 reply; 20+ messages in thread
                From: Eric Voskuil @ 2021-06-29  8:44 UTC (permalink / raw)
                  To: Jorge Timón; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                
                [-- 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 --]
                
                ^ permalink raw reply	[flat|nested] 20+ messages in thread

              • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                    2021-06-29  8:44               ` Eric Voskuil
                  @ 2021-06-29 17:55                 ` Luke Dashjr
                    2021-06-29 18:17                   ` Eric Voskuil
                    0 siblings, 1 reply; 20+ messages in thread
                  From: Luke Dashjr @ 2021-06-29 17:55 UTC (permalink / raw)
                    To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                  
                  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
                  
                  
                  
                  ^ permalink raw reply	[flat|nested] 20+ messages in thread

                • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                      2021-06-29 17:55                 ` Luke Dashjr
                    @ 2021-06-29 18:17                   ` Eric Voskuil
                      2021-06-29 19:28                     ` Jorge Timón
                      0 siblings, 1 reply; 20+ messages in thread
                    From: Eric Voskuil @ 2021-06-29 18:17 UTC (permalink / raw)
                      To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                    
                    
                    > 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
                    > 
                    
                    
                    ^ permalink raw reply	[flat|nested] 20+ messages in thread

                  • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                        2021-06-29 18:17                   ` Eric Voskuil
                      @ 2021-06-29 19:28                     ` Jorge Timón
                        2021-06-29 19:44                       ` Eric Voskuil
                        0 siblings, 1 reply; 20+ messages in thread
                      From: Jorge Timón @ 2021-06-29 19:28 UTC (permalink / raw)
                        To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                      
                      [-- 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 --]
                      
                      ^ permalink raw reply	[flat|nested] 20+ messages in thread

                    • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                          2021-06-29 19:28                     ` Jorge Timón
                        @ 2021-06-29 19:44                       ` Eric Voskuil
                          2021-06-30  2:02                         ` Billy Tetrud
                                                                   ` (2 more replies)
                          0 siblings, 3 replies; 20+ messages in thread
                        From: Eric Voskuil @ 2021-06-29 19:44 UTC (permalink / raw)
                          To: Jorge Timón; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                        
                        [-- 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 --]
                        
                        ^ permalink raw reply	[flat|nested] 20+ messages in thread

                      • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                            2021-06-29 19:44                       ` Eric Voskuil
                          @ 2021-06-30  2:02                         ` Billy Tetrud
                            2021-06-30  8:55                           ` eric
                            2021-06-30  6:39                         ` Zac Greenwood
                            2021-06-30  9:16                         ` Jorge Timón
                            2 siblings, 1 reply; 20+ messages in thread
                          From: Billy Tetrud @ 2021-06-30  2:02 UTC (permalink / raw)
                            To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
                          
                          [-- 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 --]
                          
                          ^ permalink raw reply	[flat|nested] 20+ messages in thread

                        • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                              2021-06-30  2:02                         ` Billy Tetrud
                            @ 2021-06-30  8:55                           ` eric
                              0 siblings, 0 replies; 20+ messages in thread
                            From: eric @ 2021-06-30  8:55 UTC (permalink / raw)
                              To: 'Billy Tetrud'; +Cc: 'Bitcoin Protocol Discussion'
                            
                            [-- 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 --]
                            
                            ^ permalink raw reply	[flat|nested] 20+ messages in thread

                        • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                            2021-06-29 19:44                       ` Eric Voskuil
                            2021-06-30  2:02                         ` Billy Tetrud
                          @ 2021-06-30  6:39                         ` Zac Greenwood
                            2021-06-30  9:16                         ` Jorge Timón
                            2 siblings, 0 replies; 20+ messages in thread
                          From: Zac Greenwood @ 2021-06-30  6:39 UTC (permalink / raw)
                            To: Bitcoin Protocol Discussion, Eric Voskuil; +Cc: Billy Tetrud
                          
                          [-- 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 --]
                          
                          ^ permalink raw reply	[flat|nested] 20+ messages in thread

                        • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                            2021-06-29 19:44                       ` Eric Voskuil
                            2021-06-30  2:02                         ` Billy Tetrud
                            2021-06-30  6:39                         ` Zac Greenwood
                          @ 2021-06-30  9:16                         ` Jorge Timón
                            2021-06-30  9:52                           ` eric
                            2 siblings, 1 reply; 20+ messages in thread
                          From: Jorge Timón @ 2021-06-30  9:16 UTC (permalink / raw)
                            To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
                          
                          [-- 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 --]
                          
                          ^ permalink raw reply	[flat|nested] 20+ messages in thread

                        • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                              2021-06-30  9:16                         ` Jorge Timón
                            @ 2021-06-30  9:52                           ` eric
                              2021-06-30 19:30                             ` Billy Tetrud
                              0 siblings, 1 reply; 20+ messages in thread
                            From: eric @ 2021-06-30  9:52 UTC (permalink / raw)
                              To: 'Jorge Timón'
                              Cc: 'Bitcoin Protocol Discussion', 'Billy Tetrud'
                            
                            > 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
                            
                            
                            
                            ^ permalink raw reply	[flat|nested] 20+ messages in thread

                          • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                                2021-06-30  9:52                           ` eric
                              @ 2021-06-30 19:30                             ` Billy Tetrud
                                2021-06-30 19:42                               ` Billy Tetrud
                                0 siblings, 1 reply; 20+ messages in thread
                              From: Billy Tetrud @ 2021-06-30 19:30 UTC (permalink / raw)
                                To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
                              
                              [-- 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 --]
                              
                              ^ permalink raw reply	[flat|nested] 20+ messages in thread

                            • • * Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
                                  2021-06-30 19:30                             ` Billy Tetrud
                                @ 2021-06-30 19:42                               ` Billy Tetrud
                                  0 siblings, 0 replies; 20+ messages in thread
                                From: Billy Tetrud @ 2021-06-30 19:42 UTC (permalink / raw)
                                  To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
                                
                                [-- 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 --]
                                
                                ^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-06-30 19:43 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-26 20:21 [bitcoin-dev] Trinary Version Signaling for softfork upgrades Billy Tetrud
2021-06-26 21:13 ` Luke Dashjr
2021-06-26 21:43   ` Eric Voskuil
2021-06-26 22:05     ` Eric Voskuil
2021-06-27  8:47       ` Jorge Timón
2021-06-27  9:21         ` Eric Voskuil
2021-06-27 18:11           ` Billy Tetrud
2021-06-29  8:32             ` Jorge Timón
2021-06-29  8:44               ` Eric Voskuil
2021-06-29 17:55                 ` Luke Dashjr
2021-06-29 18:17                   ` Eric Voskuil
2021-06-29 19:28                     ` Jorge Timón
2021-06-29 19:44                       ` Eric Voskuil
2021-06-30  2:02                         ` Billy Tetrud
2021-06-30  8:55                           ` eric
2021-06-30  6:39                         ` Zac Greenwood
2021-06-30  9:16                         ` Jorge Timón
2021-06-30  9:52                           ` eric
2021-06-30 19:30                             ` Billy Tetrud
2021-06-30 19:42                               ` Billy Tetrud

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox