MIME-Version: 1.0
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
 <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
 <CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
 <CABm2gDp5dRTrPEqPfrjOeeYBn6RMS=HFMbtkJ+MM0SMVnSfK5A@mail.gmail.com>
 <CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
 <CALeFGL1UbXx14aX7RK7nh7b4jwvmfF6AXrvqPJpriSB4ZvYT2A@mail.gmail.com>
 <CAOv1TnhQcYrc5q6GTUTuQMEi9RAV4dy5mmyNp--HuYTPzEUfJQ@mail.gmail.com>
In-Reply-To: <CAOv1TnhQcYrc5q6GTUTuQMEi9RAV4dy5mmyNp--HuYTPzEUfJQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 1 Mar 2021 08:54:34 -0500
Message-ID: <CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com>
To: Ariel Luaces <arielluaces@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
Precedence: list

> 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 othe=
r way around it seems as if there cannot exist a valid (rational?) reason t=
o oppose Taproot itself, and then by extension with the arguments laid out =
above, LOT=3Dtrue seems to be the logical conclusion of all of this, even i=
f Core ships LOT=3Dfalse at the outset.
> >
> > Where am I wrong here?
> >
> > Keagan
> >
> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
> >>
> >> Personally, I think with either plan the ultimate risk of forking is l=
ow given probability to activate before timeout, so we should just pick som=
ething and move on, accepting that we aren't setting a precedent by which a=
ll future forks should abide. Given my understanding of the tradeoffs, I be=
lieve that the safest choice is LOT=3Dtrue, but I wouldn't move to hold bac=
k a plan of LOT=3Dfalse (but would probably take mitigative steps on commun=
ity advocacy if it looks like there is non majority but non negligible LOT=
=3Dtrue 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=3Dtrue 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=3Dfalse"),
> 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