summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAriel Lorenzo-Luaces <arielluaces@gmail.com>2021-02-20 09:20:27 -0800
committerbitcoindev <bitcoindev@gnusha.org>2021-02-20 17:20:36 +0000
commit087cee19c84734f22e90d3b5071e82c4a48f1538 (patch)
tree2143752d56631a08b90ad7d106247457b3cb999c
parent93b956905b27d9e7fbf4fcee498aee2e4a019b65 (diff)
downloadpi-bitcoindev-087cee19c84734f22e90d3b5071e82c4a48f1538.tar.gz
pi-bitcoindev-087cee19c84734f22e90d3b5071e82c4a48f1538.zip
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
-rw-r--r--99/287ca98039979c2e2a7f70a68973f88bf5fcb7382
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 &lt;<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eo=
+rg" target=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>&gt; 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--
+
+