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 8D017C0001 for ; 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 ; 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 ; 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 ; Sat, 20 Feb 2021 17:20:32 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id b15so1042857pjb.0 for ; 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: References: 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: From: Ariel Lorenzo-Luaces Date: Sat, 20 Feb 2021 09:20:27 -0800 To: ZmnSCPxj , Bitcoin Protocol Discussion , ZmnSCPxj Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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

Cheers
Ariel Lorenzo-Luaces
=
On Feb 19, 2021, at 6:55 PM, ZmnSCPxj vi= a bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wro= te:
Good morning list,

 It was pointed out to me that this discussion is largely moot as=
 the software complexity for Bitcoin Core to ship an
 option like this i=
s likely not practical/what people would wish to see=2E

 Bitcoin Cor=
e does not have infrastructure to handle switching consensus rules with the=
 same datadir - after running with
 uasf=3Dtrue for some time, valid blo=
cks will be marked as invalid, and additional development would need to occ=
ur to
 enable switching back to uasf=3Dfalse=2E This is complex, critica=
l code to get right, and the review and testing cycles
 needed seem to b=
e not worth it=2E

Without implying anything else, this =
can be worked around by a user maintaining two `datadir`s and running two c=
lients=2E
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
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
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
CPU usage =
is doubled, though=2E

(the general idea came from gmax, just to be c=
lear, though the below use is from me)

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

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


Regards,
ZmnSCPxj


 Instead, the only practical way to ship such an optio=
n would be to treat it as a separate chain (the same way regtest,
 testn=
et, and signet are treated), including its own separate datadir and the lik=
e=2E

 Matt

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

 (Also in resp=
onse to ZMN=2E=2E=2E)
 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
 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
 Matt

 On Feb 19, 2021, at 07:08, Adam Back adam@cyphersp=
ace=2Eorg wrote:

 w=
ould dev consensus around releasing LOT=3Dfalse be considered as "developer=
s forcing their views on users"?

 given there are clear=
ly people of both views, or for now don't care
 but might later, it woul=
d minimally be friendly and useful if
 bitcoin-core has a LOT=3Dtrue opt=
ion - and that IMO goes some way to
 avoid the assumptive control via de=
faults=2E

 Otherwise it could be read as saying "developers on average
 disapp=
rove, but if you, the market disagree, go figure it out for
 yourself" w=
hich is not a good message for being defensive and avoiding
 mis-interpr=
etation of code repositories or shipped defaults as
 "control"=2E

 bitcoin-dev mailing list
 bitcoin-dev@lists=2Elinuxfounda=
tion=2Eorg
 https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/b=
itcoin-dev



bitcoin-dev mai=
ling list
bitcoin-dev@lists=2Elinuxfoundation=2Eorg
https://lists=
=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
------M3VKR8RC6SQIK94NGDLBZZCJT3IH3B--