In-Reply-To: <CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com>
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>
 <CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com>
Thread-Topic: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
User-Agent: Android
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----Y6XLTSGI28MLT6RXCV5KCEFW1Z4UW2"
Content-Transfer-Encoding: 7bit
From: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Date: Tue, 02 Mar 2021 10:32:00 -0800
To: Erik Aronesty <erik@q32.com>
Message-ID: <f2f36ee6-e08e-4e1a-bb07-00884dc29174@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
Precedence: list

------Y6XLTSGI28MLT6RXCV5KCEFW1Z4UW2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=UTF-8

I agree=2E

Thank you Erik for proposing it=2E It's a pretty good idea=2E

=
P=2ES=2E I wouldn't want a chain split of a low percentage of users though=
=2E The minority will be at the mercy of massive PoW swings and the chain w=
ill lose friends so it's not good for anyone=2E I recommend changing the fi=
nal percentage to %50 because that's the hurdle where non-upgraded users *m=
ust* activate to avoid the risk of being reorged=2E The number of running u=
sers will quickly jump to 90%+ if it ever gets near 50%=2E

Cheers
Ariel Lo=
renzo-Luaces



On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty <erik@q3=
2=2Ecom> wrote:
>> Today users should start cooperating again to continue u=
sing the
>> optimal strategy=2E
>
>the "gradual" method of reducing the % o=
f miners required for lock-in
>as time goes on seems to encode this optimal=
 strategy=2E
>
>On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-de=
v
><bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>>
>> On Tue, Feb 23,=
 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>> <bitcoin-dev@lists=
=2Elinuxfoundation=2Eorg> wrote:
>> >
>> > If social consensus is what driv=
es technical consensus and not the
>other way around it seems as if there c=
annot exist a valid (rational?)
>reason to 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 if Core ships LOT=3Dfalse at the =
outset=2E
>> >
>> > Where am I wrong here?
>> >
>> > Keagan
>> >
>> > On Mo=
n, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev
><bitcoin-dev@lists=2Elin=
uxfoundation=2Eorg> 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 a=
ren't setting a
>precedent by which all future forks should abide=2E Given =
my
>understanding of the tradeoffs, I believe that the safest choice is
>LO=
T=3Dtrue, but I wouldn't move to hold back a plan of LOT=3Dfalse (but
>woul=
d probably take mitigative steps on community advocacy if it looks
>like th=
ere is non majority but non negligible LOT=3Dtrue uptake)=2E
>> >>
>> >> Ch=
eers,
>> >>
>> >> Jeremy
>> >>
>> >>
>> >> ________________________________=
_______________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists=2Eli=
nuxfoundation=2Eorg
>> >> https://lists=2Elinuxfoundation=2Eorg/mailman/lis=
tinfo/bitcoin-dev
>> >
>> > _______________________________________________=

>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists=2Elinuxfoundation=2Eo=
rg
>> > https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
=
>>
>> To favor LOT=3Dtrue because it seems like the inevitable result is li=
ke
>> 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)=2E
>>
>> D=
uring segwit users started by cooperating (BIP9, or "LOT=3Dfalse"),
>> then=
 a minority of
>> miners didn't cooperate (small veto but remember the majo=
rity of
>> miners cooperated), then users stopped cooperating in response
>=
(UASF),
>> then miners
>> reverted to cooperating (MASF while intolerant mi=
ners forked off)=2E
>> Today users should start cooperating again to contin=
ue using the
>> optimal strategy=2E
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>>=
 _______________________________________________
>> bitcoin-dev mailing lis=
t
>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>> https://lists=2Elinuxfoun=
dation=2Eorg/mailman/listinfo/bitcoin-dev

------Y6XLTSGI28MLT6RXCV5KCEFW1Z4UW2
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir=3D"auto">I agree=2E<br><br></div>
<div di=
r=3D"auto">Thank you Erik for proposing it=2E It's a pretty good idea=2E<br=
><br></div>
<div dir=3D"auto">P=2ES=2E I wouldn't want a chain split of a l=
ow percentage of users though=2E The minority will be at the mercy of massi=
ve PoW swings and the chain will lose friends so it's not good for anyone=
=2E I recommend changing the final percentage to %50 because that's the hur=
dle where non-upgraded users *must* activate to avoid the risk of being reo=
rged=2E The number of running users will quickly jump to 90%+ if it ever ge=
ts near 50%=2E<br><br></div>
<div dir=3D"auto">Cheers<br></div>
<div dir=3D=
"auto">Ariel Lorenzo-Luaces<br><br></div>
<div class=3D"gmail_quote" >On Ma=
r 1, 2021, at 5:54 AM, Erik Aronesty &lt;<a href=3D"mailto:erik@q32=2Ecom" =
target=3D"_blank">erik@q32=2Ecom</a>&gt; wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">
<pre class=3D"blue"><blockquote class=3D"g=
mail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #7=
29fcf; padding-left: 1ex;"> Today users should start cooperating again to c=
ontinue using the<br> optimal strategy=2E<br></blockquote><br>the "gradual"=
 method of reducing the % of miners required for lock-in<br>as time goes on=
 seems to encode this optimal strategy=2E<br><br>On Thu, Feb 25, 2021 at 6:=
43 AM Ariel Luaces via bitcoin-dev<br>&lt;bitcoin-dev@lists=2Elinuxfoundati=
on=2Eorg&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0=
pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br=
> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev<br> &l=
t;bitcoin-dev@lists=2Elinuxfoundation=2Eorg&gt; wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px sol=
id #ad7fa8; padding-left: 1ex;"><br> If social consensus is what drives tec=
hnical consensus and not the other way around it seems as if there cannot e=
xist a valid (rational?) reason to oppose Taproot itself, and then by exten=
sion with the arguments laid out above, LOT=3Dtrue seems to be the logical =
conclusion of all of this, even if Core ships LOT=3Dfalse at the outset=2E<=
br><br> Where am I wrong here?<br><br> Keagan<br><br> On Mon, Feb 22, 2021 =
at 7:11 PM Jeremy via bitcoin-dev &lt;bitcoin-dev@lists=2Elinuxfoundation=
=2Eorg&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt=
 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br> =
Personally, I think with either plan the ultimate risk of forking is low gi=
ven probability to activate before timeout, so we should just pick somethin=
g and move on, accepting that we aren't setting a precedent by which all fu=
ture forks should abide=2E Given my understanding of the tradeoffs, I belie=
ve 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 community=
 advocacy if it looks like there is non majority but non negligible LOT=3Dt=
rue uptake)=2E<br><br> Cheers,<br><br> Jeremy<br><br><br><hr><br> bitcoin-d=
ev mailing list<br> bitcoin-dev@lists=2Elinuxfoundation=2Eorg<br> <a href=
=3D"https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev">htt=
ps://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev</a><br></bl=
ockquote><br><hr><br> bitcoin-dev mailing list<br> bitcoin-dev@lists=2Elinu=
xfoundation=2Eorg<br> <a href=3D"https://lists=2Elinuxfoundation=2Eorg/mail=
man/listinfo/bitcoin-dev">https://lists=2Elinuxfoundation=2Eorg/mailman/lis=
tinfo/bitcoin-dev</a><br></blockquote><br> To favor LOT=3Dtrue because it s=
eems like the inevitable result is like<br> playing the prisoner's dilemma =
and never cooperating instead of using<br> the most optimal strategy which =
is tit-for-tat (cooperating at first<br> and then cheating once for every t=
ime your counterparty cheats)=2E<br><br> During segwit users started by coo=
perating (BIP9, or "LOT=3Dfalse"),<br> then a minority of<br> miners didn't=
 cooperate (small veto but remember the majority of<br> miners cooperated),=
 then users stopped cooperating in response (UASF),<br> then miners<br> rev=
erted to cooperating (MASF while intolerant miners forked off)=2E<br> Today=
 users should start cooperating again to continue using the<br> optimal str=
ategy=2E<br><br> Cheers<br> Ariel Lorenzo-Luaces<br><hr><br> bitcoin-dev ma=
iling list<br> bitcoin-dev@lists=2Elinuxfoundation=2Eorg<br> <a href=3D"htt=
ps://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev">https://li=
sts=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev</a><br></blockquot=
e></pre></blockquote></div></body></html>
------Y6XLTSGI28MLT6RXCV5KCEFW1Z4UW2--