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
|
Return-Path: <achow101-lists@achow101.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A5CACE1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jun 2018 17:56:12 +0000 (UTC)
X-Greylist: from 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 C8D5317E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jun 2018 17:56:09 +0000 (UTC)
Date: Wed, 27 Jun 2018 13:55:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail; t=1530122167;
bh=Vgv8iOD6+y9Hw1K9H1PgsKRkHpWK63QJX7goLXQTpFE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=midLaf1hQF9U5yzB4JbXKlYqK5ls2/Ftf6Z688H3w/A9Yo+AzgqyvJOcWADLrkAym
WeOceaoFr0GQMb6yi/9pDrQHL6hNPUI9kE5itCtHoFMXeFgNSsubQRwIxgdoGxo0m3
GrqVeccW0w7Pr6pYJR+/PtpLQwxdi76o2a1Vtvwo=
To: William Casarin <jb55@jb55.com>
From: Achow101 <achow101-lists@achow101.com>
Reply-To: Achow101 <achow101-lists@achow101.com>
Message-ID: <0BT4A0BFbcfUM9xlYjS-7Cy1zpaI1J9qsIpWH_xgv2ZLhcmxb4Es5KlpMJCvHVEu8BDbBweZ92RHnES5HxDMulRhJkYSZAPi-CgXQ3uwkfY=@achow101.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: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==: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, 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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 17:56:12 -0000
Hi,=E2=80=8B
On June 26, 2018 11:09 PM, William Casarin <jb55@jb55.com> 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.
No, that is incorrect. That whole paragraph is actually outdated, it was in=
tended
for the possibility of adding output maps, which we have already done. I ha=
ve=20
removed it from the BIP.
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 PSBT=
s 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.
On June 27, 2018 6:39 AM, Andrea via bitcoin-dev <bitcoin-dev@lists.linuxfo=
undation.org> wrote:
> =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 defi=
nition, 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 pars=
er reading a key-value record does not know whether it should read it as pe=
r-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
Parsers actually do know because that information is present in the unsigne=
d transaction=20
at the beginning of each PSBT. Since each input and output must be accounte=
d 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.
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 m=
erge 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 m=
erged
share the same unsigned transaction and have the same number of maps.
Other roles need to understand the unsigned transaction anyways, so they st=
ill need
to parse it thus this isn't really a problem for those roles.
> =20
> On another note I think we can set a hard limit on the size of the PS=
BT, currently is 'legal' to produce a very large PSBT with an excessive num=
ber of Inputs and Outputs. By excessive I mean that even in the best case s=
cenario (using the smallest possible scriptPubKey as in P2WPKH) it is possi=
ble to create a PSBT that would certainly create an invalid transaction (be=
cause 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
I don't think such a limitation is practical or useful. A transaction can c=
urrently 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 h=
ard to determine what
is a reasonable limit on transaction size, and I don't think it is useful t=
o have a limit. At worst
we would simply create an invalid transaction if it were too large.
Andrew
|
