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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BE86E282
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 18:09:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 101AA1B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 18:09:21 +0000 (UTC)
Received: by lbbqi7 with SMTP id qi7so40956841lbb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 11:09: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:date:message-id:subject:from:to
:cc:content-type;
bh=GbO2zG/5ZXAXmUfldTBrXr7MlR+4IJmddMlJjKtneTY=;
b=ZpvmHIcKvuCyidBrrv2BDAMxSij7t89GhzxnbVbZF6oEccZygMpgsDqlwDAQc8jVJX
i1LtmGlLeqS4EqiAdUWAmFHnYpa8rpbA1Bdz31gjn2aUOCfwk53LCpzOntws3VnnCIuJ
7Q/0D51RLg5GldnOCC4h1/CNzFRJZAA3yTV2JwMRq+S1vidUIWT8S0rFnpxQBgS+9FH3
3pPK8rodUs0DollV3C8SIOisc0h7IMYuZhxuvA7zna0kQWEzYrvhmkqOhKbGnocuv+Yu
7y+6dGMCNqkRaICNx/LsyNCvmIeCOV22dkKwb3hPVRWesJ2h6liPiLjIxP1OhsAoI9wX
53fQ==
MIME-Version: 1.0
X-Received: by 10.112.55.70 with SMTP id q6mr30032576lbp.99.1437502159491;
Tue, 21 Jul 2015 11:09:19 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 21 Jul 2015 11:09:19 -0700 (PDT)
In-Reply-To: <CAAS2fgRBa47ye-ouV2jDe16MJFCKxYh0zF0Jw4BTwzpXVKgwOg@mail.gmail.com>
References: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
<CAAS2fgRBa47ye-ouV2jDe16MJFCKxYh0zF0Jw4BTwzpXVKgwOg@mail.gmail.com>
Date: Tue, 21 Jul 2015 14:09:19 -0400
Message-ID: <CABsx9T2ZX3iuCN4g6Yh0k8R7Ad0yx-yfx1f2XhCEPtz-vt2xsw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133d13c949aa4051b668d59
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:09:21 -0000
--001a1133d13c949aa4051b668d59
Content-Type: text/plain; charset=UTF-8
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
--001a1133d13c949aa4051b668d59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, 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> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mon, J=
ul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.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>This seems like a fairly indirect approach. The resource being watch=
ed<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></blo=
ckquote><div><br></div><div>Yes.=C2=A0 The tradeoff is implementation compl=
exity: it is trivial to check transaction size,</div><div>not as trivial to=
count signature operations, because number-of-bytes-in-transaction</div><d=
iv>doesn't require any context.</div><div><br></div><div>But I would RE=
ALLY hate myself if in ten years a future version of me was struggling to</=
div><div>get consensus to move away from some stupid 100,000 byte transacti=
on 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 to go. A=
nd if that is being changed,</div><div>might as well accurately count exact=
ly how many sigops a transaction actually</div><div>requires to be validate=
d...</div></div><div><br></div>-- <br><div class=3D"gmail_signature">--<br>=
Gavin Andresen<br></div><div class=3D"gmail_signature"><br></div>
</div></div>
--001a1133d13c949aa4051b668d59--
|
