From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BE5A0C0001 for ; Sun, 21 Feb 2021 14:30:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 951926E56C for ; Sun, 21 Feb 2021 14:30:53 +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 8NDkD-aL1UJo for ; Sun, 21 Feb 2021 14:30:51 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id DCF9F6E6E7; Sun, 21 Feb 2021 14:30:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 178BA6ED68 for ; Sun, 21 Feb 2021 14:30:48 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 79AEA4AC9AE; Sun, 21 Feb 2021 14:30:46 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1613916063; t=1613917846; bh=eGok0g4CMOMM0q95liFARxyOglb4EYeZ8eZJ6GOEEK8=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=2y79Ost7MYeIoBhfO2gi88yazj8gscfnZTdSzcClnZgEudVnyTzL8SK6h/zv71mlp SFYRzRr8IVDhuxfbk0W71hJZe+d9XoGmxhUiJ2i3kEq6hCxs1G1D87D7aSLOe89lP6 UWUUyjP3A6UIvh3ALI5hggDCD2Ss/jTAZpkokjd4XC2/wyKV8FosFGlIgxDx7vd+24 Pu26SB4WlWqpR6Sw/b7LjtS+LJItkKMgmX59G0Xo0xVM5asXhnUWnVd5JcDeGJQNWg i+bMxVYONKwobqWKu4lIU1hzLhLEGbG3R+TCMoKtCbscah2hk/WEZe8OoGUe7j+sMQ AG6iFUmXGRftg== Content-Type: multipart/alternative; boundary=Apple-Mail-E59C1076-84B3-4ECF-9014-B0894FB20E14 Content-Transfer-Encoding: 7bit From: Matt Corallo 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: In-Reply-To: To: Ariel Lorenzo-Luaces , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 14:30:53 -0000 --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 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 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
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 dir=3D"ltr">Matt

On = Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev <bitcoin-dev= @lists.linuxfoundation.org> wrote:

=EF=BB=BF
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.

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

 It was pointed out to me that this discussion is largely mo=
ot as the software complexity for Bitcoin Core to ship an
 option like th=
is is likely not practical/what people would wish to see.

 Bitcoin Co=
re does not have infrastructure to handle switching consensus rules with the=
 same datadir - after running with
 uasf=3Dtrue for some time, valid bloc=
ks will be marked as invalid, and additional development would need to occur=
 to
 enable switching back to uasf=3Dfalse. This is complex, critical cod=
e to get right, and the review and testing cycles
 needed seem to be not w=
orth it.

Without implying anything else, this can be wor=
ked around by a user maintaining two `datadir`s and running two clients.
=
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.
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.
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).
Bandwidth usage should be same si=
nce the internal client only connects to the external client and the OS shou=
ld optimize that case.
CPU usage is doubled, though.

(the general i=
dea came from gmax, just to be clear, though the below use is from me)
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.

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".
The internal node will then follow the=
 dominant chain.


Regards,
ZmnSCPxj


 Instead, the only practical way to ship such a=
n option would be to treat it as a separate chain (the same way regtest,
=
 testnet, and signet are treated), including its own separate datadir and th=
e like.

 Matt

 On 2/19/21 09:13, Matt Corallo via bitcoin-dev w=
rote:

 (Also in response=
 to ZMN...)
 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.
 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).
 Matt
=

 On Feb 19, 2021, at 07:08=
, Adam Back adam@cypherspace.org wrote:

 would dev consensus around releasing LOT=3Dfalse be consid=
ered as "developers forcing their views on users"?

 give=
n there are clearly people of both views, or for now don't care
 but migh=
t 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 c=
ontrol via defaults.

 Otherwise it could be read as saying "developers on average
 d=
isapprove, but if you, the market disagree, go figure it out for
 yoursel=
f" which is not a good message for being defensive and avoiding
 mis-inte=
rpretation of code repositories or shipped defaults as
 "control".

 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundatio=
n.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br>



bitcoin-dev mailing list
bit=
coin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/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--