> 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
