Content-Type: multipart/alternative;
 boundary=Apple-Mail-E59C1076-84B3-4ECF-9014-B0894FB20E14
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 21 Feb 2021 09:30:45 -0500
Message-Id: <4A6F5D19-DF75-4C83-A435-53B6EAABD85F@mattcorallo.com>
References: <b5d23fb8-06a8-4dda-bdbb-2247a82fa1a0@gmail.com>
In-Reply-To: <b5d23fb8-06a8-4dda-bdbb-2247a82fa1a0@gmail.com>
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
Precedence: list


--Apple-Mail-E59C1076-84B3-4ECF-9014-B0894FB20E14
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t think =E2=80=9Csome vocal users are going to threaten to for=
k themselves off=E2=80=9D is good justification for technical decisions. It=E2=
=80=99s important to communicate and for everyone to agree/understand that a=
 failed BIP 8/9 activation, in the scenario people are worried about, is not=
 the end of the story for Taproot activation. If it is clear that Taproot ha=
s broad consensus but some miners failed to upgrade in time (as it presumabl=
y would be), a flag day activation seems merited and I=E2=80=99m not sure an=
yone has argued against this. That said, forced-signaling via a UASF/BIP8(tr=
ue)-style fork carries material additional risk that a classic flag-day acti=
vation does not, so let=E2=80=99s not optimize for something like that.

Matt

> On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
> 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.
>=20
> Cheers
> Ariel Lorenzo-Luaces
>> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>> Good morning list,
>>=20
>>>  It was pointed out to me that this discussion is largely moot as the so=
ftware complexity for Bitcoin Core to ship an
>>>  option like this is likely not practical/what people would wish to see.=

>>>=20
>>>  Bitcoin Core does not have infrastructure to handle switching consensus=
 rules with the same datadir - after running with
>>>  uasf=3Dtrue for some time, valid blocks will be marked as invalid, and a=
dditional development would need to occur to
>>>  enable switching back to uasf=3Dfalse. This is complex, critical code t=
o get right, and the review and testing cycles
>>>  needed seem to be not worth it.
>>=20
>> Without implying anything else, this can be worked around by a user maint=
aining two `datadir`s and running two clients.
>> This would have an "external" client running an LOT=3DX (where X is whate=
ver the user prefers) and an "internal" client that is at most 0.21.0, which=
 will not impose any LOT rules.
>> The internal client then uses `connect=3D` directive to connect locally t=
o the external client and connects only to that client, using it as a firewa=
ll.
>> The external client can be run pruned in order to reduce diskspace resour=
ce usage (the internal client can remain unpruned if that is needed by the u=
ser, e.g. for LN implementation sthat need to look up arbitrary short-channe=
l-ids).
>> Bandwidth usage should be same since the internal client only connects to=
 the external client and the OS should optimize that case.
>> CPU usage is doubled, though.
>>=20
>> (the general idea came from gmax, just to be clear, though the below use i=
s from me)
>>=20
>> Then the user can select LOT=3DC or LOT=3D!C (where C is whatever Bitcoin=
 Core ultimately ships with) on the external client based on the user prefer=
ences.
>>=20
>> 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 destroy t=
he external node and connect the internal node directly to the network (opti=
onally upgrading the internal node to LOT=3D!U) as a way to "change their mi=
nd in view of the economy".
>> The internal node will then follow the dominant chain.
>>=20
>>=20
>> Regards,
>> ZmnSCPxj
>>=20
>>>=20
>>>  Instead, the only practical way to ship such an option would be to trea=
t it as a separate chain (the same way regtest,
>>>  testnet, and signet are treated), including its own separate datadir an=
d the like.
>>>=20
>>>  Matt
>>>=20
>>>>  On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>>>>=20
>>>>  (Also in response to ZMN...)
>>>>  Bitcoin Core has a long-standing policy of not shipping options which s=
hoot yourself in the foot. I=E2=80=99d be very disappointed if that changed n=
ow. People are of course more than welcome to run such software themselves, b=
ut I anticipate the loud minority on Twitter and here aren=E2=80=99t process=
ing enough transactions or throwing enough financial weight behind their dec=
ision for them to do anything but just switch back if they find themselves o=
n a chain with no blocks.
>>>>  There=E2=80=99s nothing we can (or should) do to prevent people from t=
hreatening to (and possibly) forking themselves off of bitcoin, but that doe=
sn=E2=80=99t mean we should encourage it either. The work Bitcoin Core maint=
ainers and developers do is to recommend courses of action which they believ=
e have reasonable levels of consensus and are technically sound. Luckily, th=
ere=E2=80=99s strong historical precedent for people deciding to run other s=
oftware around forks, so misinterpretation is not very common (just like the=
re=E2=80=99s strong historical precedent for miners not unilaterally decidin=
g forks in the case of Segwit).
>>>>  Matt
>>>>=20
>>>>>>  On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace.org wrote:
>>>>>>=20
>>>>>>  would dev consensus around releasing LOT=3Dfalse be considered as "d=
evelopers forcing their views on users"?
>>>>>=20
>>>>>  given there are clearly people of both views, or for now don't care
>>>>>  but might later, it would minimally be friendly and useful if
>>>>>  bitcoin-core has a LOT=3Dtrue option - and that IMO goes some way to
>>>>>  avoid the assumptive control via defaults.
>>>>=20
>>>>>  Otherwise it could be read as saying "developers on average
>>>>>  disapprove, but if you, the market disagree, go figure it out for
>>>>>  yourself" which is not a good message for being defensive and avoidin=
g
>>>>>  mis-interpretation of code repositories or shipped defaults as
>>>>>  "control".
>>>>=20
>>>>  bitcoin-dev mailing list
>>>>  bitcoin-dev@lists.linuxfoundation.org
>>>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>>=20
>>=20
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-E59C1076-84B3-4ECF-9014-B0894FB20E14
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">I don=E2=80=99t think =E2=80=
=9Csome vocal users are going to threaten to fork themselves off=E2=80=9D is=
 good justification for technical decisions. It=E2=80=99s important to commu=
nicate and for everyone to agree/understand that a failed BIP 8/9 activation=
, in the scenario people are worried about, is not the end of the story for T=
aproot activation. If it is clear that Taproot has broad consensus but some m=
iners failed to upgrade in time (as it presumably would be), a flag day acti=
vation seems merited and I=E2=80=99m not sure anyone has argued against this=
. That said, forced-signaling via a UASF/BIP8(true)-style fork carries mater=
ial additional risk that a classic flag-day activation does not, so let=E2=80=
=99s not optimize for something like that.</div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">Matt</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On =
Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev &lt;bitcoin-dev=
@lists.linuxfoundation.org&gt; wrote:<br><br></blockquote></div><blockquote t=
ype=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">What would be the t=
radeoffs of a BIP8(false, =E2=88=9E) option? That would remove some of the c=
oncerns of having to coordinate a UASF with an approaching deadline.<br><br>=
</div>
<div 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 via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"blue">Good morning list,<br><br><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padd=
ing-left: 1ex;"> It was pointed out to me that this discussion is largely mo=
ot as the software complexity for Bitcoin Core to ship an<br> option like th=
is is likely not practical/what people would wish to see.<br><br> Bitcoin Co=
re does not have infrastructure to handle switching consensus rules with the=
 same datadir - after running with<br> uasf=3Dtrue for some time, valid bloc=
ks will be marked as invalid, and additional development would need to occur=
 to<br> enable switching back to uasf=3Dfalse. This is complex, critical cod=
e to get right, and the review and testing cycles<br> needed seem to be not w=
orth it.<br></blockquote><br>Without implying anything else, this can be wor=
ked around by a user maintaining two `datadir`s and running two clients.<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.21.0, which wi=
ll not impose any LOT rules.<br>The internal client then uses `connect=3D` d=
irective to connect locally to the external client and connects only to that=
 client, using it as a firewall.<br>The external client can be run pruned in=
 order to reduce diskspace resource usage (the internal client can remain un=
pruned if that is needed by the user, e.g. for LN implementation sthat need t=
o look up arbitrary short-channel-ids).<br>Bandwidth usage should be same si=
nce the internal client only connects to the external client and the OS shou=
ld optimize that case.<br>CPU usage is doubled, though.<br><br>(the general i=
dea came from gmax, just to be clear, though the below use is from me)<br><b=
r>Then the user can select LOT=3DC or LOT=3D!C (where C is whatever Bitcoin C=
ore ultimately ships with) on the external client based on the user preferen=
ces.<br><br>If Taproot is not MASF-activated and LOT=3D!U is what dominates l=
ater (where U is whatever the user decided on), the user can decide to just d=
estroy the external node and connect the internal node directly to the netwo=
rk (optionally upgrading the internal node to LOT=3D!U) as a way to "change t=
heir mind in view of the economy".<br>The internal node will then follow the=
 dominant chain.<br><br><br>Regards,<br>ZmnSCPxj<br><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #72=
9fcf; padding-left: 1ex;"><br> Instead, the only practical way to ship such a=
n option would be to treat it as a separate chain (the same way regtest,<br>=
 testnet, and signet are treated), including its own separate datadir and th=
e like.<br><br> Matt<br><br> On 2/19/21 09:13, Matt Corallo via bitcoin-dev w=
rote:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=
.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> (Also in response=
 to ZMN...)<br> Bitcoin Core has a long-standing policy of not shipping opti=
ons which shoot yourself in the foot. I=E2=80=99d be very disappointed if th=
at changed now. 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 behi=
nd their decision for them to do anything but just switch back if they find t=
hemselves on a chain with no blocks.<br> There=E2=80=99s nothing we can (or s=
hould) do to prevent people from threatening to (and possibly) forking thems=
elves off of bitcoin, but that doesn=E2=80=99t mean we should encourage it e=
ither. The work Bitcoin Core maintainers and developers do is to recommend c=
ourses of action which they believe have reasonable levels of consensus and a=
re technically sound. Luckily, there=E2=80=99s strong historical precedent f=
or people deciding to run other software around forks, so misinterpretation i=
s not very common (just like there=E2=80=99s strong historical precedent for=
 miners not unilaterally deciding forks in the case of Segwit).<br> Matt<br>=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; bo=
rder-left: 1px solid #8ae234; padding-left: 1ex;"> On Feb 19, 2021, at 07:08=
, Adam Back adam@cypherspace.org wrote:<br><br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; pad=
ding-left: 1ex;"> would dev consensus around releasing LOT=3Dfalse be consid=
ered as "developers forcing their views on users"?<br></blockquote><br> give=
n there are clearly people of both views, or for now don't care<br> but migh=
t later, it would minimally be friendly and useful if<br> bitcoin-core has a=
 LOT=3Dtrue option - and that IMO goes some way to<br> avoid the assumptive c=
ontrol via defaults.<br></blockquote><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-l=
eft: 1ex;"> Otherwise it could be read as saying "developers on average<br> d=
isapprove, but if you, the market disagree, go figure it out for<br> yoursel=
f" which is not a good message for being defensive and avoiding<br> mis-inte=
rpretation of code repositories or shipped defaults as<br> "control".<br></b=
lockquote><br> bitcoin-dev mailing list<br> bitcoin-dev@lists.linuxfoundatio=
n.org<br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><=
br></blockquote></blockquote><br><br><hr><br>bitcoin-dev mailing list<br>bit=
coin-dev@lists.linuxfoundation.org<br><a href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a><br></pre></blockquote></div><span>______________=
_________________________________</span><br><span>bitcoin-dev mailing list</=
span><br><span>bitcoin-dev@lists.linuxfoundation.org</span><br><span>https:/=
/lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</span><br></div></bl=
ockquote></body></html>=

--Apple-Mail-E59C1076-84B3-4ECF-9014-B0894FB20E14--