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>
In-Reply-To: <CALeFGL1UbXx14aX7RK7nh7b4jwvmfF6AXrvqPJpriSB4ZvYT2A@mail.gmail.com>
From: Ariel Luaces <arielluaces@gmail.com>
Date: Wed, 24 Feb 2021 14:37:09 -0800
Message-ID: <CAOv1TnhQcYrc5q6GTUTuQMEi9RAV4dy5mmyNp--HuYTPzEUfJQ@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@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

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 ab=
ove, LOT=3Dtrue seems to be the logical conclusion of all of this, even if =
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@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 somet=
hing 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 beli=
eve that the safest choice is LOT=3Dtrue, but I wouldn't move to hold back =
a plan of LOT=3Dfalse (but would probably take mitigative steps on communit=
y advocacy if it looks like there is non majority but non negligible LOT=3D=
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=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