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: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 53FD9C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 11:01:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 303D360684
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 11:01:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
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 pwJa_Q17_DWl
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 11:01:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0679D605B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 11:01:38 +0000 (UTC)
Date: Sun, 23 May 2021 11:01:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1621767695;
bh=L5n97p11855pqDpcywpLzxmpQNTgtcqyTgJ7Z5EcUME=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=XCltUVVHfwCnfoORUOnbvXIzIYV+IpFUFEtxYmYzVLTeJ8mAyDACz4exJH4xhUrB/
B0B9gTQUpFJivdPDv7TBG2DPvIB5JGe8WXTMt2tsx28N5bYPJOziVgeYrLb7RnPk9U
PXM+ArvGNJmetQ0TuRJdZ1AX+XgiXm8WRQYpIJ/I=
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Pe0KEu5sh80-Bz1nMjOCVhi_tA48kDEFTE5YFob61ADSD_2G9AIFwdJ8VLZnaG6He-elxnFaysFt4588vTWepc4H7xrgESZEav16LECw68I=@protonmail.com>
In-Reply-To: <CABm2gDq5hMN+-BUfY07KEDca0wCjN4G=iWptenBhzjZ3X9Mn7w@mail.gmail.com>
References: <DM6PR02MB6187B30D0941044E24699FF8CD299@DM6PR02MB6187.namprd02.prod.outlook.com>
<CABm2gDpSWEA+AU1OKGBatuFT8biSO2S8MxfvRH8wHbF7=OEetQ@mail.gmail.com>
<DM6PR02MB6187F5E2A74950211F3934C9CD289@DM6PR02MB6187.namprd02.prod.outlook.com>
<CABm2gDq5hMN+-BUfY07KEDca0wCjN4G=iWptenBhzjZ3X9Mn7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature
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: Sun, 23 May 2021 11:01:40 -0000
Good morning Jorge, et al,
> Hardforks can be useful too.
> But, yes, I agree softforks are preferable whenever possible.
I think in principle the space of possible softforks is very much wider tha=
n can be trivially expected.
For instance, maaku7 once proposed a softfork that could potentially change=
the block discovery rate as a softfork.
Although this required exploiting a consensus bug that has since been close=
d.
The example of SegWit shows us that we can in fact create massive changes t=
o the transaction and block formats with a softfork.
For example, it is possible to change the Merkle Tree to use SHA3 instead, =
in a softfork, by requiring that miners no longer use the "normal" existing=
Merkle Tree, but instead to require miners to embed a commitment to the SH=
A3-Merkle-Tree on the coinbase of the "original" block format, and to build=
"empty" SHA2-Merkle-Trees containing only the coinbase.
To unupgraded nodes it looks as if there is a denial-of-service attack perm=
anently, while upgraded nodes will seek blocks that conform to the SHA3-Mer=
kle-Tree embedded in the coinbase.
(Do note that this definition of "softfork" is the "> 50% of miners is enou=
gh to pull everyone to the fork".
Some thinkers have a stricter definition of "softfork" as "non-upgraded nod=
es can still associate addresses to values in the UTXO set but might not be=
able to detect consensus rules violations in new address types", which fit=
s SegWit and Taproot.)
(In addition, presumably the reason to switch to SHA3 is to avoid potential=
preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree,=
so... this is a bad example)
Perhaps the only things that cannot be usefully changed in a softfork is th=
e block header format and how proof-of-work is computed from the block head=
er.
But the flexibility of the coinbase allows us to hook new commitments to ne=
w Merkle Trees to it, which allows transactions to be annotated with additi=
onal information that is invisible to unupgraded nodes (similar to the `wit=
ness` field of SegWit transactions).
------------
Even if you *do* have a softfork, we should be reminded to look at the hist=
ories of SegWit and Taproot.
SegWit became controversial later on, which delayed its activation.
On the other hand, Taproot had no significant controversy and it was widely=
accepted as being a definite improvement to the network.
Yet its implementation and deployment still took a long time, and there was=
still controversy on how to properly implement the activation code.
Any hardforks would not only have to go through the hurdles that Taproot an=
d SegWit had to go through, but will *also* have to pass through the much h=
igher hurdle of being a hardfork.
Thus, anyone contemplating a hardfork, for any reason, must be prepared to =
work on it for several **years** before anyone even frowns and says "hmm ma=
ybe" instead of everyone just outright dismissing it with a simple "hardfor=
k =3D hard pass".
As a simple estimate, I would assume that any hardfork would require twice =
the average amount of engeineering-manpower involved in SegWit and Taproot.
(this assumes that hardforks are only twice as hard as softforks --- this e=
stimate may be wrong, and this might provide only a minimum rather than an =
expected average)
There are no quick solutions in this space.
Either we work with what we have and figure out how to get around issues wi=
th no real capability to fix them at the base layer, or we have insight on =
future problems and start working on future solutions today.
For example, I know at least one individual was maintaining an "emergency" =
branch to add some kind of post-quantum signature scheme to Bitcoin, in cas=
e of a quantum break.
Regards,
ZmnSCPxj
|
