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, 5:54 AM, at 5:54 AM, Erik Aronesty 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 > wrote: >> >> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev >> 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 > 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