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