Date: Sat, 20 Feb 2021 02:55:16 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <GCV_t7q-LWZOSrp4_BzurAjmQTuAcyptvOLUsQEpGNhg_l_SPZ3q0PlBxtUKOLfLs4G73ecSdK4SapbbBnRUo2j3yJg2_OTXgcFRzZOau_Q=@protonmail.com>
In-Reply-To: <ce8925d5-d2f1-1adb-530d-36f89f5b6352@bluematt.me>
References: <CALqxMTFKbjg3yDPnrmL8TgtypirB_fDMMJD=AJxjYav51hmEAw@mail.gmail.com>
 <E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com>
 <ce8925d5-d2f1-1adb-530d-36f89f5b6352@bluematt.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Michael Folkson <michaelfolkson@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
Precedence: list

Good morning list,

> It was pointed out to me that this discussion is largely moot as the soft=
ware complexity for Bitcoin Core to ship an
> option like this is likely not practical/what people would wish to see.
>
> Bitcoin Core does not have infrastructure to handle switching consensus r=
ules with the same datadir - after running with
> uasf=3Dtrue for some time, valid blocks will be marked as invalid, and ad=
ditional development would need to occur to
> enable switching back to uasf=3Dfalse. This is complex, critical code to =
get right, and the review and testing cycles
> needed seem to be not worth it.

Without implying anything else, this can be worked around by a user maintai=
ning two `datadir`s and running two clients.
This would have an "external" client running an LOT=3DX (where X is whateve=
r 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 to =
the external client and connects only to that client, using it as a firewal=
l.
The external client can be run pruned in order to reduce diskspace resource=
 usage (the internal client can remain unpruned if that is needed by the us=
er, 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 t=
he external client and the OS should optimize that case.
CPU usage is doubled, though.

(the general idea 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 prefere=
nces.

If Taproot is not MASF-activated and LOT=3D!U is what dominates later (wher=
e 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 (opt=
ionally upgrading the internal node to LOT=3D!U) as a way to "change their =
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 an 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 =
the like.
>
> Matt
>
> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>
> > (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=
 now. People are of course more than welcome to run such software themselve=
s, but I anticipate the loud minority on Twitter and here aren=E2=80=99t pr=
ocessing enough transactions or throwing enough financial weight behind the=
ir decision for them to do anything but just switch back if they find thems=
elves on a chain with no blocks.
> > There=E2=80=99s nothing we can (or should) do to prevent people from th=
reatening 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 main=
tainers and developers do is to recommend courses of action which they beli=
eve have reasonable levels of consensus and are technically sound. Luckily,=
 there=E2=80=99s strong historical precedent for people deciding to run oth=
er software around forks, so misinterpretation is not very common (just lik=
e there=E2=80=99s strong historical precedent for miners not unilaterally d=
eciding 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 considered as "=
developers forcing their views on users"?
> > >
> > > 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.
> >
> > > 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".
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev