Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: đź“… Original date posted:2021-03-02 đź“ť Original message:It's becoming increasingly ...
đź“… Original date posted:2021-03-02
đź“ť Original message:It's becoming increasingly clear that core might not be able to release activation code.
Anyone advocating for a UASF must do tremendous amounts of work to convince users, miners, and service providers to run a UASF client. Anyone advocating against a UASF or indifferent will take the path of least resistance and ignore the rogue client. If the movement fails to materialize we will be looking at a minor chain split one year later and a year of wasted time. At that moment LOT=false can be finally released and calmer heads can activate on the majority chain.
The choice has never been LOT=false versus LOT=true. It has always been about the order. Some think LOT=true should be attempted first and some think LOT=false should be attempted first. And the grand majority are indifferent to the choice (won't upgrade until core says it's safe).
I'm realizing that a clear advantage of LOT=false is that it can happen without the need for a social movement. All that is really needed is the convincing of 95% miners. Apathetic users will never notice any kind of service disruption no matter the success or failure of the activation. This is obviously why it naturally became the default activation method.
While LOT=true, on the other hand, must be able to 51% the blockchain to win the apathetic users. But then the reorgs will not be pretty. Or if it ever clearly gets over the 51% hurdle then all apathetic users now need to scramble to use the rogue client to be safe from reorgs. Either way it's disruptive.
Please, I'm begging you, let's just try LOT=false first. Let's halt the fight for this new UASF movement until it's needed. Social movements are hard. Especially hard when the people you're trying to convince don't have a material threat to their beliefs or freedoms. It would be a shame to meet back here a year later after the risk of verbal conflicts, misdirection, lies, vilinization, reorgs, double spends, PoW changes, and threats galore.
P.S. I don't think I'm being so apocalyptic this time. I actually see all of those things as *necessary* to the UASF movement. Otherwise people won't be convinced to take a side.
Cheers
Ariel Lorenzo-Luaces
On Mar 1, 2021, 1:06 PM, at 1:06 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>It is approximately 8 months since Steve Lee formally kicked off the
>Taproot activation discussion by setting up the ##taproot-activation
>IRC channel. Obviously there was discussion that considerably predates
>that but that was the first recognition that there needed to be a
>focus towards a solution rather than endless circular debates.
>
>Eight months on it appears there are some who think there is a
>philosopher’s stone still out there that will garner 100 percent
>consensus and contain zero chain split risk in the worst case
>scenario. A philosopher’s stone that us mere mortals have failed to
>find in these 8 months.
>
>While I would be delighted if this philosopher’s stone is found (and
>all are free to continue looking) I think it is prudent at this point
>to step away from the circular arguments and build on the progress we
>have made in these last 8 months. We have effectively achieved
>overwhelming consensus on the activation mechanism (BIP 8) and all of
>the parameters apart from one (lockinontimeout or LOT). Again I’d like
>to thank the people who have put hours of work into getting to this
>point. It is thankless work and it is probably the last thing any of
>us want to be doing.
>
>At this point it is unclear whether Bitcoin Core will be able to
>release any activation code whatsoever due to disagreement logjams.
>Personally I hope they do but again it is prudent to prepare for the
>scenario where Core is unable to. Hence I and others have assessed
>that our energies are better spent working on a community release
>implementing LOT=true in a similar spirit to 2017’s UASF effort. I say
>similar as this time there really is no need for any antagonism.
>Approximately 90 percent of mining pools (taprootactivation.com) have
>declared support and there is overwhelming community consensus to
>activate Taproot. In the absence of a Core release with activation
>code I hope and expect all users (including miners) to consider
>supporting this UASF release and consider running it to activate
>Taproot.
>
>TL;DR Tomorrow (Tuesday) we are holding a kick off meeting for this
>UASF (LOT=true) effort on the ##uasf IRC channel at 19:00 UTC. Please
>consider attending and supporting this effort to get Taproot
>activated. It would be great to get users from the 2017 effort
>involved in addition to recent Taproot proponents from all parts of
>our community. The future of Bitcoin’s scalability and privacy depends
>on, as it always has, on you the user.
>
>--
>Michael Folkson
>Email: michaelfolkson at gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>_______________________________________________
>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/20210302/1722c7a2/attachment-0001.html>;
đź“ť Original message:It's becoming increasingly clear that core might not be able to release activation code.
Anyone advocating for a UASF must do tremendous amounts of work to convince users, miners, and service providers to run a UASF client. Anyone advocating against a UASF or indifferent will take the path of least resistance and ignore the rogue client. If the movement fails to materialize we will be looking at a minor chain split one year later and a year of wasted time. At that moment LOT=false can be finally released and calmer heads can activate on the majority chain.
The choice has never been LOT=false versus LOT=true. It has always been about the order. Some think LOT=true should be attempted first and some think LOT=false should be attempted first. And the grand majority are indifferent to the choice (won't upgrade until core says it's safe).
I'm realizing that a clear advantage of LOT=false is that it can happen without the need for a social movement. All that is really needed is the convincing of 95% miners. Apathetic users will never notice any kind of service disruption no matter the success or failure of the activation. This is obviously why it naturally became the default activation method.
While LOT=true, on the other hand, must be able to 51% the blockchain to win the apathetic users. But then the reorgs will not be pretty. Or if it ever clearly gets over the 51% hurdle then all apathetic users now need to scramble to use the rogue client to be safe from reorgs. Either way it's disruptive.
Please, I'm begging you, let's just try LOT=false first. Let's halt the fight for this new UASF movement until it's needed. Social movements are hard. Especially hard when the people you're trying to convince don't have a material threat to their beliefs or freedoms. It would be a shame to meet back here a year later after the risk of verbal conflicts, misdirection, lies, vilinization, reorgs, double spends, PoW changes, and threats galore.
P.S. I don't think I'm being so apocalyptic this time. I actually see all of those things as *necessary* to the UASF movement. Otherwise people won't be convinced to take a side.
Cheers
Ariel Lorenzo-Luaces
On Mar 1, 2021, 1:06 PM, at 1:06 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>It is approximately 8 months since Steve Lee formally kicked off the
>Taproot activation discussion by setting up the ##taproot-activation
>IRC channel. Obviously there was discussion that considerably predates
>that but that was the first recognition that there needed to be a
>focus towards a solution rather than endless circular debates.
>
>Eight months on it appears there are some who think there is a
>philosopher’s stone still out there that will garner 100 percent
>consensus and contain zero chain split risk in the worst case
>scenario. A philosopher’s stone that us mere mortals have failed to
>find in these 8 months.
>
>While I would be delighted if this philosopher’s stone is found (and
>all are free to continue looking) I think it is prudent at this point
>to step away from the circular arguments and build on the progress we
>have made in these last 8 months. We have effectively achieved
>overwhelming consensus on the activation mechanism (BIP 8) and all of
>the parameters apart from one (lockinontimeout or LOT). Again I’d like
>to thank the people who have put hours of work into getting to this
>point. It is thankless work and it is probably the last thing any of
>us want to be doing.
>
>At this point it is unclear whether Bitcoin Core will be able to
>release any activation code whatsoever due to disagreement logjams.
>Personally I hope they do but again it is prudent to prepare for the
>scenario where Core is unable to. Hence I and others have assessed
>that our energies are better spent working on a community release
>implementing LOT=true in a similar spirit to 2017’s UASF effort. I say
>similar as this time there really is no need for any antagonism.
>Approximately 90 percent of mining pools (taprootactivation.com) have
>declared support and there is overwhelming community consensus to
>activate Taproot. In the absence of a Core release with activation
>code I hope and expect all users (including miners) to consider
>supporting this UASF release and consider running it to activate
>Taproot.
>
>TL;DR Tomorrow (Tuesday) we are holding a kick off meeting for this
>UASF (LOT=true) effort on the ##uasf IRC channel at 19:00 UTC. Please
>consider attending and supporting this effort to get Taproot
>activated. It would be great to get users from the 2017 effort
>involved in addition to recent Taproot proponents from all parts of
>our community. The future of Bitcoin’s scalability and privacy depends
>on, as it always has, on you the user.
>
>--
>Michael Folkson
>Email: michaelfolkson at gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>_______________________________________________
>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/20210302/1722c7a2/attachment-0001.html>;