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
158
159
160
161
162
163
164
165
166
167
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id D5A1AC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:49:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B1D2B6F584
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:49:09 +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 EpRQVKK7e29t
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:49:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com
[209.85.210.42])
by smtp3.osuosl.org (Postfix) with ESMTPS id 93E786F510
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:49:07 +0000 (UTC)
Received: by mail-ot1-f42.google.com with SMTP id h22so4259708otr.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 08:49:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=OL1y0D5MOoJyU/OIMTzXBMnIKlaFyTcuhbk3UK0NyB8=;
b=kEhvXUfS9FfVphEG87TsWYg5zQc+xMk/nMYtXFmlA/HNO5L67F0ogcd+Ske+JYBOdS
N+yLjtPFn3Jq5vGOLxDRSpaTOQ7mgzkbFZ41PRsKYd9ux2EWyPX78tLFYTS9TQg1vJNG
1DrmxjpVXkHMUq87SaseCrjQ9JP+FpoVgFH+GT1waQBVSQnrUdQv1xtsmsMZChGGI280
jVaxKwch7Thza1BcvAM2gPXyiYZ3DU+XZvUfpxNlQBzI+c+996WSeqZhKoeBgBuiqPhi
g9DpIpe5VjK2RlqJKywL2SjAgojVDVXsyFmryzXslWmfHYOs8yGPBmT5pGHozJ+mHPyU
7gVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=OL1y0D5MOoJyU/OIMTzXBMnIKlaFyTcuhbk3UK0NyB8=;
b=E/2KN3NmzszDnM6+/As/A7U9IaufV0Tn/CtspaZwRNyu4DwZz1oE4mSLe5QQWV9rPX
NeMGQLVurCdOUNKmTyax66TpleGi713vA/hnLFh6yYjqClciTi1JgYReHhvmaaCRjkjV
qZ5pPERIqtaKaeFDMr6QjDwF3MlpMmRFq3ufcMfqlPufbg9Q1NtzYupPdVdsb07c3Rnn
x/f7J6nQp4VKhRT9ywY91jQ2neT28hFoVj9i9WupJodiM/oBVbDjXYulelDVOua7JTDv
03wzNlt5O/3ewg8eljvMHjBTn0dM0J27ED2fWiSY+HPTNlxb2NYLJ7Aeq2L8XP6JF9U9
WP0Q==
X-Gm-Message-State: AOAM532bJ+90gCOo/sUCFDHGisT04foSJmVL/6l9cKDiXU+/Vv8V7bbl
L3Cgivw07CvXVRf7LIMnlNS0l1N4g0kPaRFHNG/ZVwSLcSY=
X-Google-Smtp-Source: ABdhPJxla68oJlbuv/ymgk5T2L6ZNrWYDajRXgUkHUc2MJ7XiLMXHfEzMMuEzI3c2eZ11Jx/vh8c7bN5cWGB7k29KeM=
X-Received: by 2002:a9d:6a8c:: with SMTP id l12mr17594652otq.343.1614012546341;
Mon, 22 Feb 2021 08:49:06 -0800 (PST)
MIME-Version: 1.0
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
<7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
<CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
In-Reply-To: <CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Mon, 22 Feb 2021 17:48:55 +0100
Message-ID: <CABm2gDp5dRTrPEqPfrjOeeYBn6RMS=HFMbtkJ+MM0SMVnSfK5A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 22 Feb 2021 16:49:10 -0000
Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want this, but if people want it I offer
myself to code it,
I mean, just imagine that a day after publishing a bitcoin core
release with activation software for taproot some one, let's say in
New York reach an Agreement to "just use the same activation
mechanism, but for our 32 mb hardfork, it's about time, now computers
are 64 bits anyway". How convenient would it be to just cancel that
with 2 lines in bitcoin core?
Not that I think it will be necessary, but perhaps we want it just in case.
On Mon, Feb 22, 2021 at 5:31 PM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
> Sorry, I haven't read everything. I just want to say what I think is
> the best option and why.
> Let's say something like 2 years in which miners can signal activation
> after which, the MUST signal it for their blocks to be valid (I think
> this is LOT=3Dtrue, but I don't remember what LOT stands for).
> Some may argue than it's easier to move from LOT=3Dfalse to LOT=3Dtrue
> than viceversa (I think I'm getting this right), but either way
> different clients could interpret things more differently more easily
> and, you know, that's really bad.
> If anyone is against the consensus change itself, what they should do
> is run a client in which the must is turned into a MUST NOT. Whenever
> miners signal activation, blocks aren't valid so that it doesn't
> happen.
> That way both sides can be cleanly separated and both communities
> (assuming there's a community of users opposing the change) can stick
> together with their own in the same chain. That is, having only 2
> chains in total if there are users opposing the change or only one if
> not, but never 2 chains for people who want the change or 2 chains for
> pople who don't want it.
>
> Just my two sats, please nobody ask me "why would anyone oppose
> taproot?" or anything similar. Because I'm trying to generalize here,
> if we're talking about activation, I think the specifics of the change
> are kind of irrelevant.
>
> Separately: thanks to everyone who worked on taproot.
>
>
> On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >
> >
> > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian.com.au> wrote:
> >
> > =EF=BB=BFIf a lockinontimeout=3Dtrue node is requesting compact blocks =
from a
> > lockinontimeout=3Dfalse node during a chainsplit in the MUST_SIGNAL pha=
se,
> > I think that could result in a ban.
> >
> > More importantly, nodes on both sides of the fork need to find each oth=
er.
> >
> >
> > (If there was going to be an ongoing fork there'd be bigger things to
> > worry about...)
> >
> >
> > I think it should be clear that a UASF-style command line option to all=
ow consensus rule changes in the node in the short term, immediately before=
a fork carries some risk of a fork, even if I agree it may not persist ove=
r months. We can=E2=80=99t simply ignore that.
> >
> > I think the important specific case of this is something like "if a cha=
in
> > where taproot is impossible to activate is temporarily the most work,
> > miners with lockinontimeout=3Dtrue need to be well connected so they do=
n't
> > end up competing with each other while they're catching back up".
> >
> >
> > Between this and your above point, I think we probably agree - there is=
material technical complexity hiding behind a =E2=80=9Cchange the consens=
us rules=E2=80=9C option. Given it=E2=80=99s not a critical feature by any =
means, putting resources into fixing these issues probably isn=E2=80=99t wo=
rth it.
> >
> > Matt
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
