Billy Tetrud [ARCHIVE] on Nostr: đź“… Original date posted:2021-06-27 đź“ť Original message:@Luke > They can still ...
đź“… Original date posted:2021-06-27
đź“ť Original message:@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 at 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210627/e5faf2f4/attachment-0001.html>;
đź“ť Original message:@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 at 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210627/e5faf2f4/attachment-0001.html>;