summaryrefslogtreecommitdiff
path: root/62/9d4d92b0e762e48929712a3fbbfbe79eb03919
blob: 83ad1b11a34be9abcbc35ba93ba7906cfcae5071 (plain)
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
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EAB2C45E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 20:55:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 72D3D1DB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 20:55:58 +0000 (UTC)
Received: by igbij6 with SMTP id ij6so92184019igb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 13:55:57 -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=emXbbGpZ3rIKEKi08HZqYhJ8+PAmgV5+FNjyImPCHxg=;
	b=jp0ebZx9ktLKn/ow4Plm5s+EwhuyS7y0DoJWgTrfcn0DSPj0Uz2zHZd/YEb+eapwgv
	SmFVBMloB15YJ5W5kmtQFqDl/srWNX7vdn7gytv7u/6RG4Pqj4/81aQzLHCiBJDA7smW
	Xx70io/F1gKzsyeR1rTPejCJLnzZxZ3twryRThlR5EdCLpPo323sdpdFdVNYIWnQxrwV
	GC36shG+RbiwU4BHCtO4BFnY4r6VtvVqiB2/t4m55QruSogg9ZesbzzS0dpb0vtYcU8v
	mVWFUwL8o9xQLk2N4ZFYivwxBcQNctYsgGcIZmDJvDroBSb0scyBacy/QOVe43ba+cGE
	e0wg==
MIME-Version: 1.0
X-Received: by 10.50.39.114 with SMTP id o18mr16994056igk.75.1437425757912;
	Mon, 20 Jul 2015 13:55:57 -0700 (PDT)
Received: by 10.107.48.212 with HTTP; Mon, 20 Jul 2015 13:55:57 -0700 (PDT)
In-Reply-To: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
References: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
Date: Mon, 20 Jul 2015 20:55:57 +0000
Message-ID: <CAAS2fgRBa47ye-ouV2jDe16MJFCKxYh0zF0Jw4BTwzpXVKgwOg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
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
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: Mon, 20 Jul 2015 20:55:59 -0000

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.

The cost of the indirection is forclosing future applications which
involve larger signatures but have no quadratic component and are thus
fast to verify-- or requring yet another hard fork to remove the
limit, or a kludgy soft fork that splits the same data across two
"transactions" which get processed as a unit... all would be
unfortunate.

Alternative 1 sounds more attractive to be for this reason as it's more direct.