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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 84EC142A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 19:43:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
[209.85.220.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A226101
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 19:43:52 +0000 (UTC)
Received: by qkdv3 with SMTP id v3so119179146qkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 12:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=n/RQ4pzefRTx/oxPj8jRKSE1XnHJ39F1L1ydBRuTUbE=;
b=EKOU+h6mXFmhAxxHDQoc9Ybqp/XspWc1SVLepV4EtD04T5DJRHULk6zJ5LCCaqIo+X
/bAQ53xlbC/uJHjuZj1Dlt91MwgE5muGPScGJv7wc8IdAZGLIp2s1/GHI5O8H6IcdjzH
IA8+cVYhaMynCC9zMIKABUn7zixc2HqGPskrcMkOMXnIWvebuRBEP8xi78XSnMde8OPB
x4oDsGVhd1cQMZseAhsfxYkeiYbi2lGWWLbn2afkjfuXRsN2epuBx6a1yvRqo7Njx1Vu
xd/4HZSLsHCQkBr3gxmwTJwFtdUPCYLy4f+ahh0b9UPYWlX5Pa135KSUMWyOA5d0Wpef
pxPw==
MIME-Version: 1.0
X-Received: by 10.140.84.137 with SMTP id l9mr49308981qgd.94.1437421431317;
Mon, 20 Jul 2015 12:43:51 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Mon, 20 Jul 2015 12:43:51 -0700 (PDT)
In-Reply-To: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
References: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
Date: Mon, 20 Jul 2015 20:43:51 +0100
Message-ID: <CAE-z3OVWYaoGc+_=xQN1=CV=LUHdLEtuds6FZCXdktowfCaLYA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c1192ace6a8d051b53c156
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] For discussion: limit transaction size to
mitigate CVE-2013-2292
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Mon, 20 Jul 2015 19:43:52 -0000
--001a11c1192ace6a8d051b53c156
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 20, 2015 at 8:10 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> After deployment, the maximum serialized size of a transaction allowed
> in a block shall be 100,000 bytes.
>
This could render transactions with a locktime in the future as unspendable.
It is pretty low probability that someone has created a >100kB locked
transaction though.
It violates the principle that no fork should render someone's coins
unspendable.
At the cost of weakening the protection, the rule could be made to only
apply to version 2 transactions.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
As time passes more and more of the UTXO set will be from version two
transactions. To launch the attack, the attacker needs an historical UTXO
entry.
Standard software would create version two transactions even if all inputs
were version one.
The rule could be applied to all transactions most of the time, and have
daily blocks that allow legacy transactions.
This rule shall apply to version 1 transactions too unless the block
height is
a multiple of 100.
At the risk of encouraging feature creep, if the transaction size is being
limited, it would be useful to also limit the size of all its inputs.
This helps with fraud proofs and offline signing.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
The maximum of the total serialized size of a version two transaction
and all
of its parents allowed in a block shall be 200,000 bytes.
--001a11c1192ace6a8d051b53c156
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Jul 20, 2015 at 8:10 PM, Gavin Andresen via bitcoi=
n-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></=
span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>After de=
ployment, the maximum serialized size of a transaction allowed</div><div>in=
a block shall be 100,000 bytes.</div></div></blockquote><div><br></div><di=
v>This could render transactions with a locktime in the future as unspendab=
le.<br><br></div><div>It is pretty low probability that someone has created=
a >100kB locked transaction though.<br><br></div><div>It violates the p=
rinciple that no fork should render someone's coins unspendable.<br><br=
></div><div>At the cost of weakening the protection, the rule could be made=
to only apply to version 2 transactions.<br></div><div><br></div><div><b>S=
pecification<br></b></div><div><br>=C2=A0=C2=A0=C2=A0 The transaction versi=
on is increased to version two.<br><br></div><div>=C2=A0=C2=A0=C2=A0 All co=
inbase transactions must be version two or higher.<br></div><div><br>=C2=A0=
=C2=A0=C2=A0 If any of its parent transactions are version two or higher<br=
>=C2=A0=C2=A0=C2=A0 then the transaction must be version two or higher.<br>=
</div><div><br>=C2=A0=C2=A0=C2=A0 The maximum serialized size of a version =
two transactions allowed in <br>=C2=A0=C2=A0=C2=A0 a block is 100,000 bytes=
.<br></div><div></div><div><br><br></div><div>As time passes more and more =
of the UTXO set will be from version two transactions.=C2=A0 To launch the =
attack, the attacker needs an historical UTXO entry.<br><br></div><div>Stan=
dard software would create version two transactions even if all inputs were=
version one.<br></div><div></div><br></div><div class=3D"gmail_quote">The =
rule could be applied to all transactions most of the time, and have daily =
blocks that allow legacy transactions.<br><br><div>=C2=A0=C2=A0=C2=A0 This =
rule shall apply to version 1 transactions too unless the block height is<b=
r></div><div>=C2=A0=C2=A0=C2=A0 a multiple of 100.<br></div><br></div><div =
class=3D"gmail_quote"><div>At the risk of encouraging feature creep, if the=
transaction size is being limited, it would be useful to also limit the si=
ze of all its inputs.<br><br></div><div>This helps with fraud proofs and of=
fline signing.<br></div><div><br></div><div><b>Specification<br></b><br>=C2=
=A0=C2=A0=C2=A0 The transaction version is increased to version two.<br><br=
><div>=C2=A0 =C2=A0 All coinbase transactions must be version two or higher=
.<br><br>=C2=A0=C2=A0=C2=A0 If any of its parent transactions are version t=
wo or higher<br>=C2=A0=C2=A0=C2=A0 then the transaction must be version two=
or higher.<br></div><br>=C2=A0=C2=A0=C2=A0 The maximum serialized size of =
a version two transactions allowed in <br>=C2=A0=C2=A0=C2=A0 a block is 100=
,000 bytes.<br><br><div>=C2=A0=C2=A0=C2=A0 The maximum of the total seriali=
zed size of a version two transaction and all <br>=C2=A0=C2=A0=C2=A0 of its=
parents allowed in a block shall be 200,000 bytes.<br><br></div></div></di=
v></div></div>
--001a11c1192ace6a8d051b53c156--
|
