Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-26 📝 Original message:Given the recent ...
📅 Original date posted:2021-06-26
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thresholdChart.png
Type: image/png
Size: 11132 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.png>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thresholdChart.png
Type: image/png
Size: 11132 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.png>;
