From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A175BC000A for ; 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 ; 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 ; 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 ; Tue, 2 Mar 2021 18:32:04 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id e9so2496459pjs.2 for ; 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: References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au> <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.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: From: Ariel Lorenzo-Luaces Date: Tue, 02 Mar 2021 10:32:00 -0800 To: Erik Aronesty Message-ID: X-Mailman-Approved-At: Tue, 02 Mar 2021 18:49:57 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > wrote: >> >> On Tue, Feb 23,= 2021 at 12:09 PM Keagan McClelland via bitcoin-dev >> 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 > 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
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 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

Cheers
Ariel Lorenzo-Luaces

On Ma= r 1, 2021, at 5:54 AM, Erik Aronesty <erik@q32=2Ecom> wrote:
 Today users should start cooperating again to c=
ontinue using the
 optimal strategy=2E

the "gradual"=
 method of reducing the % of 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-dev
<bitcoin-dev@lists=2Elinuxfoundati=
on=2Eorg> wrote:
 On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
 &l=
t;bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:

 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>
 Where am I wrong here?

 Keagan

 On Mon, Feb 22, 2021 =
at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=
=2Eorg> wrote:

 =
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

 Cheers,

 Jeremy



 bitcoin-d=
ev mailing list
 bitcoin-dev@lists=2Elinuxfoundation=2Eorg
 htt=
ps://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev


 bitcoin-dev mailing list
 bitcoin-dev@lists=2Elinu=
xfoundation=2Eorg
 https://lists=2Elinuxfoundation=2Eorg/mailman/lis=
tinfo/bitcoin-dev

 To favor LOT=3Dtrue because it s=
eems 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 t=
ime your counterparty cheats)=2E

 During segwit users started by coo=
perating (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
 rev=
erted to cooperating (MASF while intolerant miners forked off)=2E
 Today=
 users should start cooperating again to continue using the
 optimal str=
ategy=2E

 Cheers
 Ariel Lorenzo-Luaces

 bitcoin-dev ma=
iling list
 bitcoin-dev@lists=2Elinuxfoundation=2Eorg
 https://li=
sts=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
------Y6XLTSGI28MLT6RXCV5KCEFW1Z4UW2--