path: root/99/287ca98039979c2e2a7f70a68973f88bf5fcb7

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