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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 80DC3B43
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Apr 2017 18:04:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8CDD0140
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Apr 2017 18:04:15 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 4773B38A3126
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Apr 2017 18:03:58 +0000 (UTC)
X-Hashcash: 1:25:170404:bitcoin-dev@lists.linuxfoundation.org::7gEmBcS9oZsWBr8b:bvR7o
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 4 Apr 2017 18:03:56 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201704041803.57409.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 04 Apr 2017 18:04:16 -0000
Recently there has been some discussion of an apparent work-in-progress=20
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny=
,=20
and Steven Pair. Since this hasn't been formally posted on the ML yet, perh=
aps=20
it is still in pre-draft stages and not quite ready for review, but in ligh=
t=20
of public interest, I think it is appropriate to open it to discussion, and=
=20
toward this end, I have reviewed the current revision.
=46or reference, the WIP proposal itself is here:
https://github.com/tothemoon-org/extension-blocks
=3D=3DOverall analysis & comparison=3D=3D
This is a relatively complicated proposal, creating a lot of additional=20
technical debt and complexity in comparison to both BIP 141 and hardforks. =
It=20
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational =
to=20
consider at face value. In fact, it fits much better the inaccurate critici=
sms=20
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is f=
or=20
the most part technically sound. While ill-fit to merely making blocks larg=
er,=20
it may be an ideal fit for fundamentally different block designs such as=20
Rootstock and MimbleWimble in absence of decentralised non-integrated=20
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin=
=20
directly).
=3D=3DFundamental problem=3D=3D
Extension blocks are a risk of creating two classes of "full nodes": those=
=20
which verify the full block (and are therefore truly full nodes), and those=
=20
which only verify the "base" block. However, because the extension is=20
consensus-critical, the latter are in fact not full nodes at all, and are l=
eft=20
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature i=
s=20
of course true of a softfork as well, but softforks are intentionally desig=
ned=20
such that all nodes are capable of trivially upgrading, and there is no=20
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, =
but=20
without the false expectation and pointless complexity.
=3D=3DOther problems & questions=3D=3D
> These outpoints may not be spent inside the mempool (they must be redeeme=
d=20
from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is=
=20
required for CPFP).
The extension block's transaction count is not cryptographically committed-=
to=20
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to=
=20
exploit in practice; however, exploiting it in an extension block may not b=
e=20
as impractical, and it should be fixed given the opportunity.)
> The merkle root is to be calculated as a merkle tree with all extension=20
block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txi=
ds=20
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and=20
wtxid trees built independently and merged at the tip?
> Output script code aside from witness programs, p2pkh or p2sh is consider=
ed=20
invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other=20
various possible destinations. (While static address forms do not exist for=
=20
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to crea=
te=20
unprovably-unspendable UTXOs. Is that intentional?
> The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue =
as=20
BIP141, but even more extreme since it is planned to be used for future siz=
e=20
increases.
> Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not j=
ust=20
say "8 points"?
> Witness script hash v0 shall be worth the number of accurately counted=20
sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static countin=
g,=20
or accurately counting sigops during execution?
> To reduce the chance of having redeem scripts which simply allow for garb=
age=20
data in the witness vector, every 73 bytes in the serialized witness vector=
is=20
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0=20
points...)
=3D=3DTrivial & process=3D=3D
BIPs must be in MediaWiki format, not Markdown. They should be submitted fo=
r=20
discussion to the bitcoin-dev mailing list, not social media and news.
> Layer: Consensus (soft-fork)
Extension blocks are more of a hard-fork IMO.
> License: Public Domain
BIPs may not be "public domain" due to non-recognition in some jurisdiction=
s.=20
Can you agree on one or more of these?=20
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended_=
licenses
> ## Abstract
>=20
> This specification defines a method of increasing bitcoin transaction=20
throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.
> ## Motivation
>=20
> Bitcoin retargetting ensures that the time in between mined blocks will b=
e=20
roughly 10 minutes. It is not possible to change this rule. There has been=
=20
great debate regarding other ways of increasing transaction throughput, wit=
h=20
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.
> Extension blocks leverage several features of BIP141, BIP143, and BIP144 =
for=20
transaction opt-in, serialization, verification, and network services, and =
as=20
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally=20
incompatible with this one, so saying BIP 141 is activated is confusingly=20
incorrect.
> This specification should be considered an extension and modification to=
=20
these BIPs. Extension blocks are _not_ compatible with BIP141 in its curren=
t=20
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn=E2=80=99t a=
ppear to be=20
any justification for not making them compatible.
> This specification prescribes a way of fooling non-upgraded nodes into=20
believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposa=
l,=20
albeit in a mostly compatible manner.
> Note that canonical blocks containing entering outputs MUST contain an=20
extension block commitment (all zeroes if nothing is present in the extensi=
on=20
block).
Please explain why in Rationale.
> Coinbase outputs MUST NOT contain witness programs, as they cannot be=20
sweeped by the resolution transaction due to previously existing consensus=
=20
rules.
Seems like an annoying technical debt. I wonder if it can be avoided.
> The genesis resolution transaction MAY also include a 1-100 byte pushdata=
in=20
the first input script, allowing the miner of the genesis resolution to add=
a=20
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt wi=
th=20
no apparent purpose. Better to just have a consensus rule every input must =
be=20
null.
> The resolution transaction's version MUST be set to the uint32 max (`2^32=
-=20
1`).
Transaction versions are signed, so I assume this is actually simply -1.=20
(While signed transaction versions seemed silly to me, using it for special=
=20
cases like this actually makes sense.)
> ### Exiting the extension block
Should specify that spending such an exit must use the resolution txid, not=
=20
the extblock's txid.
> On the policy layer, transaction fees may be calculated by transaction co=
st=20
as well as additional size/legacy-sigops added to the canonical block due t=
o=20
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of=
=20
doubt:" to be clear that miners may perform any fee logic they like.
> Transactions within the extended transaction vector MAY include a witness=
=20
vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't thi=
s=20
be mandatory?
> - BIP141's nested P2SH feature is no longer available, and no longer a=20
consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the=
=20
economy has updated to support segwit-native addresses.
> To reduce the chance of having redeem scripts which simply allow for garb=
age=20
data in the witness vector, every 73 bytes in the serialized witness vector=
is=20
worth 1 additional point.
Please explain why 73 bytes in Rationale.
> This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
> A consensus dust threshold is now enforced within the extension block.
Why?
> If the second highest transaction version bit (30th bit) is set to to `1`=
=20
within an extension block transaction, an extra 700-bytes is reserved on th=
e=20
transaction space used up in the block.
Why wouldn't users set this on all transactions?
> `default_witness_commitment` has been renamed to=20
`default_extension_commitment` and includes the extension block commitment=
=20
script.
`default_witness_commitment` was never part of the GBT spec. At least descr=
ibe=20
what this new key is.
> - Deployment name: `extblk` (appears as `!extblk` in GBT).
Should be just `extblk` if backward compatibility is supported (and `!extbl=
k`=20
when not).
> The "deactivation" deployment's start time...
What about timeout? None? To continue the extension block, must it be=20
deactivated and reactivated in parallel?
|