Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 246BBC013A for ; Fri, 5 Feb 2021 12:44:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 068D886A7A for ; Fri, 5 Feb 2021 12:44:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BdIMcCivTd5 for ; Fri, 5 Feb 2021 12:44:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by whitealder.osuosl.org (Postfix) with ESMTPS id 834BB871D0 for ; Fri, 5 Feb 2021 12:44:09 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id 100so48635otg.3 for ; Fri, 05 Feb 2021 04:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fsQ5kU3Z87wVztw2EZyIWLdgVWsR+Jwf9UALp3VeW4Y=; b=EGRBO7kuLD4En2O82yS3OE/K8qXASZOj98idUidIwjjwItEL94b5g4T2Tt5/TSakjh JqCThbfpvy1vV5IKJUyDpKR+Otly6F4yb4N1y0B4kvYR4mGThAIo8mAzExSXNj7EOYiq Oa1GH6/hxOPdf4SXJHAkzhp+vanW4dAPfw9H6ZFbaDlXcPCPSijSbsrlUlkChXYBL3WY 6HRQFK3FSRxSYk1DPgr4O77mSEnXVsqdtdkPOtK+F+rgcIF9exTjnjZjDAjkfzveunUs WhZdQeyx9XB/+/11WfZ2P6dg7YWsTZUC0fG62sh3l3t4fMNeeHq8Pjq+6jHZIM4kY8Q6 KniQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fsQ5kU3Z87wVztw2EZyIWLdgVWsR+Jwf9UALp3VeW4Y=; b=DsU+df/d5zhNDxhNeGZGHLd3SHlKoE8tEEMIo75mgCHW5R4smEjiI6pqo0BvxBPG1N 1Krx9syoV1Mkzc7mCiklN5f6h2WsfFU8eNY6x966JV0xO2jZJl4HN0sOsD/QR4iBJZWH kBI1I3poIpezm9KnMZGU3tKmnGoUIiMaNpWLvztrGwjmR4wxLn9J1jbcXfyVCR539v9E aynxmnbJruG65Uh4jvySNPL6o66rs2BxoEI2h3Nkpz5tG1MrA2KpHMbhY6n43i+0vpEG jE2ViGC92E4D9zhwpiA6ZNFPezoP9G8yW7suAEzKV4KTaq5cSwDovhP4oMNfkJcKWUv/ FS6w== X-Gm-Message-State: AOAM532yDpK1fkroeCliG21UoaHw/cuql231J6TrXg5Ya55UQXK1Ycp4 PJpxErFAOSk1okcecsKwL+HLOgbqy2614EIMK6sE6uIkVvc= X-Google-Smtp-Source: ABdhPJzqdBZf04p1+hdRP84Dn6hO7lXCt0EgToT+064cuVrxkMiG4g3daEeroz+KJ04Pz4gMfx9OUCj3t21oacthS7A= X-Received: by 2002:a9d:1d64:: with SMTP id m91mr3201275otm.290.1612529048444; Fri, 05 Feb 2021 04:44:08 -0800 (PST) MIME-Version: 1.0 From: Michael Folkson Date: Fri, 5 Feb 2021 12:43:57 +0000 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000001f633105ba962d1f" X-Mailman-Approved-At: Fri, 05 Feb 2021 13:40:43 +0000 Subject: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC 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: Fri, 05 Feb 2021 12:44:11 -0000 --0000000000001f633105ba962d1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A summary of the first Taproot activation meeting (February 3rd) is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01837= 9.html It appears there is one (hopefully) last stumbling block before we are ready to propose Taproot activation parameters to the mailing list. Hence we are organizing a follow up meeting on IRC on the ##taproot-activation channel on Tuesday 16th February at 19:00 UTC. As I said in the summary of the first Taproot activation meeting whether lockinontimeout (LOT) is set to true or false in a Bitcoin Core release attracted discussion during the meeting and has continued to attract discussion afterwards. I will weigh up the arguments I have seen for both true and false here. I won=E2=80=99t comment on the strength of the arguments, merely attempt to s= ummarize them. Any errors are my own. Arguments for setting lockinontimeout (LOT) to true in a Core release T1) This entirely eradicates the possibility (however unlikely) that Taproot fails to activate within a year. Although approximately 90 percent of mining pools have already pledged to activate Taproot there is no reason to open the door to possible delays and political shenanigans for no reason, however unlikely. T2) Given users can change LOT=3Dtrue at any point (and some have declared they will be setting LOT=3Dtrue regardless), setting LOT=3Dfalse in Core op= ens up edge case scenarios where different proportions of users on the network change to LOT=3Dtrue at different points in time in an uncoordinated fashio= n. Given the end state we all want is Taproot activated it doesn=E2=80=99t mak= e sense to open the door to these edge cases. Setting LOT=3Dtrue in Core would mean there is no motivation for users to change LOT in the software they are running. T3) We should not be putting users in a place where they feel they need to change LOT. The urge to change LOT will be strong if miners delay for an unreasonable period. We are then in a situation where a decision has to be made on whether Core releases a new version with LOT=3Dtrue and this whole discussion kicks off again. We should definitely seek to avoid the need to rehash this discussion later in the year. T4) LOT is only relevant if miners fail to activate. It doesn=E2=80=99t mak= e sense to set it to false as that is essentially saying if miners fail to activate early, LOT should also let them not activate. T5) Activation should only be attempted once community consensus for the soft fork has been reached. Miner signaling is not voting for the changes, it is signaling readiness. There is no reasonable rationale for not being ready within a year. T6) An argument belcher outlined on IRC. If LOT was set to true and a chain split happened then the Taproot chain doesn=E2=80=99t have wipeout risk so = there=E2=80=99s a really strong incentive to be on the Taproot activating LOT=3Dtrue chain and therefore using LOT=3Dtrue means the risk of a chain split is actually lower. Arguments for setting lockinontimeout (LOT) to false in a Core release F1) The probability of Taproot not being activated by miners is small. This is not 2017, this is not SegWit, there is no need to worry. F2) The worst case scenario is we have to wait over a year for Taproot to be activated. Even the worst case scenario is not a disaster. F3) If in the unlikely scenario miners did not activate Taproot for a year for no apparent reason we would never set LOT to false again for any potential future soft fork. If miners fail to activate Taproot despite pledging support and there being overwhelming community consensus for it, it would set a precedent that miners cannot be relied upon *at all* to activate soft forks. F4) If in the highly unlikely scenario that a bug or some problem with the Taproot implementation was found during the signaling period miners could choose not to activate it which is cleaner than needing an emergency Core release. Then some additional arguments nullc posted on Reddit https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_w= ill_be_able_to_veto/gm2l02w/ F5) LOT =3D false is more similar to what was done previously (unless you g= o way back to the earliest soft forks which were more similar to LOT =3D true= ) F6) It is more important that no rules that harm users are deployed than it is that new useful rules are deployed quickly. If there is a choice between =E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore clear that this isn=E2=80=99t a = mechanism to force bad things on users=E2=80=9D we should prefer the latter. Plenty of people just don=E2=80= =99t like LOT=3Dtrue very much absent evidence that miners are blocking deployment. T= o some it just feels needlessly antagonistic and distrusting towards part of our community. There are some additional parameters other than LOT we will discuss in this meeting such as activation threshold, start time etc but personally I don= =E2=80=99t think they will attract the same discussion as LOT. As I=E2=80=99ve stated before please continue to engage productively and in= good faith. I can see arguments with merit on both sides of the LOT discussion but there appears to be overwhelming consensus that Taproot is activated this year and there appears to be no reason it shouldn=E2=80=99t be. This discussion on LOT really should not derail that. --=20 Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --0000000000001f633105ba962d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A summary of the first Taproot activation meeti= ng (February 3rd) is here: https://lists.linuxfoundation= .org/pipermail/bitcoin-dev/2021-February/018379.html


It appears there is one (hopefully) last stumbl= ing block before we are ready to propose Taproot activation parameters to t= he mailing list.


Hence we are organizing a follow up meeting on = IRC on the ##taproot-activation channel on Tuesday 16th February at 19:00 U= TC.


As I said in the summary of the first Taproot a= ctivation meeting whether lockinontimeout (LOT) is set to true or false in = a Bitcoin Core release attracted discussion during the meeting and has cont= inued to attract discussion afterwards.


I will weigh up the arguments I have seen for b= oth true and false here. I won=E2=80=99t comment on the strength of the arg= uments, merely attempt to summarize them. Any errors are my own.


Arguments for setting lockinontimeout (LOT) to = true in a Core release

T1) This entirely eradicates the possibility (h= owever unlikely) that Taproot fails to activate within a year. Although app= roximately 90 percent of mining pools have already pledged to activate Tapr= oot there is no reason to open the door to possible delays and political sh= enanigans for no reason, however unlikely.

T2) Given users can change LOT=3Dtrue at any po= int (and some have declared they will be setting LOT=3Dtrue regardless), se= tting LOT=3Dfalse in Core opens up edge case scenarios where different prop= ortions of users on the network change to LOT=3Dtrue at different points in= time in an uncoordinated fashion. Given the end state we all want is Tapro= ot activated it doesn=E2=80=99t make sense to open the door to these edge c= ases. Setting LOT=3Dtrue in Core would mean there is no motivation for user= s to change LOT in the software they are running.

T3) We should not be putting users in a place w= here they feel they need to change LOT. The urge to change LOT will be stro= ng if miners delay for an unreasonable period. We are then in a situation w= here a decision has to be made on whether Core releases a new version with = LOT=3Dtrue and this whole discussion kicks off again. We should definitely = seek to avoid the need to rehash this discussion later=C2=A0in=C2=A0the yea= r.

T4) LOT is only relevant if miners fail to acti= vate. It doesn=E2=80=99t make sense to set it to false as that is essential= ly saying if miners fail to activate early, LOT should also let them not ac= tivate.

T5) Activation should only be attempted once co= mmunity consensus for the soft fork has been reached. Miner signaling is no= t voting for the changes, it is signaling readiness. There is no reasonable= rationale for not being ready within a year.

T6) An argument belcher outlined on IRC. If LOT= was set to true and a chain split happened then the Taproot chain doesn=E2= =80=99t have wipeout risk so there=E2=80=99s a really strong incentive to b= e on the Taproot activating LOT=3Dtrue chain and therefore using LOT=3Dtrue= means the risk of a chain split is actually lower.



Arguments for setting lockinontimeout (LOT) to = false in a Core release

F1) The probability of Taproot not being activa= ted by miners is small. This is not 2017, this is not SegWit, there is no n= eed to worry.=C2=A0

F2) The worst case scenario is we have to wait = over a year for Taproot to be activated. Even the worst case scenario is no= t a disaster.

F3) If in the unlikely scenario miners did not = activate Taproot for a year for no apparent reason we would never set LOT t= o false again for any potential future soft fork. If miners fail to activat= e Taproot despite pledging support and there being overwhelming community c= onsensus for it, it would set a precedent that miners cannot be relied upon= *at all* to activate soft forks.

F4) If in the highly unlikely scenario that a b= ug or some problem with the Taproot implementation was found during the sig= naling period miners could choose not to activate it which is cleaner than = needing an emergency Core release.


Then some additional arguments nullc posted on = Reddit

https:= //old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be= _able_to_veto/gm2l02w/

F5) LOT =3D false is more similar to what was d= one previously (unless you go way back to the earliest soft forks which wer= e more similar to LOT =3D true)

F6) It is more important that no rules that har= m users are deployed than it is that new useful rules are deployed quickly.= If there is a choice between =E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore cl= ear that this isn=E2=80=99t a mechanism to force bad things on users=E2=80= =9D we should prefer the latter. Plenty of people just don=E2=80=99t like L= OT=3Dtrue very much absent evidence that miners are blocking deployment. To= some it just feels needlessly antagonistic and distrusting towards part of= our community.


There are some additional parameters other than= LOT we will discuss in this meeting such as activation threshold, start ti= me etc but personally I don=E2=80=99t think they will attract the same disc= ussion as LOT.


As I=E2=80=99ve stated before please continue t= o engage productively and in good faith. I can see arguments with merit on = both sides of the LOT discussion but there appears to be overwhelming conse= nsus that Taproot is activated this year and there appears to be no reason = it shouldn=E2=80=99t be. This discussion on LOT really should not derail th= at.


--
Mi= chael Folkson
Keybase: michaelfolkson=
PG= P: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--0000000000001f633105ba962d1f--