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
|
Return-Path: <joseph@lightning.network>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 80439895
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 00:20:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
[209.85.220.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE27D184
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 00:20:06 +0000 (UTC)
Received: by pabyb7 with SMTP id yb7so119007153pab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 17:20:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lightning.network; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to;
bh=3sma/77fTZrtiAs+dHj3kJP7akZW8P7vQMy9tzFONiM=;
b=G6QUF5LG22YPzx+hhVY8YBdaUogcFrN/zMveCiXPSj+Le/DRnmuivceH4IG8qhcUOr
iJUM5RRNTlh7cHYk4FESPzX8E9BIJy7YX8bkpyTDxxHgEbxjm8xCi76UoPdkAaNkh6lD
EstYroOV6i8kruydzHUSIdW7CafLKI+PdB7AA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to;
bh=3sma/77fTZrtiAs+dHj3kJP7akZW8P7vQMy9tzFONiM=;
b=mlvNQYFdiqy7/sE+l8u66b4s8VKthPGMgLgr7uoV5wKtSPfulawbu66xgOZmDL9Nwf
EP9gvFGe5rzD/Yq5QpMJwDjKcMONKacJiurzGoTdDHPRXjs4IWraU2UqKL6gGTd5eNXi
q0TPJoLGtai0RjUyEcHRDwNU8kzYk3/SuB64tafT624lX50RmeNeKxTFCUWsibX+YBMw
ktlUotRuWbm+BcnBoE+6Qc3IkWBCwN0p45KT+/BzHg/NHjTTtCsagV7B4ekV48QDTSmm
KJH+QTkgWWbgJ/gBnI43wboF6wXigcAr6tANZjg+RZclFjtKs29srM6wKzoSVPzetcmi
n2kA==
X-Gm-Message-State: ALoCoQlaXOBMXSiehv9weyAd60YUbNxMvN5bn/a8Bk1Y2nhvQTrRqot8rftIPoW2b1ExWqou1zK0
X-Received: by 10.68.109.97 with SMTP id hr1mr7465017pbb.110.1439857206613;
Mon, 17 Aug 2015 17:20:06 -0700 (PDT)
Received: from localhost (199-230-11-50.PUBLIC.monkeybrains.net.
[199.230.11.50]) by smtp.gmail.com with ESMTPSA id
fx4sm15866832pbb.92.2015.08.17.17.20.05
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 17 Aug 2015 17:20:06 -0700 (PDT)
Date: Mon, 17 Aug 2015 17:20:02 -0700
From: Joseph Poon <joseph@lightning.network>
To: Chris Pacia <ctpacia@gmail.com>
Message-ID: <20150818002002.GA3048@lightning.network>
References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04>
<20150817212912.GA15817@muck>
<CAB+qUq79BgiTGFS1yLxxogg8907jCUtNDmBhnikLWc1fqofNyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB+qUq79BgiTGFS1yLxxogg8907jCUtNDmBhnikLWc1fqofNyg@mail.gmail.com>
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-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Incentives to run full nodes
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, 18 Aug 2015 00:20:07 -0000
Hi Chris, I don't speak for Peter, but here's my opinion on the matter
anyway.
On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote:
> Can you explain how the spv node fails against an attacker with a
> non-trivial amount of hash power where a full node doesn't? To attack an
> spv wallet that is waiting for 6 or 10 confirmations, you would not only
> need to Sybil them but also summon a massive amount of hashing power to
> create a chain of headers (while forgoing the opportunity to mine valid
> blocks with that hash power).
>
> But could someone with that much hash power not Sybil a full node and give
> them a chain for valid blocks (but on an orphan fork)? The failure model
> doesn't seem specific to spv to me.
With SPV, it is possible to create a transaction that spends from
non-existent coins. With sufficient hashpower, you can construct an SPV
proof which sends 1,000 bitcoin to the victim. The attack is
"overloadable" in the sense that the attacker is never out of money
(they never needed to have 1,000 BTC in the first place). Whereas if the
victim is running a full node, the attacker must be signing and spending
real outputs in their control, there is a possibility in a re-org that
the victim will eventually get their money if it gets re-orged back.
On a more fundamental level, the SPV attack isn't on re-orging real/live
transactions, it's an attack on *how much money you currently have*. If
the client is using SPV, they never had the money in the first place
when attacked, irrespective of re-orgs.
It is possible to attack thousands of people at once (everyone gets
1,000 bitcoin in false transactions) with a fraction of the hashpower
(lie in wait until you get a sufficiently long chain of blocks). If you
wished to attack a full-node, it requires you orphaning a chain of valid
blocks *live*, meaning you have to send real coins in a real transaction
to the victim first. With SPV validation, you only need to construct a
chain of invalid blocks off the current blockheight *whenever*. This
means you can attack with substantially less hashpower; you don't need
51% of the hashpower to attack SPV wallets. It may be economically
unviable to attack a single victim with a full node within a very short
timeframe, but it can be economically viable to attack thousands of
victims doing SPV validation in a long timeframe.
Note I'm not arguing that SPV should be compeletely avoided, I don't
have a solid opinion on that (and some threats can definitely be
mitigated in various ways, and I certainly like/appreciate the
convenience of SPV), but the current SPV security model is definitely
weaker than running a full node (if you're handling a lot of money, you
should be running a full node), are these issues not well-known by all
in the bitcoin community?
--
Joseph Poon
|
