public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Joseph Poon <joseph@lightning•network>
To: Chris Pacia <ctpacia@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Incentives to run full nodes
Date: Mon, 17 Aug 2015 17:20:02 -0700	[thread overview]
Message-ID: <20150818002002.GA3048@lightning.network> (raw)
In-Reply-To: <CAB+qUq79BgiTGFS1yLxxogg8907jCUtNDmBhnikLWc1fqofNyg@mail.gmail.com>

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


  reply	other threads:[~2015-08-18  0:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-15 17:43 [bitcoin-dev] Bitcoin XT Fork Satoshi Nakamoto
2015-08-15 19:08 ` Laszlo Hanyecz
2015-08-15 19:10 ` jl2012
2015-08-17 11:40 ` Oliver Egginger
2015-08-17 11:44   ` Jorge Timón
2015-08-17 11:51     ` Oliver Egginger
2015-08-17 16:32       ` Jorge Timón
2015-08-17 17:01         ` Oliver Egginger
2015-08-17 17:15           ` Jorge Timón
2015-08-17 17:30             ` Btc Drak
2015-08-17 17:18       ` Gregory Maxwell
2015-08-17 19:14         ` Peter Todd
2015-08-17 17:28   ` Jeff Garzik
2015-08-17 19:03   ` Warren Togami Jr.
2015-08-17 20:37     ` Oliver Egginger
2015-08-18  5:16       ` Gregory Maxwell
2015-08-18  9:15       ` Warren Togami Jr.
2015-08-18 11:52         ` Micha Bailey
2015-08-18 18:57         ` Oliver Egginger
2015-08-18 20:59           ` Anon Moto
2015-08-19  1:03             ` Sergio Demian Lerner
2015-08-17 19:02 ` Anon Moto
2015-08-17 19:40   ` Marcel Jamin
2015-08-17 19:16 ` Hector Chu
2015-08-17 19:28   ` Gregory Maxwell
2015-08-17 19:39     ` Jorge Timón
2015-08-17 21:29 ` [bitcoin-dev] Incentives to run full nodes Peter Todd
2015-08-17 21:44   ` Chris Pacia
2015-08-18  0:20     ` Joseph Poon [this message]
2015-08-19  5:21     ` odinn
2015-10-04  6:46       ` odinn
2015-10-04  6:59         ` odinn
2015-08-19  2:54 ` [bitcoin-dev] Bitcoin XT Fork odinn
2015-08-19  2:59   ` Angel Leon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150818002002.GA3048@lightning.network \
    --to=joseph@lightning$(echo .)network \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=ctpacia@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox