<p>This is a a known shortcoming. The SPV protocol does not protect against omission attacks.</p>

<p>An SPV wallet can request a proof that a given tx is present in a given block, and that a given block is part of a given chain. However, it is not possible to prove that the node isn't omitting a transaction the wallet would like to know about without providing the entire block data for each block, at which point you are essentially a full node.</p>

<p>Wallets avoid this by connecting to multiple nodes - as long as there is one honest node in that connection pool, the wallet will receive up to date information.</p>

CC BY-SA 4.0
2019-12-28T16:39:26.467Z
2019-12-28T16:39:26.467Z
Raghav Sood
<p>This isn't unique to SPV nodes but can affect any node. The simple fact is that Bitcoin relies on up-to-date information about blocks in order for you to make meaningful decisions about the finality of a transaction. No kind of UTXO commitment could fix this because you might not receive the most up-to-date UTXO commitment.</p>

<p>Whether <code>y</code> has had an attempted spend is not something of importance. What you need to know is whether <code>y</code> has been <em>confirmed spent</em>, meaning, has been included in a block, and some amount of proof-of-work has been done to limit the possibility that this could be undone by a minority of network participants.</p>

<p>You need to listen for new information to get these confirmations. If you are selling goods or services for Bitcoin, then you <em>need</em> to have some N > 0 confirmations before you part with any goods because there exists the possibility that <code>y</code> could be double-spent, but this possibility declines rapidly with each new confirmation.</p>

<p>To make sure that you aren't a victim of fraud, you should get information from multiple distinct sources to ensure that you are not subject to an <em>eclipse attack</em>, where one party, or a group of parties colluding deliberately provide you false or incomplete information in attempt to defraud you.</p>

CC BY-SA 4.0
2019-12-28T15:53:33.983Z
2019-12-28T15:53:33.983Z
Mark H
<p>I am wondering how SPV handles the following scenario:</p>

<ol>
<li>A transaction has been confirmed by some block <code>X</code>, and funds address <code>y</code>.</li>
<li>At some later block, the transaction's output are spent again</li>
<li>SPV node queries the balances of <code>y</code>, the full node peer returns the answer along with the merkle proof for block <code>X</code>.</li>
<li>But.. the answer doesn't give you the most up to date response, because <code>y</code> funds were depleted in a more recent block...</li>
</ol>

<p>I know some ideas like UTXO commitments were around but I am not sure that they were ever merged into bitcoin.</p>

<p>So, was this problem ever solved? Or maybe no one tended to it because it was concluded to not be so bad?</p>

<spv>
Passing incomplete information to an SPV node
whomaniac
# Passing incomplete information to an SPV node

(Asked by: username_0 on 2019-12-28)

I am wondering how SPV handles the following scenario:

1. A transaction has been confirmed by some block `X`, and funds address `y`.
2. At some later block, the transaction's output are spent again
3. SPV node queries the balances of `y`, the full node peer returns the answer along with the merkle proof for block `X`.
4. But.. the answer doesn't give you the most up to date response, because `y` funds were depleted in a more recent block...

I know some ideas like UTXO commitments were around but I am not sure that they were ever merged into bitcoin.

So, was this problem ever solved? Or maybe no one tended to it because it was concluded to not be so bad?

**Tags:** spv


---

## 2 answers

### Answer by username_1 on 2019-12-28. Score: 2 | Accepted answer

This is a a known shortcoming. The SPV protocol does not protect against omission attacks.

An SPV wallet can request a proof that a given tx is present in a given block, and that a given block is part of a given chain. However, it is not possible to prove that the node isn't omitting a transaction the wallet would like to know about without providing the entire block data for each block, at which point you are essentially a full node.

Wallets avoid this by connecting to multiple nodes - as long as there is one honest node in that connection pool, the wallet will receive up to date information.


---

### Answer by username_2 on 2019-12-28. Score: 0

This isn't unique to SPV nodes but can affect any node. The simple fact is that Bitcoin relies on up-to-date information about blocks in order for you to make meaningful decisions about the finality of a transaction. No kind of UTXO commitment could fix this because you might not receive the most up-to-date UTXO commitment.

Whether `y` has had an attempted spend is not something of importance. What you need to know is whether `y` has been *confirmed spent*, meaning, has been included in a block, and some amount of proof-of-work has been done to limit the possibility that this could be undone by a minority of network participants.

You need to listen for new information to get these confirmations. If you are selling goods or services for Bitcoin, then you *need* to have some N > 0 confirmations before you part with any goods because there exists the possibility that `y` could be double-spent, but this possibility declines rapidly with each new confirmation.

To make sure that you aren't a victim of fraud, you should get information from multiple distinct sources to ensure that you are not subject to an *eclipse attack*, where one party, or a group of parties colluding deliberately provide you false or incomplete information in attempt to defraud you.


---

