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
|
Return-Path: <a.raspitzu@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 626F2BC6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jun 2018 13:39:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 737F1619
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jun 2018 13:39:07 +0000 (UTC)
Date: Wed, 27 Jun 2018 09:39:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1530106744;
bh=pSGeimGqM9G79v5uMprhJuzoT7uXDSbiOoQXSbpYAy0=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=rjBIGkfY6b591popCr4vNqKWIq57Y1txVb0VdO/HpaDXrZx9W2C/9Ax/soRrWvlOW
sUFwbhujQ0I0fvB7G518v6Xf5P7Nvqo7DmA4446AXKHIz7vSvQ1SXIs1gkifpeLEAQ
N5LMiiMpde+Op9hq2Zp0e5Y3/ILwraTZ/+2wv91U=
To: William Casarin <jb55@jb55.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrea <a.raspitzu@protonmail.com>
Reply-To: Andrea <a.raspitzu@protonmail.com>
Message-ID: <SBu1mxevY6vaDj8jipOqQacRY02PPUHcsq30eXRaC5jwE5JKCfNuM9RNKVSQvQfup1fBfWEcANimrKbdQFFbdg4bmb2yvv7UVdLRHyuMIyc=@protonmail.com>
In-Reply-To: <87k1qk7oca.fsf@jb55.com>
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>
Feedback-ID: x-YXDi3m_TiFBHTDMZypFbA_HjfCQuhNiwHDBR0xli2NzJKdIoqs25GtJLT5wHvl0eyVBeRQs8LMD0l_SOtUrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Wed, 27 Jun 2018 13:42:06 +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: Wed, 27 Jun 2018 13:39:08 -0000
Hi William, Andrew, list,
As noted by William there are some types missing in the global-types defini=
tion, 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 th=
e number of maps and ensure they are ordered (inputs first). If you haven't=
already worked out some types for that i propose using:
Number of inputs
- key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER =3D 0x01 =20
- value: Varint=20
Number of outputs
- key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER =3D 0x02
- value: Varint
On another note I think we can set a hard limit on the size of the PSBT, cu=
rrently 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 scenari=
o (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 th=
e previous discussions, please ignore this if it was already proposed/discu=
ssed.
Cheers, Andrea.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On June 27, 2018 8:09 AM, William Casarin via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> =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
> Also, the extensibility section reads:
>=20
> > Additional key-value maps with different types for the key-value pairs
> >=20
> > can be added on to the end of the format.
>=20
> "different types for the key-value pairs", is this referring to new
>=20
> types beyond the current global, input and output types?
>=20
> > The number of each map that follows must be specified in the globals
> >=20
> > section
>=20
> Is this out of date? Since there is only one type in the global section
>=20
> now (tx).
>=20
> > so that parsers will know when to use different definitions of the
> >=20
> > data types
>=20
> I'm not sure what this means.
>=20
> Thanks!
>=20
> Will
>=20
>=20
> ------------------------------------------------
>=20
> https://jb55.com
>=20
> bitcoin-dev mailing list
>=20
> bitcoin-dev@lists.linuxfoundation.org
>=20
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
