<p>When receiving a payment, it is critical to know whether or not the transaction that makes that payment is a legitimate Bitcoin transaction (or not).</p>

<p>This is determined by checking if the transaction is valid according to the network's rules- and a crucial part of this is determining whether or not the transaction's inputs are valid. In order to determine the validity of the inputs, the client must have some way of knowing the current state of the network. Generally this is accomplished in two ways:</p>

<ul>
<li><strong>Full node</strong>: this is software that will independently download and validate every transaction and block, thus verifying what the current state of the network is. As such, any transaction can (and will) be checked for validity.</li>
<li><strong>Thin/Lite/SPV client</strong>: this is software that will download the longest chain of block headers, but not the entire block. The client can thus check the validity of transaction by requesting proof of the transaction's inclusion in a block from full nodes on the network, this is accomplished via the merkle root included in the block header. This method of transaction verification requires more trust (that miners are in fact creating valid blocks), so the thin-client must trust that this verification is being performed by other nodes on the network. </li>
</ul>

<p>If you are not performing verification of incoming transactions in one of these ways, then you will be easily defrauded, since you will be unable to differentiate between a valid and invalid transaction, without <strong>fully</strong> trusting someone else to supply this info to you. </p>

CC BY-SA 4.0
2019-12-19T05:30:14.797Z
That makes a lot of sense. Is it true that this lite client does not have access to the mempool?
foba
CC BY-SA 4.0
2019-12-19T06:17:18.420Z
@foba There is no 'the mempool'. Rather, each node may choose to keep a mempool (or not), it is simply a local database of unconfirmed transactions. To receive info about transactions relevant to the wallet, a thin-client will generally communicate with a full node via BIP 37/157/158.
chytrik
CC BY-SA 4.0
2019-12-19T06:20:37.757Z
@foba One issue I can see with a thin-client keeping a mempool, is that without validating all blockchain data, it is difficult to prove that an unconfirmed transaction's inputs have not already been spent (making the transaction invalid). I think doing so would require some sort of cryptographic UTXO-set commitment to be included in blocks, but the protocol does not currently include such a thing. This is probably worth posting as a new question.
chytrik
CC BY-SA 4.0
2019-12-19T06:35:41.000Z
yeah good points, thank you for your help! It looks like you really can't get around running a full node if you want to get pending transactions.
foba
CC BY-SA 4.0
2019-12-19T07:06:16.543Z
BIP37 (bloom filtered) clients today can receive unconfirmed transactions from the nodes they are connected to, but there is essentially no way for them to do any validation on those. A well-known block explorer that used this approach once accepted and showed on the site an unconfirmed transaction that paid someone 21M BTC.
Pieter Wuille
CC BY-SA 4.0
2019-12-19T04:25:02.810Z
2019-12-19T04:25:02.810Z
chytrik
<p>I looked into using a thin client but even thin clients implement SPV (Simple Payment Verification). What if you just wanted a client that <strong>only</strong> listens for transactions/pending transactions, doesn't store the blockchain, and only uses memory.</p>

<mempool><thin-clients>
Is it possible to create a thin client that only listens for transactions and pending transactions?
foba
# Is it possible to create a thin client that only listens for transactions and pending transactions?

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

I looked into using a thin client but even thin clients implement SPV (Simple Payment Verification). What if you just wanted a client that **only** listens for transactions/pending transactions, doesn't store the blockchain, and only uses memory.

**Tags:** mempool, thin-clients


---

## 1 answers

### Answer by username_1 on 2019-12-19. Score: 1 | Accepted answer

When receiving a payment, it is critical to know whether or not the transaction that makes that payment is a legitimate Bitcoin transaction (or not).

This is determined by checking if the transaction is valid according to the network's rules- and a crucial part of this is determining whether or not the transaction's inputs are valid. In order to determine the validity of the inputs, the client must have some way of knowing the current state of the network. Generally this is accomplished in two ways:

* **Full node**: this is software that will independently download and validate every transaction and block, thus verifying what the current state of the network is. As such, any transaction can (and will) be checked for validity.
* **Thin/Lite/SPV client**: this is software that will download the longest chain of block headers, but not the entire block. The client can thus check the validity of transaction by requesting proof of the transaction's inclusion in a block from full nodes on the network, this is accomplished via the merkle root included in the block header. This method of transaction verification requires more trust (that miners are in fact creating valid blocks), so the thin-client must trust that this verification is being performed by other nodes on the network.

If you are not performing verification of incoming transactions in one of these ways, then you will be easily defrauded, since you will be unable to differentiate between a valid and invalid transaction, without **fully** trusting someone else to supply this info to you.

> **Comments:**
> **username_0**: That makes a lot of sense. Is it true that this lite client does not have access to the mempool?  
> **username_1**: @username_0 There is no 'the mempool'. Rather, each node may choose to keep a mempool (or not), it is simply a local database of unconfirmed transactions. To receive info about transactions relevant to the wallet, a thin-client will generally communicate with a full node via BIP 37/157/158.  
> **username_1**: @username_0 One issue I can see with a thin-client keeping a mempool, is that without validating all blockchain data, it is difficult to prove that an unconfirmed transaction's inputs have not already been spent (making the transaction invalid). I think doing so would require some sort of cryptographic UTXO-set commitment to be included in blocks, but the protocol does not currently include such a thing. This is probably worth posting as a new question.  
> **username_0**: yeah good points, thank you for your help! It looks like you really can't get around running a full node if you want to get pending transactions.  
> **username_2**: BIP37 (bloom filtered) clients today can receive unconfirmed transactions from the nodes they are connected to, but there is essentially no way for them to do any validation on those. A well-known block explorer that used this approach once accepted and showed on the site an unconfirmed transaction that paid someone 21M BTC.  

---

