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
|
Return-Path: <jeremy.l.rubin.travel@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B80903C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 18:18:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E39D51C2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 18:18:20 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so130254724wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 11:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=gyi/h0oqgV5mCHbdQnl7t0Gc+YIQWZ02dEQSiol6Dek=;
b=S+3VjtF9TpU11Tg4J4LwwjUdhh9jG4+XV61uY5uF3Y+RkmfkbUW+RgLTqIwfSLrx53
s2fgOGE5PtXOu8rD3i2jiQVasOMZTiGYSKZb7RlQ2GQwM0S6w8copzy9aGmKZuL8yOvf
TwgWcnPkNcydcw++k9Llu4fdH4OttCOVd7fE8TmMdLzl+MEFYDy8cyUxg02B+tc4BaKw
K8P7RI6DP35haxhnZRJ05UBwsKjNI/51u9k62II2Zq7ghpktN9Y7OJY7dZ/Mg2PH33E8
KKjuimsY3ga+W4BWpBhbkvCikvzFTAlZvYvlU6Edi1Ug58pjqoecniMGIQZ0HocESFIY
PUfA==
X-Received: by 10.194.89.98 with SMTP id bn2mr74527887wjb.153.1437502699751;
Tue, 21 Jul 2015 11:18:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.229.195 with HTTP; Tue, 21 Jul 2015 11:18:00 -0700 (PDT)
In-Reply-To: <CABsx9T2ZX3iuCN4g6Yh0k8R7Ad0yx-yfx1f2XhCEPtz-vt2xsw@mail.gmail.com>
References: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
<CAAS2fgRBa47ye-ouV2jDe16MJFCKxYh0zF0Jw4BTwzpXVKgwOg@mail.gmail.com>
<CABsx9T2ZX3iuCN4g6Yh0k8R7Ad0yx-yfx1f2XhCEPtz-vt2xsw@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
Date: Wed, 22 Jul 2015 02:18:00 +0800
Message-ID: <CAJ+8mEPt1xe6dxx1+jm=sndArHXCbjEfYKNVhJw=OO1aG=CBJQ@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e010d8b24c84e86051b66ad25
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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-dev@lists.linuxfoundation.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: Tue, 21 Jul 2015 18:18:21 -0000
--089e010d8b24c84e86051b66ad25
Content-Type: text/plain; charset=UTF-8
I think it's not a horrible idea to just add a field into the transaction
metadata for N_SIG_OPS in the script_sig
It is much simpler in implementation if the concern is complexity (once a
transaction goes above N_SIG_OPS it could be considered invalid, number
computed must be equal). It wouldn't even need to be stored permanently as
it can be pruned easily and recomputed later (hashes would protect against
buggy complicated sig counting code).
Furthermore, it would differentiate a branch with different counts well.
On Wed, Jul 22, 2015 at 2:09 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Mitigate a potential CPU exhaustion denial-of-service attack by limiting
>> > the maximum size of a transaction included in a block.
>>
>> This seems like a fairly indirect approach. The resource being watched
>> for is not the size (otherwise two transactions for 200k would be
>> strictly worse than one 200k transactions) but the potential of N^2
>> costs related to repeated hashing in checksig; which this ignores.
>>
>
> Yes. The tradeoff is implementation complexity: it is trivial to check
> transaction size,
> not as trivial to count signature operations, because
> number-of-bytes-in-transaction
> doesn't require any context.
>
> But I would REALLY hate myself if in ten years a future version of me was
> struggling to
> get consensus to move away from some stupid 100,000 byte transaction size
> limit
> I imposed to mitigate a potential DoS attack.
>
> So I agree, a limit on sigops is the right way to go. And if that is being
> changed,
> might as well accurately count exactly how many sigops a transaction
> actually
> requires to be validated...
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e010d8b24c84e86051b66ad25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think it's not a horrible idea to just add a field i=
nto the transaction metadata for N_SIG_OPS in the script_sig<div><br></div>=
<div>It is much simpler in implementation if the concern is complexity (onc=
e a transaction goes above N_SIG_OPS it could be considered invalid, number=
computed must be equal). It wouldn't even need to be stored permanentl=
y as it can be pruned easily and recomputed later (hashes would protect aga=
inst buggy complicated sig counting code).</div><div><br></div><div>Further=
more, it would differentiate a branch with different counts well.</div><div=
><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Jul 22, 2015 at 2:09 AM, 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><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Mon, Jul 20=
, 2015 at 4:55 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mailto:=
gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span> wro=
te:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span><span class=3D"">On Mon,=
Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev<br></span><span cl=
ass=3D"">
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> Mitigate a potential CPU exhaustion denial-of-service attack by limiti=
ng<br>
> the maximum size of a transaction included in a block.<br>
<br>
</span></span><span class=3D"">This seems like a fairly indirect approach. =
The resource being watched<br>
for is not the size (otherwise two transactions for 200k would be<br>
strictly worse than one 200k transactions) but the potential of N^2<br>
costs related to repeated hashing in checksig; which this ignores.<br></spa=
n></blockquote><div><br></div><div>Yes.=C2=A0 The tradeoff is implementatio=
n complexity: it is trivial to check transaction size,</div><div>not as tri=
vial to count signature operations, because number-of-bytes-in-transaction<=
/div><div>doesn't require any context.</div><div><br></div><div>But I w=
ould REALLY hate myself if in ten years a future version of me was struggli=
ng to</div><div>get consensus to move away from some stupid 100,000 byte tr=
ansaction size limit</div><div>I imposed to mitigate a potential DoS attack=
.</div><div><br></div><div>So I agree, a limit on sigops is the right way t=
o go. And if that is being changed,</div><div>might as well accurately coun=
t exactly how many sigops a transaction actually</div><div>requires to be v=
alidated...</div></div><span class=3D"HOEnZb"><font color=3D"#888888"><div>=
<br></div>-- <br><div>--<br>Gavin Andresen<br></div><div><br></div>
</font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--089e010d8b24c84e86051b66ad25--
|
