<p>There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but this is even weaker than a normal unconfirmed transaction sent to a fully validating wallet.</p>
<p>It has always been an issue with &quot;SPV&quot; wallets that they can be duped into showing completely absurd false data, for BIP37 especially it was completely possible to sniff the incoming filter and dynamically produce transactions paying to the addresses that likely matched it billions of dollars. The client, as dumb as it is, can only show them to the user and hope that common sense on the part of the user prevails.</p>

CC BY-SA 4.0
2021-01-15T18:33:33.187Z
2021-02-05T21:04:09.670Z
2021-02-05T21:04:09.670Z
Claris
<p>I was discussing various light client models and we got into unconfirmed transactions. With the BIP37-based bloom filters, a light client would subscribe to updates from full node peers by submitting its filter to the full nodes. A BIP37 filter could be applied to the mempool and a full node could notify the light client of unconfirmed transactions.</p>
<p>As far as I understands, compact block filters (CBF) are only created for confirmed blocks. This implies that a CBF-based light client would only hear about transactions after confirmation unless they had another mechanism to hear about unconfirmed transactions. Keeping up with the mempool would incur a lot of traffic. How would CBF-based light clients learn about relevant unconfirmed transactions without having all the downsides of BIP37-based wallets?</p>

<unconfirmed-transactions><thin-clients><compact-client-side-block-filters>
How do light clients using compact block filters get relevant unconfirmed transactions?
Murch
# How do light clients using compact block filters get relevant unconfirmed transactions?

(Asked by: username_0 on 2021-01-15)

I was discussing various light client models and we got into unconfirmed transactions. With the BIP37-based bloom filters, a light client would subscribe to updates from full node peers by submitting its filter to the full nodes. A BIP37 filter could be applied to the mempool and a full node could notify the light client of unconfirmed transactions.

As far as I understands, compact block filters (CBF) are only created for confirmed blocks. This implies that a CBF-based light client would only hear about transactions after confirmation unless they had another mechanism to hear about unconfirmed transactions. Keeping up with the mempool would incur a lot of traffic. How would CBF-based light clients learn about relevant unconfirmed transactions without having all the downsides of BIP37-based wallets?

**Tags:** unconfirmed-transactions, thin-clients, compact-client-side-block-filters


---

## 1 answers

### Answer by username_1 on 2021-01-15. Score: 4 | Accepted answer

There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but this is even weaker than a normal unconfirmed transaction sent to a fully validating wallet.

It has always been an issue with "SPV" wallets that they can be duped into showing completely absurd false data, for BIP37 especially it was completely possible to sniff the incoming filter and dynamically produce transactions paying to the addresses that likely matched it billions of dollars. The client, as dumb as it is, can only show them to the user and hope that common sense on the part of the user prevails.


---

