Joseph Poon [ARCHIVE] on Nostr: đ Original date posted:2015-08-17 đ Original message:Hi Chris, I don't speak ...
đ
Original date posted:2015-08-17
đ Original message: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
đ Original message: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