* [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel @ 2021-03-01 17:47 Michael Folkson 2021-03-02 18:22 ` Ariel Lorenzo-Luaces 0 siblings, 1 reply; 5+ messages in thread From: Michael Folkson @ 2021-03-01 17:47 UTC (permalink / raw) To: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel 2021-03-01 17:47 [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel Michael Folkson @ 2021-03-02 18:22 ` Ariel Lorenzo-Luaces 2021-03-02 18:57 ` Luke Dashjr 0 siblings, 1 reply; 5+ messages in thread From: Ariel Lorenzo-Luaces @ 2021-03-02 18:22 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel 2021-03-02 18:22 ` Ariel Lorenzo-Luaces @ 2021-03-02 18:57 ` Luke Dashjr 2021-03-02 19:36 ` Ariel Lorenzo-Luaces 2021-03-02 20:19 ` Eric Voskuil 0 siblings, 2 replies; 5+ messages in thread From: Luke Dashjr @ 2021-03-02 18:57 UTC (permalink / raw) To: bitcoin-dev, Ariel Lorenzo-Luaces; +Cc: Michael Folkson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel 2021-03-02 18:57 ` Luke Dashjr @ 2021-03-02 19:36 ` Ariel Lorenzo-Luaces 2021-03-02 20:19 ` Eric Voskuil 1 sibling, 0 replies; 5+ messages in thread From: Ariel Lorenzo-Luaces @ 2021-03-02 19:36 UTC (permalink / raw) To: Luke Dashjr; +Cc: Michael Folkson, bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel 2021-03-02 18:57 ` Luke Dashjr 2021-03-02 19:36 ` Ariel Lorenzo-Luaces @ 2021-03-02 20:19 ` Eric Voskuil 1 sibling, 0 replies; 5+ messages in thread From: Eric Voskuil @ 2021-03-02 20:19 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion; +Cc: Michael Folkson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-02 20:19 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-01 17:47 [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel Michael Folkson 2021-03-02 18:22 ` Ariel Lorenzo-Luaces 2021-03-02 18:57 ` Luke Dashjr 2021-03-02 19:36 ` Ariel Lorenzo-Luaces 2021-03-02 20:19 ` Eric Voskuil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox