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
|
Delivery-date: Sun, 23 Jun 2024 18:19:05 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC5P5KEHZQLBBAET4OZQMGQEXWM2EIQ@googlegroups.com>)
id 1sLYMK-0004Z7-Nc
for bitcoindev@gnusha.org; Sun, 23 Jun 2024 18:19:05 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e0268d49b6dsf7695798276.2
for <bitcoindev@gnusha.org>; Sun, 23 Jun 2024 18:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1719191938; x=1719796738; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=;
b=Vc+rDXd6VCde6paRlf9i6jlwIPzAEeU8Zw7pZHUWSxcgIzbev/1yyOvD89PtjmU4Bz
noGI1CysDJPgHY11RRXfvUU88yBhMuqST8l/0jFEiD+umnRIFWfVUaZJLK1LuUURmOB7
LBM73M7yS6LEx4vbNfhi5EO2SPwbiNydl074NDOCmOJ5DkuoY0OfofVKZwC7tXv7Y1rX
uDBtep8ERVV0asfOwQs/AhSzOH/jgY1CayQjuOvj2iDsvCxqyi7OEnjtI8CnlqeO6Tjx
X11k6JnALYHp4a6EZnTvuTEa8mNNpYUa5erDu9YYA316RNuDCVHImeSBMJooHooRySqB
ABRA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1719191938; x=1719796738; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=;
b=IBUJ6WP00bYKnYrQYzap4dxXRg0ailpZoCR8tlz7UDKD61w9UI5Mg+2Q4t/01S/k9K
RdJ1IhlwYtiaBaGH/VxMkq3iRaqO8QurEFbmKL0Ec5LclMM694b9vrc2PWJXkHQ4vvGk
R30IXcETDY6FqChYX2cyFeCNqIRbWcJ8uKxTtyjjfT6xYQTfBQyzMvHhF3QLtQ783TGc
4tN2ex+b9rQeHQcmQCFcG/u8RDGsANKw5Bz09DkHTTDb1GJCnJBSqimUORjX9nIISkjy
60gRK7Jw9KZOr5mR2akrSwFXmDkDldvm/JqtmGOb1sCEJ6+I2D5hnb7eNXYJISc9IGlc
ej0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1719191938; x=1719796738;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=;
b=dpQYWff94PVRXsX3r7MjTXDTZ4b+8avvvts6J5KJ8X5k27te9ecueTJxgXvoJ1ng2B
FtG13a3HROQfLMt4/DUvOfR/FZc3xAdNogFxyOsGIW565OFSofG2d3ty6RCR76jd8u9A
7NBApgwAgISzDpMIgkvW8xXURMFLCj5JpdLPsbHIMn1voEJj87AyiCeQi1IAOvl2b1WK
ZkNOBKzj1XaAgDIG98ClslqUZY7NlqoOjWMRfBrf/HvD7u7ZSHrJQhte/W1pERD/72tr
9q73wpFFh/dbzS4cq8jtfUtHrpWYR0Roe+eeuLRfzSq5QbDiAxR0Dc5M/M8+4IgivDFy
urTw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWHSO1bVtblO5T3oYlSqOWaFoH98eNcXTnjYqE1MIL+WMHiWFsV/dxapyx0tXkt33Ddp6WbuO2Q04gZ2sD9TjnA6IL75R0=
X-Gm-Message-State: AOJu0Yz8Pe5nInHPtWx8tUNHQW7G37KudhqAKyvTuRx6b8S/TP35adt8
fiu5+g9NOtbi7Hb7N1V3Qvqq1mGGqJvl6iS4rzNE7eSxvsTXVSTS
X-Google-Smtp-Source: AGHT+IHh+EPg2QB+4TLegFk/m5u4yleEENpvp9+n1XOcYVcHQdDDGUarOEARlqTBEP7eprzB31SDPg==
X-Received: by 2002:a25:6b41:0:b0:df4:d91d:74a7 with SMTP id 3f1490d57ef6-e0304007dc0mr3016301276.45.1719191937647;
Sun, 23 Jun 2024 18:18:57 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:1895:b0:dff:34c9:92f8 with SMTP id
3f1490d57ef6-e02d0ac0766ls5977524276.0.-pod-prod-05-us; Sun, 23 Jun 2024
18:18:56 -0700 (PDT)
X-Received: by 2002:a05:690c:6e0d:b0:62c:67f4:4f5 with SMTP id 00721157ae682-643ae44f5e5mr2390177b3.9.1719191936182;
Sun, 23 Jun 2024 18:18:56 -0700 (PDT)
Received: by 2002:a05:690c:4605:b0:627:7f59:2eee with SMTP id 00721157ae682-6413a4f66e0ms7b3;
Sun, 23 Jun 2024 17:35:31 -0700 (PDT)
X-Received: by 2002:a05:690c:7001:b0:62c:c5ea:66ad with SMTP id 00721157ae682-643ab54d839mr4222117b3.4.1719189330473;
Sun, 23 Jun 2024 17:35:30 -0700 (PDT)
Date: Sun, 23 Jun 2024 17:35:30 -0700 (PDT)
From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com>
In-Reply-To: <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
<72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com>
<heKH68GFJr4Zuf6lBozPJrb-StyBJPMNvmZL0xvKFBnBGVA3fVSgTLdWc-_8igYWX8z3zCGvzflH-CsRv0QCJQcfwizNyYXlBJa_Kteb2zg=@protonmail.com>
<5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com>
<yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_258520_191179190.1719189330256"
X-Original-Sender: eric@voskuil.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)
------=_Part_258520_191179190.1719189330256
Content-Type: multipart/alternative;
boundary="----=_Part_258521_1966216055.1719189330256"
------=_Part_258521_1966216055.1719189330256
Content-Type: text/plain; charset="UTF-8"
Thanks for the responses Antoine.
> As discussed here it would let node implementations cache block failures
at an earlier stage of validation. Not a large gain, but still nice to have.
It is not clear to me how determining the coinbase size can be done at an
earlier stage of validation than detection of the non-null coinbase. The
former requires parsing the coinbase to determine its size, the latter
requires parsing it to know if the point is null. Both of these can be
performed as early as immediately following the socket read.
size check
(1) requires new consensus rule: 64 byte transactions (or coinbases?) are
invalid.
(2) creates a consensus "seam" (complexity) in txs, where < 64 bytes and >
64 bytes are potentially valid.
(3) can be limited to reading/skipping header (80 bytes) plus parsing 0 -
65 coinbase bytes.
point check
(1) requires no change.
(2) creates no consensus seam.
(3) can be limited to reading/skipping header (80 bytes) plus parsing 6 -
43 coinbase bytes.
Not only is this not a large (performance) gain, it's not one at all.
> It would also avoid a large footgun for anyone implementing a software
verifying an SPV proof verifier and not knowing the intricacies of the
protocol...
It seems to me that introducing an arbitrary tx size validity may create
more potential implementation bugs than it resolves. And certainly anyone
implementing such a verifier must know many intricacies of the protocol.
This does not remove one, it introduces another - as there is not only a
bifurcation around tx size but one around the question of whether this rule
is active.
> Finally, it would get rid of a large footgun in general.
I do not see this. I see a very ugly perpetual seam which will likely
result in unexpected complexities over time.
> Certainly, unique block hashes would be a useful property for Bitcoin to
have. It's not far-fetched to expect current or future Bitcoin-related
software to rely on this.
This does not produce unmalleable block hashes. Duplicate tx hash
malleation remains in either case, to the same effect. Without a resolution
to both issues this is an empty promise.
The only possible benefit that I can see here is the possible very small
bandwidth savings pertaining to SPV proofs. I would have a very hard time
justifying adding any consensus rule to achieve only that result.
Best,
Eric
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.com.
------=_Part_258521_1966216055.1719189330256
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks for the responses Antoine.<br /><br />> =C2=A0As discussed here i=
t would let node implementations cache block failures at an earlier stage o=
f validation. Not a large gain, but still nice to have.<br /><br />It is no=
t clear to me how determining the coinbase size can be done at an earlier s=
tage of validation than detection of the non-null coinbase. The former requ=
ires parsing the coinbase to determine its size, the latter requires parsin=
g it to know if the point is null. Both of these can be performed as early =
as immediately following the socket read.<br /><br />size check<br /><br />=
(1) requires new consensus rule: 64 byte transactions (or coinbases?) are i=
nvalid.<br />(2) creates a consensus "seam" =C2=A0(complexity) in txs, wher=
e < 64 bytes and > 64 bytes are potentially valid.<br />(3) can be li=
mited to reading/skipping header (80 bytes) plus parsing 0 - 65 coinbase by=
tes.<br /><br />point check<br /><br />(1) requires no change.<br />(2) cre=
ates no consensus seam.<br />(3) can be limited to reading/skipping header =
(80 bytes) plus parsing 6 - 43 coinbase bytes.<br /><br />Not only is this =
not a large (performance) gain, it's not one at all.<br /><br />> It wou=
ld also avoid a large footgun for anyone implementing a software verifying =
an SPV proof verifier and not knowing the intricacies of the protocol...<br=
/><br />It seems to me that introducing an arbitrary tx size validity may =
create more potential implementation bugs than it resolves. And certainly a=
nyone implementing such a verifier must know many intricacies of the protoc=
ol. This does not remove one, it introduces another - as there is not only =
a bifurcation around tx size but one around the question of whether this ru=
le is active.<br />=C2=A0<br />> Finally, it would get rid of a large fo=
otgun in general. <br /><br />I do not see this. I see a very ugly perpetua=
l seam which will likely result in unexpected complexities over time.<br />=
<br />> Certainly, unique block hashes would be a useful property for Bi=
tcoin to have. It's not far-fetched to expect current or future Bitcoin-rel=
ated software to rely on this.<br /><br />This does not produce unmalleable=
block hashes. Duplicate tx hash malleation remains in either case, to the =
same effect. Without a resolution to both issues this is an empty promise.<=
br /><br />The only possible benefit that I can see here is the possible ve=
ry small bandwidth savings pertaining to SPV proofs. I would have a very ha=
rd time justifying adding any consensus rule to achieve only that result.<b=
r /><br />Best,<br />Eric<br /><span style=3D"font-family: Arial, sans-seri=
f;"><br /></span>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.com</a>.=
<br />
------=_Part_258521_1966216055.1719189330256--
------=_Part_258520_191179190.1719189330256--
|
