I agree.

Thank you Erik for proposing it. It's a pretty good idea.

P.S. I wouldn't want a chain split of a low percentage of users though. The minority will be at the mercy of massive PoW swings and the chain will lose friends so it's not good for anyone. I recommend changing the final percentage to %50 because that's the hurdle where non-upgraded users *must* activate to avoid the risk of being reorged. The number of running users will quickly jump to 90%+ if it ever gets near 50%.

Cheers
Ariel Lorenzo-Luaces

On Mar 1, 2021, at 5:54 AM, Erik Aronesty <erik@q32.com> wrote:
 Today users should start cooperating again to continue using the
 optimal strategy.

the "gradual" method of reducing the % of miners required for lock-in
as time goes on seems to encode this optimal strategy.

On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

 On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
 <bitcoin-dev@lists.linuxfoundation.org> wrote:

 If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.

 Where am I wrong here?

 Keagan

 On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

 Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).

 Cheers,

 Jeremy



 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

 To favor LOT=true because it seems like the inevitable result is like
 playing the prisoner's dilemma and never cooperating instead of using
 the most optimal strategy which is tit-for-tat (cooperating at first
 and then cheating once for every time your counterparty cheats).

 During segwit users started by cooperating (BIP9, or "LOT=false"),
 then a minority of
 miners didn't cooperate (small veto but remember the majority of
 miners cooperated), then users stopped cooperating in response (UASF),
 then miners
 reverted to cooperating (MASF while intolerant miners forked off).
 Today users should start cooperating again to continue using the
 optimal strategy.

 Cheers
 Ariel Lorenzo-Luaces

 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev