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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2B318C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:39:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 188F6830C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:39:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DqeMFpaF7YaJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:39:10 +0000 (UTC)
X-Greylist: delayed 00:07:57 by SQLgrey-1.8.0
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com
[209.85.210.42])
by smtp1.osuosl.org (Postfix) with ESMTPS id A5523830C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 16:39:10 +0000 (UTC)
Received: by mail-ot1-f42.google.com with SMTP id s6so12554102otk.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 08:39:10 -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
:cc:content-transfer-encoding;
bh=g56vtzE2siGPqWDz2SxNOhJjwdKD71BH9FJT120sbpE=;
b=LAdKGGimT0IGHHR+BwXAvAt9jqht4gfg5BR+zirL6AYgDOGHx+zjpyqgkq9udqILuA
NUJ20AgUfeWzxq2yCs965cUpCCwTEKql3NamebkDit0s0Z2siaJG2U+wnKx/yXl78nF1
8RCyTRPpXNgTCJZqMfb8RTCkhPLaAW/Pml6+V4wujqHsKDhufFJVe4YG++hbL9A8urGh
b4LbJy5iRCAKoVTcv28GNGRTjY3m38CTqYEZQOtQrky/Hq7Zk+JdgdT6JbB8RF0L0Tjy
ruwgALW26ct33Z+co45fxBnfbbje7p/YHfyBkG9g+orNFaQfQknCyzg708sigGKJeZ8H
6f/A==
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:cc:content-transfer-encoding;
bh=g56vtzE2siGPqWDz2SxNOhJjwdKD71BH9FJT120sbpE=;
b=ZdykB3PBZaG9M3w+5F7x3v89VWxuPK+m9qvKL9eHF9q/2c60MAZqA+MX2NT3Dg4Hkh
vpYbERGtwelG6PDVr4jq6dTPVjBCfa5zrRHV/ofqHLCEFOwEWu8GY9ODr+f1mzF/aOk3
oxGN5csh+UTjbKPWqxVPer4cpAMRh2q0dn06dynZdqJ39BMY0+Grx5HsLqNXXbhAXs7i
XDTGq7+E9MO/gqomvZYBOcfpC54Uf6VKB/TY6Z2BaCqSbQ6DtWk6FCKX36uPnjkmWho4
5zigxKR+XMtcX1/+wDEdnSeLc/hTFufcGDItfu0mmdloNjB0RjFFZcJIO3y7Ve2i4ZtF
nc5g==
X-Gm-Message-State: AOAM532uVHC9yRrJm/vV1ylnnHVy+/7d2dcte/djl7nFQvd9dVlOgkcd
X0v/dsEW334GY7iff/R/GZi4+5af6vSsc0SdNKO+rcqqdC4=
X-Google-Smtp-Source: ABdhPJyZo9MChu6D38yMxHxWwKzhA+vLAxpO/RkutBIM0y1cvd7hSvHvuzeLrAt+aCD9rspd+vbOeQT3JktCY2SxxsE=
X-Received: by 2002:a9d:30d3:: with SMTP id r19mr12194289otg.123.1614011472466;
Mon, 22 Feb 2021 08:31:12 -0800 (PST)
MIME-Version: 1.0
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
<7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
In-Reply-To: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Mon, 22 Feb 2021 17:31:01 +0100
Message-ID: <CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Michael Folkson <michaelfolkson@gmail.com>
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:39:12 -0000
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 fr=
om a
> lockinontimeout=3Dfalse node during a chainsplit in the MUST_SIGNAL phase=
,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other=
.
>
>
> (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 allow=
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 over =
months. We can=E2=80=99t simply ignore that.
>
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=3Dtrue need to be well connected so they don'=
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 m=
aterial technical complexity hiding behind a =E2=80=9Cchange the consensus=
rules=E2=80=9C option. Given it=E2=80=99s not a critical feature by any me=
ans, putting resources into fixing these issues probably isn=E2=80=99t wort=
h it.
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
