Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-07 📝 Original message:Hi Carlo This your ...
📅 Original date posted:2021-03-07
📝 Original message:Hi Carlo
This your proposal is similar to the Simple Majority Activation proposal (SMA). The difference is that your proposal has the final activation threshold set to 80% and SMA has it set to 51% https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html
The problem with what you're proposing is what do users do if signaling is somewhere between 51% to 79%? Users that want to promote a UASF know that their miner majority can activate Taproot and activate without the 21% to 49% of miners needing to signal (or purposefully stalling). A UASF knows they have majority mining power so there is little risk to them and a big reward (activating Taproot) so they are incentivized to do a UASF.
A UASF with a miner majority can scare everyone else about them being at risk of big reorgs to gain traction and followers.
With the same proposal but the final threshold set to 51% instead of 80% there can't be risk of a UASF because if 51% is not reached they know they don't have enough miner support to keep the chain together.
If support is less than 50% a UASF movement needs to hard fork anyway to change the PoW (for protection) and change addresses to prevent double spends.
I really like the SMA proposal with 51% because it removes the incentive to do a UASF.
Cheers
Ariel Lorenzo-Luaces
On Mar 7, 2021, 6:37 AM, at 6:37 AM, Carlo Spiller via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi everybody
>
>I'm new to this list, but not new to Bitcoin, having skin in the game
>since 2014. I was there for the scaling war and the drama around
>SegWit,
>as a simple user. This time, I run my own full node and follow
>development. I hope to bring something new to the table.
>
>Having witnessed the miner's unwillingness to activate SegWit truly
>makes me concerened for a simple LOT=false. After reading the
>discussion
>now for some time and thinking about it myself, I have come to the
>following proposal.
>
>Initially deploy with LOT=false and an activation threshold of 95% of
>miner signaling.
>
>*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
>
>of hashpower signaled for the upgrade, LOT gets a lock-in date another
>6
>months later and the threshold for MASF is lowered to 90%.
>
>If after the initial 6 months of signaling with LOT=false, 80% is not
>reached, the proposal expires.
>
>This way, a small percent of hashpower does not get to stall
>activation,
>rather, 80% of hashpower can activate LOT=true, and later, 90% can
>activate Taproot. If a flaw is found in Taproot in the first six months
>
>(unlikely anyway), miners simply don't signal and the proposal expires.
>
>If miners don't signal at all, only six months are lost, before a new
>activation logic can be deployed.
>
>Don't mind this if something similar was already proposed somewhere
>else.
>
>Best
>
>Carlo
>
>_______________________________________________
>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/20210307/f99a9224/attachment.html>;
📝 Original message:Hi Carlo
This your proposal is similar to the Simple Majority Activation proposal (SMA). The difference is that your proposal has the final activation threshold set to 80% and SMA has it set to 51% https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html
The problem with what you're proposing is what do users do if signaling is somewhere between 51% to 79%? Users that want to promote a UASF know that their miner majority can activate Taproot and activate without the 21% to 49% of miners needing to signal (or purposefully stalling). A UASF knows they have majority mining power so there is little risk to them and a big reward (activating Taproot) so they are incentivized to do a UASF.
A UASF with a miner majority can scare everyone else about them being at risk of big reorgs to gain traction and followers.
With the same proposal but the final threshold set to 51% instead of 80% there can't be risk of a UASF because if 51% is not reached they know they don't have enough miner support to keep the chain together.
If support is less than 50% a UASF movement needs to hard fork anyway to change the PoW (for protection) and change addresses to prevent double spends.
I really like the SMA proposal with 51% because it removes the incentive to do a UASF.
Cheers
Ariel Lorenzo-Luaces
On Mar 7, 2021, 6:37 AM, at 6:37 AM, Carlo Spiller via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi everybody
>
>I'm new to this list, but not new to Bitcoin, having skin in the game
>since 2014. I was there for the scaling war and the drama around
>SegWit,
>as a simple user. This time, I run my own full node and follow
>development. I hope to bring something new to the table.
>
>Having witnessed the miner's unwillingness to activate SegWit truly
>makes me concerened for a simple LOT=false. After reading the
>discussion
>now for some time and thinking about it myself, I have come to the
>following proposal.
>
>Initially deploy with LOT=false and an activation threshold of 95% of
>miner signaling.
>
>*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
>
>of hashpower signaled for the upgrade, LOT gets a lock-in date another
>6
>months later and the threshold for MASF is lowered to 90%.
>
>If after the initial 6 months of signaling with LOT=false, 80% is not
>reached, the proposal expires.
>
>This way, a small percent of hashpower does not get to stall
>activation,
>rather, 80% of hashpower can activate LOT=true, and later, 90% can
>activate Taproot. If a flaw is found in Taproot in the first six months
>
>(unlikely anyway), miners simply don't signal and the proposal expires.
>
>If miners don't signal at all, only six months are lost, before a new
>activation logic can be deployed.
>
>Don't mind this if something similar was already proposed somewhere
>else.
>
>Best
>
>Carlo
>
>_______________________________________________
>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/20210307/f99a9224/attachment.html>;