diff options
author | Ariel Lorenzo-Luaces <arielluaces@gmail.com> | 2021-02-20 09:20:27 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-20 17:20:36 +0000 |
commit | 087cee19c84734f22e90d3b5071e82c4a48f1538 (patch) | |
tree | 2143752d56631a08b90ad7d106247457b3cb999c | |
parent | 93b956905b27d9e7fbf4fcee498aee2e4a019b65 (diff) | |
download | pi-bitcoindev-087cee19c84734f22e90d3b5071e82c4a48f1538.tar.gz pi-bitcoindev-087cee19c84734f22e90d3b5071e82c4a48f1538.zip |
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
-rw-r--r-- | 99/287ca98039979c2e2a7f70a68973f88bf5fcb7 | 382 |
1 files changed, 382 insertions, 0 deletions
diff --git a/99/287ca98039979c2e2a7f70a68973f88bf5fcb7 b/99/287ca98039979c2e2a7f70a68973f88bf5fcb7 new file mode 100644 index 000000000..b2455a3eb --- /dev/null +++ b/99/287ca98039979c2e2a7f70a68973f88bf5fcb7 @@ -0,0 +1,382 @@ +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 8D017C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 20 Feb 2021 17:20:36 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 7B074605F3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 20 Feb 2021 17:20:36 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +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 C42gn_VbC1Ts + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 20 Feb 2021 17:20:34 +0000 (UTC) +Received: by smtp3.osuosl.org (Postfix, from userid 1001) + id D6C5360672; Sat, 20 Feb 2021 17:20:34 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com + [209.85.216.47]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 9B9E7605F3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 20 Feb 2021 17:20:32 +0000 (UTC) +Received: by mail-pj1-f47.google.com with SMTP id b15so1042857pjb.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 20 Feb 2021 09:20:32 -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:message-id; + bh=9IkThfegNAVaNxbdiemNdoHlJqFvnwj+x88PHiy217I=; + b=aOy1RJWHRcdWm6rTLw8Tnsr/L69x7pihz4vKj7iokgxo0NMcS3GxhE5DEIwE9i5HP0 + e3FCeY/Mrdo8roxNLbE8k9PKxqEIShwNukpc7m2MOZwez52xiODeq0exU/QDJyAEqZPX + H4CWuVyim7Cs9BLXCflnuo6jUFsuiDW7H1t4FrNduBQFxut7GFRA1CkRfWsv3bRQQHqv + OdrGOsKI5ZmoaZaDhn1ARlroqsI1gbvhNwRAdSml18BjVfUDT1JyKIfzNGCf4kRDRkgK + 78OuUXSV2kutxz3miIW92XfxljA9ZGQU4Zavog518FEcgJ+evd/SxTClxXmp1TApsWI/ + MwEQ== +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 + :message-id; + bh=9IkThfegNAVaNxbdiemNdoHlJqFvnwj+x88PHiy217I=; + b=K+0gRHhfBQ+V7nfKx1Sd5gaLBoEwbEqs/VV39/237FhDOIt2RGmdt6dD7oViXEN5Xo + D/CElK0cjBDClk3MA5Rl5XrAlICQ+WZCs7B8BTMeQtlH1bGYaOorIFk5qqYVOuH7GINg + kxrRkfWvy0SsmxZHlT7V6NdzqBD+8ocIRlHOxY6sjvgq47kG/KHzZNEB4yPRX22iBSBU + x4d56aF07iYrzOMQBbZFwn40UOUx/uSbhXE6146r/bLOFeAcirLgTN/omndCsBSCDMxi + BGAeZFvFVvzKpg+FkG/+uDzO5BtWi7eyJWRCzD7NG9eZyPZq6cQ1TgQBGwl6NcwSMzhE + 6nnw== +X-Gm-Message-State: AOAM533uLF0sd5sHeA2UgIbB8jMGlS9H1YN4w9127J+WNiUIKtye0Qi/ + 0PD61p1WSGcaxmJnFdxKF2g= +X-Google-Smtp-Source: ABdhPJwF1eaKCkgZ7pp8yu5AGo6uZJRmzyPwigmYFJnFT3sJ4aPG0qaKabm97/Pjy8rsex45Ndg8eA== +X-Received: by 2002:a17:902:c702:b029:e3:cb6b:5e59 with SMTP id + p2-20020a170902c702b02900e3cb6b5e59mr6515179plp.71.1613841632076; + Sat, 20 Feb 2021 09:20:32 -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 ms24sm12314745pjb.18.2021.02.20.09.20.30 + (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); + Sat, 20 Feb 2021 09:20:31 -0800 (PST) +In-Reply-To: <GCV_t7q-LWZOSrp4_BzurAjmQTuAcyptvOLUsQEpGNhg_l_SPZ3q0PlBxtUKOLfLs4G73ecSdK4SapbbBnRUo2j3yJg2_OTXgcFRzZOau_Q=@protonmail.com> +References: <CALqxMTFKbjg3yDPnrmL8TgtypirB_fDMMJD=AJxjYav51hmEAw@mail.gmail.com> + <E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com> + <ce8925d5-d2f1-1adb-530d-36f89f5b6352@bluematt.me> + <GCV_t7q-LWZOSrp4_BzurAjmQTuAcyptvOLUsQEpGNhg_l_SPZ3q0PlBxtUKOLfLs4G73ecSdK4SapbbBnRUo2j3yJg2_OTXgcFRzZOau_Q=@protonmail.com> +X-Referenced-Uid: 24075 +Thread-Topic: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on + lockinontimeout (LOT) +X-Blue-Identity: !l=123&o=96429&fo=102426&pl=56&po=0&qs=PREFIX&f=HTML&n=Ariel%20Lorenzo-Luaces&e=arielluaces%40gmail.com&m=!%3AZjEwN2MyYjMtOWE0OC00NzJhLWEzYTQtYjc3MTEzNTNhODJm%3ASU5CT1g%3D%3AMjQwNzU%3D%3AANSWERED&p=30&q=SHOW +User-Agent: Android +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----M3VKR8RC6SQIK94NGDLBZZCJT3IH3B" +Content-Transfer-Encoding: 7bit +X-Local-Message-Id: <b5d23fb8-06a8-4dda-bdbb-2247a82fa1a0@gmail.com> +From: Ariel Lorenzo-Luaces <arielluaces@gmail.com> +Date: Sat, 20 Feb 2021 09:20:27 -0800 +To: ZmnSCPxj <zmnscpxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + ZmnSCPxj <zmnscpxj@protonmail.com> +Message-ID: <b5d23fb8-06a8-4dda-bdbb-2247a82fa1a0@gmail.com> +X-Mailman-Approved-At: Sun, 21 Feb 2021 13:25:49 +0000 +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: Sat, 20 Feb 2021 17:20:36 -0000 + +------M3VKR8RC6SQIK94NGDLBZZCJT3IH3B +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=UTF-8 + +What would be the tradeoffs of a BIP8(false, =E2=88=9E) option? That would = +remove some of the concerns of having to coordinate a UASF with an approach= +ing deadline=2E + +Cheers +Ariel Lorenzo-Luaces +=E2=81=A3=E2=80=8B + +On Feb 19,= + 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists=2El= +inuxfoundation=2Eorg> wrote: +>Good morning list, +> +>> It was pointed out to= + me that this discussion is largely moot as the +>software complexity for Bi= +tcoin Core to ship an +>> option like this is likely not practical/what peop= +le would wish to +>see=2E +>> +>> Bitcoin Core does not have infrastructure to= + handle switching +>consensus rules with the same datadir - after running wi= +th +>> uasf=3Dtrue for some time, valid blocks will be marked as invalid, an= +d +>additional development would need to occur to +>> enable switching back t= +o uasf=3Dfalse=2E This is complex, critical code +>to get right, and the rev= +iew and testing cycles +>> needed seem to be not worth it=2E +> +>Without impl= +ying anything else, this can be worked around by a user +>maintaining two `d= +atadir`s and running two clients=2E +>This would have an "external" client r= +unning an LOT=3DX (where X is +>whatever the user prefers) and an "internal"= + client that is at most +>0=2E21=2E0, which will not impose any LOT rules=2E= + +>The internal client then uses `connect=3D` directive to connect locally +>= +to the external client and connects only to that client, using it as a +>fir= +ewall=2E +>The external client can be run pruned in order to reduce diskspac= +e +>resource usage (the internal client can remain unpruned if that is +>need= +ed by the user, e=2Eg=2E for LN implementation sthat need to look up +>arbit= +rary short-channel-ids)=2E +>Bandwidth usage should be same since the intern= +al client only connects +>to the external client and the OS should optimize = +that case=2E +>CPU usage is doubled, though=2E +> +>(the general idea came fro= +m gmax, just to be clear, though the below +>use is from me) +> +>Then the use= +r can select LOT=3DC or LOT=3D!C (where C is whatever Bitcoin +>Core ultimat= +ely ships with) on the external client based on the user +>preferences=2E +> += +>If Taproot is not MASF-activated and LOT=3D!U is what dominates later +>(wh= +ere U is whatever the user decided on), the user can decide to just +>destro= +y the external node and connect the internal node directly to the +>network = +(optionally upgrading the internal node to LOT=3D!U) as a way to +>"change t= +heir mind in view of the economy"=2E +>The internal node will then follow th= +e dominant chain=2E +> +> +>Regards, +>ZmnSCPxj +> +>> +>> Instead, the only pract= +ical way to ship such an option would be to +>treat it as a separate chain (= +the same way regtest, +>> testnet, and signet are treated), including its ow= +n separate datadir +>and the like=2E +>> +>> Matt +>> +>> On 2/19/21 09:13, Matt= + Corallo via bitcoin-dev wrote: +>> +>> > (Also in response to ZMN=2E=2E=2E) += +>> > Bitcoin Core has a long-standing policy of not shipping options +>which= + shoot yourself in the foot=2E I=E2=80=99d be very disappointed if that +>ch= +anged now=2E People are of course more than welcome to run such +>software t= +hemselves, but I anticipate the loud minority on Twitter and +>here aren=E2= +=80=99t processing enough transactions or throwing enough financial +>weight= + behind their decision for them to do anything but just switch +>back if the= +y find themselves on a chain with no blocks=2E +>> > There=E2=80=99s nothing= + we can (or should) do to prevent people from +>threatening to (and possibly= +) forking themselves off of bitcoin, but +>that doesn=E2=80=99t mean we shou= +ld encourage it either=2E The work Bitcoin Core +>maintainers and developers= + do is to recommend courses of action which +>they believe have reasonable l= +evels of consensus and are technically +>sound=2E Luckily, there=E2=80=99s s= +trong historical precedent for people deciding +>to run other software aroun= +d forks, so misinterpretation is not very +>common (just like there=E2=80=99= +s strong historical precedent for miners not +>unilaterally deciding forks i= +n the case of Segwit)=2E +>> > Matt +>> > +>> > > On Feb 19, 2021, at 07:08, A= +dam Back adam@cypherspace=2Eorg wrote: +>> > > +>> > > > would dev consensus = +around releasing LOT=3Dfalse be considered as +>"developers forcing their vi= +ews on users"? +>> > > +>> > > given there are clearly people of both views, = +or for now don't +>care +>> > > but might later, it would minimally be friend= +ly and useful if +>> > > bitcoin-core has a LOT=3Dtrue option - and that IMO= + goes some way +>to +>> > > avoid the assumptive control via defaults=2E +>> >= + +>> > > Otherwise it could be read as saying "developers on average +>> > > = +disapprove, but if you, the market disagree, go figure it out for +>> > > yo= +urself" which is not a good message for being defensive and +>avoiding +>> > = +> mis-interpretation of code repositories or shipped defaults as +>> > > "co= +ntrol"=2E +>> > +>> > bitcoin-dev mailing list +>> > bitcoin-dev@lists=2Elinux= +foundation=2Eorg +>> > https://lists=2Elinuxfoundation=2Eorg/mailman/listinf= +o/bitcoin-dev +> +> +>_______________________________________________ +>bitcoin= +-dev mailing list +>bitcoin-dev@lists=2Elinuxfoundation=2Eorg +>https://lists= +=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev + +------M3VKR8RC6SQIK94NGDLBZZCJT3IH3B +Content-Type: text/html; + charset=utf-8 +Content-Transfer-Encoding: quoted-printable + +<html><head></head><body><div dir=3D"auto">What would be the tradeoffs of a= + BIP8(false, =E2=88=9E) option? That would remove some of the concerns of h= +aving to coordinate a UASF with an approaching deadline=2E<br><br></div> +<d= +iv dir=3D"auto">Cheers<br></div> +<div dir=3D"auto">Ariel Lorenzo-Luaces<br>= +</div> +<div class=3D"gmail_quote" >On Feb 19, 2021, at 6:55 PM, ZmnSCPxj vi= +a bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eo= +rg" target=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>> wro= +te:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; = +border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<pre class= +=3D"blue">Good morning list,<br><br><blockquote class=3D"gmail_quote" style= +=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-le= +ft: 1ex;"> It was pointed out to me that this discussion is largely moot as= + the software complexity for Bitcoin Core to ship an<br> option like this i= +s likely not practical/what people would wish to see=2E<br><br> Bitcoin Cor= +e does not have infrastructure to handle switching consensus rules with the= + same datadir - after running with<br> uasf=3Dtrue for some time, valid blo= +cks will be marked as invalid, and additional development would need to occ= +ur to<br> enable switching back to uasf=3Dfalse=2E This is complex, critica= +l code to get right, and the review and testing cycles<br> needed seem to b= +e not worth it=2E<br></blockquote><br>Without implying anything else, this = +can be worked around by a user maintaining two `datadir`s and running two c= +lients=2E<br>This would have an "external" client running an LOT=3DX (where= + X is whatever the user prefers) and an "internal" client that is at most 0= +=2E21=2E0, which will not impose any LOT rules=2E<br>The internal client th= +en uses `connect=3D` directive to connect locally to the external client an= +d connects only to that client, using it as a firewall=2E<br>The external c= +lient can be run pruned in order to reduce diskspace resource usage (the in= +ternal client can remain unpruned if that is needed by the user, e=2Eg=2E f= +or LN implementation sthat need to look up arbitrary short-channel-ids)=2E<= +br>Bandwidth usage should be same since the internal client only connects t= +o the external client and the OS should optimize that case=2E<br>CPU usage = +is doubled, though=2E<br><br>(the general idea came from gmax, just to be c= +lear, though the below use is from me)<br><br>Then the user can select LOT= +=3DC or LOT=3D!C (where C is whatever Bitcoin Core ultimately ships with) o= +n the external client based on the user preferences=2E<br><br>If Taproot is= + not MASF-activated and LOT=3D!U is what dominates later (where U is whatev= +er the user decided on), the user can decide to just destroy the external n= +ode and connect the internal node directly to the network (optionally upgra= +ding the internal node to LOT=3D!U) as a way to "change their mind in view = +of the economy"=2E<br>The internal node will then follow the dominant chain= +=2E<br><br><br>Regards,<br>ZmnSCPxj<br><br><blockquote class=3D"gmail_quote= +" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; pad= +ding-left: 1ex;"><br> Instead, the only practical way to ship such an optio= +n would be to treat it as a separate chain (the same way regtest,<br> testn= +et, and signet are treated), including its own separate datadir and the lik= +e=2E<br><br> Matt<br><br> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wr= +ote:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex = +0=2E8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> (Also in resp= +onse to ZMN=2E=2E=2E)<br> Bitcoin Core has a long-standing policy of not sh= +ipping options which shoot yourself in the foot=2E I=E2=80=99d be very disa= +ppointed if that changed now=2E People are of course more than welcome to r= +un such software themselves, but I anticipate the loud minority on Twitter = +and here aren=E2=80=99t processing enough transactions or throwing enough f= +inancial weight behind their decision for them to do anything but just swit= +ch back if they find themselves on a chain with no blocks=2E<br> There=E2= +=80=99s nothing we can (or should) do to prevent people from threatening to= + (and possibly) forking themselves off of bitcoin, but that doesn=E2=80=99t= + mean we should encourage it either=2E The work Bitcoin Core maintainers an= +d developers do is to recommend courses of action which they believe have r= +easonable levels of consensus and are technically sound=2E Luckily, there= +=E2=80=99s strong historical precedent for people deciding to run other sof= +tware around forks, so misinterpretation is not very common (just like ther= +e=E2=80=99s strong historical precedent for miners not unilaterally decidin= +g forks in the case of Segwit)=2E<br> Matt<br><br><blockquote class=3D"gmai= +l_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae2= +34; padding-left: 1ex;"> On Feb 19, 2021, at 07:08, Adam Back adam@cyphersp= +ace=2Eorg wrote:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: = +0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> w= +ould dev consensus around releasing LOT=3Dfalse be considered as "developer= +s forcing their views on users"?<br></blockquote><br> given there are clear= +ly people of both views, or for now don't care<br> but might later, it woul= +d minimally be friendly and useful if<br> bitcoin-core has a LOT=3Dtrue opt= +ion - and that IMO goes some way to<br> avoid the assumptive control via de= +faults=2E<br></blockquote><br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1e= +x;"> Otherwise it could be read as saying "developers on average<br> disapp= +rove, but if you, the market disagree, go figure it out for<br> yourself" w= +hich is not a good message for being defensive and avoiding<br> mis-interpr= +etation of code repositories or shipped defaults as<br> "control"=2E<br></b= +lockquote><br> bitcoin-dev mailing list<br> bitcoin-dev@lists=2Elinuxfounda= +tion=2Eorg<br> <a href=3D"https://lists=2Elinuxfoundation=2Eorg/mailman/lis= +tinfo/bitcoin-dev">https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/b= +itcoin-dev</a><br></blockquote></blockquote><br><br><hr><br>bitcoin-dev mai= +ling list<br>bitcoin-dev@lists=2Elinuxfoundation=2Eorg<br><a href=3D"https:= +//lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev">https://lists= +=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev</a><br></pre></blockq= +uote></div></body></html> +------M3VKR8RC6SQIK94NGDLBZZCJT3IH3B-- + + |