path: root/e5/b3bd1187592de8e83e05f328ff30686762d708

Return-Path: <arielluaces@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A175BC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 18:32:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 83A72606BD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 18:32:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.604
X-Spam-Level: 
X-Spam-Status: No, score=0.604 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id YXagztfCbakc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 18:32:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com
 [209.85.216.51])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 72CB6606B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 18:32:04 +0000 (UTC)
Received: by mail-pj1-f51.google.com with SMTP id e9so2496459pjs.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 02 Mar 2021 10:32:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=in-reply-to:references:thread-topic:user-agent:mime-version
 :content-transfer-encoding:subject:from:date:to:cc:message-id;
 bh=VkHyoxPmCixX2X5ZbuFjWaEg+sOOdVn2fAgkP7LY8gk=;
 b=acQddDqhKJNoaRv8fq/89HVBC2nZ/PGMb1bCxDxpdv7kqelohl92JShhs4O4l8QAYV
 IqB70ftcrwLytSZ93JD67QwtFWZc8K6pMCrDxm2vyhq7mcGgCgKxEhVZRDTHx+H1yaFh
 P4jhZdKKXETKt5x+0P1OnL8CVpli9TLqMIHpbNYQk8HjVrlUjYQzHXrdcAJBbSC6ZMEJ
 CcHeO/nskzS4tms61dlRMgZLN3/1OV+7194A1uHBzROZ/usvH4XK8CDhRZTi6LQizLj4
 F4r3f3GP6vlhSy+2Ns9C6oaOlCUb8XXwwsPEI4jQ3dOnZrQfOjEGIocjjQiE5c+XHLqV
 b5jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent
 :mime-version:content-transfer-encoding:subject:from:date:to:cc
 :message-id;
 bh=VkHyoxPmCixX2X5ZbuFjWaEg+sOOdVn2fAgkP7LY8gk=;
 b=ClwwesHGO9dbZHtIxmj9+W/Dbo4MIAfwSqlIsT6Ol0fc1zybZKLb1hWxBfSjtLjBLe
 7282i15tv/VaTUNXzgq2WrwsDkdA5hYONd54oDVJlV8tFRS9IsIm5qrlAbzImjOGTdNf
 azsSfT9ZAC/MIdwwhFivIFQblw8gjVyMfh2I1wSYb328m6/UFgqRBP5xvWTOegLUGPVv
 wBFZHVqRWUmH2VkHSupfCA5gvF2g0VCfztlZ/COqgFbCcL+P75ShiLuqvoPpeB9ixA69
 rj8o6YojjINZQwFTSehm29cBtpXm+6WS7+/x8zrcJj2lZ8HVRlDCZF4o5OGu/+SXyRde
 ZaVQ==
X-Gm-Message-State: AOAM530hPvLItR5nWLTMCFyh64vLp90V/7bs9C5/UD8G1DbybyKENwUi
 6xLlVtFsGSWHE1pQx/gmVN4=
X-Google-Smtp-Source: ABdhPJwM6L9dV+zUMDSTlBaxeLLy0WTAB3OhXITYCwNO2skT/3TaAeGg7MSv9/wOm0jDwdIMKsGGSw==
X-Received: by 2002:a17:902:d504:b029:e3:21bf:36b2 with SMTP id
 b4-20020a170902d504b02900e321bf36b2mr21417509plg.37.1614709923913; 
 Tue, 02 Mar 2021 10:32:03 -0800 (PST)
Received: from [192.168.168.106] (d142-179-7-88.bchsia.telus.net.
 [142.179.7.88])
 by smtp.gmail.com with ESMTPSA id y4sm7663517pgq.32.2021.03.02.10.32.02
 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
 Tue, 02 Mar 2021 10:32:03 -0800 (PST)
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>
X-Referenced-Uid: 24149
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
X-Local-Message-Id: <f2f36ee6-e08e-4e1a-bb07-00884dc29174@gmail.com>
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>
X-Mailman-Approved-At: Tue, 02 Mar 2021 18:49:57 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 18:32:05 -0000

------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--