1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3BB0FC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 02:55:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 2F9AB87520
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 02:55:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vG322YNMxDvq
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 02:55:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by hemlock.osuosl.org (Postfix) with ESMTPS id E5950874F3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 02:55:22 +0000 (UTC)
Date: Sat, 20 Feb 2021 02:55:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1613789719;
bh=yaOS9tPwEFG4nd5LeHLvMCqS9SJHb9dMiDjVIJHF0YU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=VeOIhOkwunAN9f6VHyzTeBXS8en1rEQPHKOeFbqynbWwROECeMkonrcY/Delcf7oa
S3mEVFPhwimCkE79oU5QN8Pm0b9jdgqq/cJRhv0re/QwBCJkhjjfi+Gzf7B6uhKxtB
F7yJEZTjjPWqaZMu38y/tm4xROglpCOiquG5gv+4=
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)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2021 02:55:25 -0000
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
|
