[bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Michael Folkson]

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@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Ariel Lorenzo-Luaces]

[-- Attachment #1: Type: text/plain, Size: 5180 bytes --]

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@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@gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5494 bytes --]

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Luke Dashjr]

On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
> 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.

No. Miners enforcing rules without the social support is a 51% attack, not a 
softfork.

> 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.

No, LOT=True doesn't do this. It only happens if miners choose to create an 
invalid chain, which they could do at any time with or without a softfork 
involved.

Luke

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Ariel Lorenzo-Luaces]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

You can try to redefine all you want but it doesn't make what you're saying true.

A soft fork is a constriction of rules

A 51% attack is a soft fork with majority mining power.

I didn't say that LOT=true does it I said that it must achieve 51% miner support to pose reorg risks to force apathetic users into paying attention. Please read my message again.

Your definition of invalid has no power here. We are all painfully aware of your semantic mental gymnastics.

Cheers
Ariel Lorenzo-Luaces


On Mar 2, 2021, 10:58 AM, at 10:58 AM, Luke Dashjr <luke@dashjr.org> wrote:
>On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev
>wrote:
>> 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.
>
>No. Miners enforcing rules without the social support is a 51% attack,
>not a
>softfork.
>
>> 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.
>
>No, LOT=True doesn't do this. It only happens if miners choose to
>create an
>invalid chain, which they could do at any time with or without a
>softfork
>involved.
>
>Luke

[-- Attachment #2: Type: text/html, Size: 2405 bytes --]

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Eric Voskuil]

I personally don’t like the term 51% attack as applied to censorship. A miner is free to mine or not mine any transactions it wants (censor). The term attack is better reserved for stealing from someone (reclaiming spends using hash power), as it implies a moral distinction.

But 51% attack is the term in common use for a majority censor and using it helps people understand the mechanism of hash power soft fork enforcement. It’s not intended as a pejorative. 

However “without social support” is a political term. It confuses the actual behavior to imply the mechanism is somehow not the same because there is some ill-defined level of agreement.

e


> On Mar 2, 2021, at 10:58, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
>> 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.
> 
> No. Miners enforcing rules without the social support is a 51% attack, not a 
> softfork.
> 
>> 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.
> 
> No, LOT=True doesn't do this. It only happens if miners choose to create an 
> invalid chain, which they could do at any time with or without a softfork 
> involved.
> 
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev