summaryrefslogtreecommitdiff
path: root/84/96e50b2a49043ca929e2e5116434f942bacac4
blob: 18290267838d1d571f9068f1649e90fbb28cee2d (plain)
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
Return-Path: <rodolfo@coinkite.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C2460EBA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Jun 2018 20:51:47 +0000 (UTC)
X-Greylist: delayed 00:09:33 by SQLgrey-1.7.6
Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com
	[173.203.187.89])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9D56674
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Jun 2018 20:51:46 +0000 (UTC)
Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1])
	by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id
	220FA5290 for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Jun 2018 16:42:13 -0400 (EDT)
Received: from smtp105.iad3b.emailsrvr.com (relay.iad3a.rsapps.net
	[172.27.255.110])
	by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTPS id
	1AC355215 for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Jun 2018 16:42:13 -0400 (EDT)
Received: from smtp14.relay.iad3b.emailsrvr.com (localhost [127.0.0.1])
	by smtp14.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id
	1A3C6E008D; Thu, 28 Jun 2018 16:42:11 -0400 (EDT)
X-Auth-ID: rodolfo@coinkite.com
Received: by smtp14.relay.iad3b.emailsrvr.com (Authenticated sender:
	rodolfo-AT-coinkite.com) with ESMTPSA id BC590E0095; 
	Thu, 28 Jun 2018 16:42:10 -0400 (EDT)
X-Sender-Id: rodolfo@coinkite.com
Received: from [10.10.0.11]
	(CPE44d9e70592e4-CM64777d5e0200.cpe.net.cable.rogers.com
	[99.248.13.208])
	(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384)
	by 0.0.0.0:465 (trex/5.7.12); Thu, 28 Jun 2018 16:42:11 -0400
From: Rodolfo Novak <rodolfo@coinkite.com>
Message-Id: <9EE074B3-5A3D-489E-90F1-207BBD281BBE@coinkite.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4ACC3DF0-E3FE-47C3-B859-F0B92AD67D34"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 28 Jun 2018 16:42:09 -0400
In-Reply-To: <0BT4A0BFbcfUM9xlYjS-7Cy1zpaI1J9qsIpWH_xgv2ZLhcmxb4Es5KlpMJCvHVEu8BDbBweZ92RHnES5HxDMulRhJkYSZAPi-CgXQ3uwkfY=@achow101.com>
To: Achow101 <achow101-lists@achow101.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<20180621195654.GC99379@coinkite.com>
	<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
	<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
	<f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com>
	<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
	<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
	<J0KV-aP96fSVHPkPw85N2qdKV_F5vqXt5fIFwKDp9wBjRKJ6bZpUEtzbgHyxlWW9PCXMOEVZnyUnJ-kW281ZbblbCp2sbZI_UyTP46q-PiY=@achow101.com>
	<87k1qk7oca.fsf@jb55.com>
	<0BT4A0BFbcfUM9xlYjS-7Cy1zpaI1J9qsIpWH_xgv2ZLhcmxb4Es5KlpMJCvHVEu8BDbBweZ92RHnES5HxDMulRhJkYSZAPi-CgXQ3uwkfY=@achow101.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 28 Jun 2018 21:08:33 +0000
Subject: Re: [bitcoin-dev] BIP 174 thoughts
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: Thu, 28 Jun 2018 20:51:47 -0000


--Apple-Mail=_4ACC3DF0-E3FE-47C3-B859-F0B92AD67D34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Folks,

Thanks for expediting this debate, I understand some still disagree =
about how this final spec should look like.

1. Coldcard's plugin for Electrum using the original BIP spec is ready, =
https://github.com/spesmilo/electrum/pull/4470 =
<https://github.com/spesmilo/electrum/pull/4470>
2. Our hardware is ready with this spec (src will be public soon)
3. Samourai Wallet and Sentinel also are ready with the current spec.

We intend to upgrade it once the final spec is ready, but I need to ship =
Coldcard.

Cheers,

=E2=84=9D.

Rodolfo Novak  ||  Founder, Coinkite  ||  twitter @nvk  ||  GPG: =
B444CDDA

> On Jun 27, 2018, at 13:55, Achow101 via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Hi,=E2=80=8B
>=20
> On June 26, 2018 11:09 PM, William Casarin <jb55@jb55.com> wrote:
>=20
>> =E2=80=8B=E2=80=8B
>>=20
>> Hey Andrew,
>>=20
>> If I'm reading the spec right: the way it is designed right now, you
>>=20
>> could create hundreds of thousands of zero bytes in the input or =
output
>>=20
>> key-value arrays. As far as I can tell this would be considered =
valid,
>>=20
>> as it is simply a large array of empty dictionaries. Is this right? =
I'm
>>=20
>> worried about buffer overflows in cases where someone sends a large =
blob
>>=20
>> of zeros to an unsuspecting implementation.
>=20
> No, that is incorrect. That whole paragraph is actually outdated, it =
was intended
> for the possibility of adding output maps, which we have already done. =
I have=20
> removed it from the BIP.
>=20
> However, it is possible for a PSBT to contain very large unknown =
key-value pairs=20
> which could potentially cause a problem. But I do not think that large =
PSBTs should=20
> really be a problem as they are really something that the user has to =
enter rather=20
> than something received remotely without user interaction.
>=20
>=20
>=20
> On June 27, 2018 6:39 AM, Andrea via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>> =E2=80=8B=E2=80=8B
>>=20
>> Hi William, Andrew, list,
>>=20
>> As noted by William there are some types missing in the global-types =
definition, because the number of each map for I/O must be known to the =
parser in order to use the correct definitions for the types. At the =
moment a parser reading a key-value record does not know whether it =
should read it as per-input type or per-output, a way to address this is =
to declare in advance the number of maps and ensure they are ordered =
(inputs first). If you haven't already worked out some types for that i =
propose using:
>>=20
>=20
> Parsers actually do know because that information is present in the =
unsigned transaction=20
> at the beginning of each PSBT. Since each input and output must be =
accounted for,
> a parser can just parse the unsigned transaction and from there it can =
know how
> many inputs and outputs to expect. If it sees more or less, it should =
throw an error
> as the transaction is invalid.
>=20
> Of course this implies that implementations will need to parse the =
unsigned transaction,
> but not all actually need to. Combiners do not need to, they just need =
to merge the
> maps together and follow the key uniqueness rule. They don't really =
need to know
> or care about the number of inputs and outputs, just that the PSBTs =
being merged
> share the same unsigned transaction and have the same number of maps.
>=20
> Other roles need to understand the unsigned transaction anyways, so =
they still need
> to parse it thus this isn't really a problem for those roles.
>=20
>>=20
>>    On another note I think we can set a hard limit on the size of the =
PSBT, currently is 'legal' to produce a very large PSBT with an =
excessive number of Inputs and Outputs. By excessive I mean that even in =
the best case scenario (using the smallest possible scriptPubKey as in =
P2WPKH) it is possible to create a PSBT that would certainly create an =
invalid transaction (because of its size) when finalized. I haven't =
found anything related to this in the previous discussions, please =
ignore this if it was already proposed/discussed.
>>=20
>=20
> I don't think such a limitation is practical or useful. A transaction =
can currently have, at most,
> ~24000 inputs and ~111000 outputs (+/- a few hundred) which is well =
beyond any useful limit.
> Additionally, such limits may not be as extensible for future work. It =
is hard to determine what
> is a reasonable limit on transaction size, and I don't think it is =
useful to have a limit. At worst
> we would simply create an invalid transaction if it were too large.
>=20
>=20
> Andrew
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_4ACC3DF0-E3FE-47C3-B859-F0B92AD67D34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">Hello Folks,</div><div class=3D""><br =
class=3D""></div><div class=3D"">Thanks for expediting this debate, I =
understand some still disagree about how this final spec should look =
like.</div><div class=3D""><br class=3D""></div><div class=3D"">1. =
Coldcard's plugin for Electrum using the original BIP spec is =
ready,&nbsp;<a href=3D"https://github.com/spesmilo/electrum/pull/4470" =
class=3D"">https://github.com/spesmilo/electrum/pull/4470</a></div><div =
class=3D"">2. Our hardware is ready with this spec (src will be public =
soon)</div><div class=3D"">3. Samourai Wallet and Sentinel also are =
ready with the current spec.</div><div class=3D""><br =
class=3D""></div><div class=3D"">We intend to upgrade it once the final =
spec is ready, but I need to ship Coldcard.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Cheers,</div><br class=3D""><div =
class=3D"">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;">=E2=84=9D.<br class=3D""><br =
class=3D"">Rodolfo Novak &nbsp;|| &nbsp;Founder, Coinkite =
&nbsp;||&nbsp;&nbsp;twitter @nvk &nbsp;|| &nbsp;GPG: B444CDDA</div>
</div>
<br class=3D""><div style=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 27, 2018, at 13:55, Achow101 via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">Hi,=E2=80=8B<br class=3D""><br class=3D"">On June 26, 2018 =
11:09 PM, William Casarin &lt;<a href=3D"mailto:jb55@jb55.com" =
class=3D"">jb55@jb55.com</a>&gt; wrote:<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">=E2=80=8B=E2=80=8B<br =
class=3D""><br class=3D"">Hey Andrew,<br class=3D""><br class=3D"">If =
I'm reading the spec right: the way it is designed right now, you<br =
class=3D""><br class=3D"">could create hundreds of thousands of zero =
bytes in the input or output<br class=3D""><br class=3D"">key-value =
arrays. As far as I can tell this would be considered valid,<br =
class=3D""><br class=3D"">as it is simply a large array of empty =
dictionaries. Is this right? I'm<br class=3D""><br class=3D"">worried =
about buffer overflows in cases where someone sends a large blob<br =
class=3D""><br class=3D"">of zeros to an unsuspecting implementation.<br =
class=3D""></blockquote><br class=3D"">No, that is incorrect. That whole =
paragraph is actually outdated, it was intended<br class=3D"">for the =
possibility of adding output maps, which we have already done. I have =
<br class=3D"">removed it from the BIP.<br class=3D""><br =
class=3D"">However, it is possible for a PSBT to contain very large =
unknown key-value pairs <br class=3D"">which could potentially cause a =
problem. But I do not think that large PSBTs should <br class=3D"">really =
be a problem as they are really something that the user has to enter =
rather <br class=3D"">than something received remotely without user =
interaction.<br class=3D""><br class=3D""><br class=3D""><br class=3D"">On=
 June 27, 2018 6:39 AM, Andrea via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">=E2=80=8B=E2=
=80=8B<br class=3D""><br class=3D"">Hi William, Andrew, list,<br =
class=3D""><br class=3D"">As noted by William there are some types =
missing in the global-types definition, because the number of each map =
for I/O must be known to the parser in order to use the correct =
definitions for the types. At the moment a parser reading a key-value =
record does not know whether it should read it as per-input type or =
per-output, a way to address this is to declare in advance the number of =
maps and ensure they are ordered (inputs first). If you haven't already =
worked out some types for that i propose using:<br class=3D""><br =
class=3D""></blockquote><br class=3D"">Parsers actually do know because =
that information is present in the unsigned transaction <br class=3D"">at =
the beginning of each PSBT. Since each input and output must be =
accounted for,<br class=3D"">a parser can just parse the unsigned =
transaction and from there it can know how<br class=3D"">many inputs and =
outputs to expect. If it sees more or less, it should throw an error<br =
class=3D"">as the transaction is invalid.<br class=3D""><br class=3D"">Of =
course this implies that implementations will need to parse the unsigned =
transaction,<br class=3D"">but not all actually need to. Combiners do =
not need to, they just need to merge the<br class=3D"">maps together and =
follow the key uniqueness rule. They don't really need to know<br =
class=3D"">or care about the number of inputs and outputs, just that the =
PSBTs being merged<br class=3D"">share the same unsigned transaction and =
have the same number of maps.<br class=3D""><br class=3D"">Other roles =
need to understand the unsigned transaction anyways, so they still =
need<br class=3D"">to parse it thus this isn't really a problem for =
those roles.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D""> &nbsp;&nbsp;&nbsp;On another note I think we =
can set a hard limit on the size of the PSBT, currently is 'legal' to =
produce a very large PSBT with an excessive number of Inputs and =
Outputs. By excessive I mean that even in the best case scenario (using =
the smallest possible scriptPubKey as in P2WPKH) it is possible to =
create a PSBT that would certainly create an invalid transaction =
(because of its size) when finalized. I haven't found anything related =
to this in the previous discussions, please ignore this if it was =
already proposed/discussed.<br class=3D""><br class=3D""></blockquote><br =
class=3D"">I don't think such a limitation is practical or useful. A =
transaction can currently have, at most,<br class=3D"">~24000 inputs and =
~111000 outputs (+/- a few hundred) which is well beyond any useful =
limit.<br class=3D"">Additionally, such limits may not be as extensible =
for future work. It is hard to determine what<br class=3D"">is a =
reasonable limit on transaction size, and I don't think it is useful to =
have a limit. At worst<br class=3D"">we would simply create an invalid =
transaction if it were too large.<br class=3D""><br class=3D""><br =
class=3D"">Andrew<br class=3D""><br class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_4ACC3DF0-E3FE-47C3-B859-F0B92AD67D34--