<blockquote>
  <p>But, it seems that most discussions focused on double-spending (like broadcasting two or more conflicting-but-valid transactions, or Finney attack), instead of the validity of the transaction.</p>
</blockquote>

<p>That is because a transaction being 'valid' is somewhat inconsequential when considering whether or not a payment has been made. What does matter is that the transaction is confirmed in the blockchain record. Even a single confirmation may not be enough, <a href="https://bitcoin.stackexchange.com/questions/1170/why-is-6-the-number-of-confirms-that-is-considered-secure">and so waiting for several confirmations</a> will mean a higher probability of a permanently confirmed payment. </p>

<p>Obviously, an invalid transaction is no good, but there are also no guarantees that a valid, but unconfirmed transaction will eventually be included in the blockchain. </p>

<p>This isn't to say that you should never, ever accept a 0-conf payment. Perhaps you run a service where the risk of a double-spent payment is somewhat inconsequential to the way you make money. If a customer misbehaves, you cut them off, and thats the end of it. No major loss on your part. </p>

<p>But if your job is to sell <em>very</em> expensive rocket ships, you should probably wait for several confirmations before you allow your customer to blast off, in case they maliciously double-spend the payment to you, and get a sweet new rocket ship free of charge. </p>

<blockquote>
  <p>Does a lightweight wallet have the same security as a full node under this 0-conf scenario?</p>
</blockquote>

<p>I think the reason that the attacks you listed are often mentioned is because the more important point is that <strong>'0-conf' transactions are inherently insecure</strong>, and those are the sorts of attacks that are the reason for this.  It is of lesser importance whether your wallet/node can confirm just the validity of the transaction or not. </p>

<p>But to answer your question more directly, I think a lightweight wallet will have a difficult time figuring out whether a transaction is valid or not, without just validating all of the data itself locally anyways. </p>

CC BY-SA 4.0
2019-01-15T06:28:25.290Z
2019-01-15T06:43:14.373Z
2019-01-15T06:43:14.373Z
chytrik
<p>Zero-confirmation transactions can easily be double-spent by another signed transaction spending the same UTXO, but with an arbitrarily higher fee, thereby achieving a higher likelihood of being mined first, rendering the original transaction invalid.</p>

<p>A merchant still needs a full-node to accept new transactions to the mem-pool, because it needs to validate each new transaction it sees.</p>

<p>A lightweight wallet does not have the same security as a full-node, because it relies on verifying the accumulated POW, and not the actual transaction validity. The assumption is that the chain with the most accumulated POW must be valid.</p>

CC BY-SA 4.0
2019-01-14T14:39:23.980Z
memo-pool - typo?
Chris Chen
CC BY-SA 4.0
2019-01-14T14:42:53.617Z
A 0-conf transaction doesn't yet have any accumulated PoW to verify. So, I wonder how could a lightweight wallet validate 0-conf transaction?
Chris Chen
CC BY-SA 4.0
2019-01-14T14:44:09.720Z
It cant. It can only validate the inclusion of a confirmed tx in a block header (with a merkle proof) from a fullnode.
James C.
CC BY-SA 4.0
2019-01-14T14:53:15.973Z
But I see the Electrum wallet can distinguish whether a 0-conf has an unconfirmed parent or not - obviously it's doing some validation.
Chris Chen
CC BY-SA 4.0
2019-01-14T15:00:44.877Z
I am not sure if electrum always requires a full node, but the confirmation of the parent can also be provided with a merkle proof in a light client
James C.
CC BY-SA 4.0
2019-01-14T14:07:45.963Z
2019-01-14T14:39:46.193Z
2019-01-14T14:39:46.193Z
James C.
<p>I found that a lot of people are interested about security of 0-confirmation payments. But, it seems that most discussions focused on double-spending (like broadcasting two or more conflicting-but-valid transactions, or Finney attack), instead of the validity of the transaction. Does a merchant accepting 0-conf have to run his own full node, or trust someone else (like a public block explorer service), to validate the transaction? Does a lightweight wallet have the same security as a full node under this 0-conf scenario?</p>

<wallet><security><spv><zero-confirmation>
How could a lightweight wallet determine the validity of 0-conf transaction?
Chris Chen
# How could a lightweight wallet determine the validity of 0-conf transaction?

(Asked by: username_0 on 2019-01-14)

I found that a lot of people are interested about security of 0-confirmation payments. But, it seems that most discussions focused on double-spending (like broadcasting two or more conflicting-but-valid transactions, or Finney attack), instead of the validity of the transaction. Does a merchant accepting 0-conf have to run his own full node, or trust someone else (like a public block explorer service), to validate the transaction? Does a lightweight wallet have the same security as a full node under this 0-conf scenario?

**Tags:** wallet, security, spv, zero-confirmation


---

## 2 answers

### Answer by username_1 on 2019-01-15. Score: 1

> But, it seems that most discussions focused on double-spending (like broadcasting two or more conflicting-but-valid transactions, or Finney attack), instead of the validity of the transaction.

That is because a transaction being 'valid' is somewhat inconsequential when considering whether or not a payment has been made. What does matter is that the transaction is confirmed in the blockchain record. Even a single confirmation may not be enough, [and so waiting for several confirmations](https://bitcoin.stackexchange.com/questions/1170/why-is-6-the-number-of-confirms-that-is-considered-secure) will mean a higher probability of a permanently confirmed payment.

Obviously, an invalid transaction is no good, but there are also no guarantees that a valid, but unconfirmed transaction will eventually be included in the blockchain.

This isn't to say that you should never, ever accept a 0-conf payment. Perhaps you run a service where the risk of a double-spent payment is somewhat inconsequential to the way you make money. If a customer misbehaves, you cut them off, and thats the end of it. No major loss on your part.

But if your job is to sell *very* expensive rocket ships, you should probably wait for several confirmations before you allow your customer to blast off, in case they maliciously double-spend the payment to you, and get a sweet new rocket ship free of charge.

> Does a lightweight wallet have the same security as a full node under this 0-conf scenario?

I think the reason that the attacks you listed are often mentioned is because the more important point is that **'0-conf' transactions are inherently insecure**, and those are the sorts of attacks that are the reason for this. It is of lesser importance whether your wallet/node can confirm just the validity of the transaction or not.

But to answer your question more directly, I think a lightweight wallet will have a difficult time figuring out whether a transaction is valid or not, without just validating all of the data itself locally anyways.


---

### Answer by username_2 on 2019-01-14. Score: 1

Zero-confirmation transactions can easily be double-spent by another signed transaction spending the same UTXO, but with an arbitrarily higher fee, thereby achieving a higher likelihood of being mined first, rendering the original transaction invalid.

A merchant still needs a full-node to accept new transactions to the mem-pool, because it needs to validate each new transaction it sees.

A lightweight wallet does not have the same security as a full-node, because it relies on verifying the accumulated POW, and not the actual transaction validity. The assumption is that the chain with the most accumulated POW must be valid.

> **Comments:**
> **username_0**: memo-pool - typo?  
> **username_0**: A 0-conf transaction doesn't yet have any accumulated PoW to verify. So, I wonder how could a lightweight wallet validate 0-conf transaction?  
> **username_2**: It cant. It can only validate the inclusion of a confirmed tx in a block header (with a merkle proof) from a fullnode.  
> **username_0**: But I see the Electrum wallet can distinguish whether a 0-conf has an unconfirmed parent or not - obviously it's doing some validation.  
> **username_2**: I am not sure if electrum always requires a full node, but the confirmation of the parent can also be provided with a merkle proof in a light client  

---

