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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 959E2C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 16:27:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 7F4CB4027F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 16:27:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id p0dpANeCZWrd
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 16:27:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo114.poczta.onet.pl (smtpo114.poczta.onet.pl
[213.180.149.167])
by smtp2.osuosl.org (Postfix) with ESMTPS id EBF9E400D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 May 2021 16:27:57 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4Fp5Nk0XvWz2K26;
Sun, 23 May 2021 18:27:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1621787270; bh=0WdsnsLS8ua1Ok/sk31gUl1bCYL2yht6VwiRXoHDLZQ=;
h=From:To:Date:Subject:From;
b=jow/lvXKMI9008WCk1NkdX1puX6kddkyqpCSTwh3gEKlLdV+s5ccWxwHoIEkO/kNv
2NxN0FkYIem5LLv48FhaQiyOk0uaZEUSIBPMd66j6ECu4MEw/MLc+vhU1cOFDVA96t
QhyyaG3iMlfVR4w3HIJdjJF7nQLSJSeYVvOZi7D4=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.226.233] by pmq3v.m5r2.onet via HTTP id
202105231826224592010001; Sun, 23 May 2021 18:27:50 +0200
From: vjudeu <vjudeu@gazeta.pl>
X-Priority: 3
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 23 May 2021 18:27:47 +0200
Message-Id: <132915149-33e6cd5749dc76930de03704c89b4399@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.226.233;PL;2
X-Mailman-Approved-At: Sun, 23 May 2021 17:17:17 +0000
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 16:27:59 -0000
> Perhaps the only things that cannot be usefully changed in a softfork is =
the block header format and how proof-of-work is computed from the block he=
ader.
Why not? I can imagine a soft fork where the block header would contain SHA=
-256 and SHA-3 hashes in the same place. The SHA-256 would be calculated as=
-is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 ha=
shes. In this way, if SHA-256 would be totally broken, old nodes would see =
zero hashes in the previous block hash and the merkle tree hash, but the ne=
w nodes would see correct SHA-3 hashes in the same place. So, for example i=
f we have 1d00ffff difficulty, the first 32-bits would be zeroes for all ol=
d nodes, but all new nodes would see SHA-3 truncated to 32-bits in the same=
place. The difficulty could tell us how many zero bits we should truncate =
our SHA-3 result to. Also, in the same way we could introduce SHA-4 in the =
future as a soft-fork if SHA-3 would be broken and we would see many zero b=
its in our mixed SHA-256 plus SHA-3 consensus.
On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
> 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 t=
han can be trivially expected.
> =
> For instance, maaku7 once proposed a softfork that could potentially chan=
ge the block discovery rate as a softfork.
> Although this required exploiting a consensus bug that has since been clo=
sed.
> =
> The example of SegWit shows us that we can in fact create massive changes=
to 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" existi=
ng Merkle Tree, but instead to require miners to embed a commitment to the =
SHA3-Merkle-Tree on the coinbase of the "original" block format, and to bui=
ld "empty" SHA2-Merkle-Trees containing only the coinbase.
> To unupgraded nodes it looks as if there is a denial-of-service attack pe=
rmanently, while upgraded nodes will seek blocks that conform to the SHA3-M=
erkle-Tree embedded in the coinbase.
> =
> (Do note that this definition of "softfork" is the "> 50% of miners is en=
ough to pull everyone to the fork".
> Some thinkers have a stricter definition of "softfork" as "non-upgraded n=
odes 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 f=
its SegWit and Taproot.)
> =
> (In addition, presumably the reason to switch to SHA3 is to avoid potenti=
al preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tre=
e, so... this is a bad example)
> =
> Perhaps the only things that cannot be usefully changed in a softfork is =
the block header format and how proof-of-work is computed from the block he=
ader.
> But the flexibility of the coinbase allows us to hook new commitments to =
new Merkle Trees to it, which allows transactions to be annotated with addi=
tional information that is invisible to unupgraded nodes (similar to the `w=
itness` field of SegWit transactions).
> =
> =
> ------------
> =
> =
> Even if you *do* have a softfork, we should be reminded to look at the hi=
stories 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 wide=
ly accepted as being a definite improvement to the network.
> Yet its implementation and deployment still took a long time, and there w=
as still controversy on how to properly implement the activation code.
> =
> Any hardforks would not only have to go through the hurdles that Taproot =
and SegWit had to go through, but will *also* have to pass through the much=
higher hurdle of being a hardfork.
> =
> Thus, anyone contemplating a hardfork, for any reason, must be prepared t=
o work on it for several **years** before anyone even frowns and says "hmm =
maybe" instead of everyone just outright dismissing it with a simple "hardf=
ork =3D hard pass".
> As a simple estimate, I would assume that any hardfork would require twic=
e the average amount of engeineering-manpower involved in SegWit and Taproo=
t.
> (this assumes that hardforks are only twice as hard as softforks --- this=
estimate may be wrong, and this might provide only a minimum rather than a=
n 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 =
with no real capability to fix them at the base layer, or we have insight o=
n 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 c=
ase of a quantum break.
> =
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> =
|
