<p>A bitcoin wallet application that runs as a full node client contains a copy of every unspent transaction in the blockchain. This allows a wallet to construct transaction inputs as well as quickly verify incoming transactions as having correct inputs. However, most user wallets run lightweight clients that only track a users own unspent outputs. If the wallet does not maintain a copy of unspent transaction outputs it can query the bitcoin network using a variety of APIs. The API's will return all the unspent transaction outputs for an address. Most wallets will not run continuously and so when a user starts up the application it will query the network to synchronize with it.</p>

CC BY-SA 4.0
2022-03-07T20:16:02.973Z
How does a wallet (e.g. Bitcoin.com mobile wallet) know to send me a notification when I receive a transaction? It is almost instantaneous so I wonder how that works.
autr3go
CC BY-SA 4.0
2024-08-26T09:55:24.963Z
@autr3go - he never answered your question!
user93353
CC BY-SA 3.0
2017-12-28T10:22:41.250Z
2017-12-28T10:22:41.250Z
John Singh
<p>Some wallets scan every transaction, other wallets use different mechanisms to learn about payments. Bitcoin is a peer-to-peer gossip network. Nodes on the Bitcoin network announce new blocks immediately to all their peers, so if your wallet software interacts with the Bitcoin network, it will know to scan for updates whenever a new block is announced. Wallet software that does not directly participate in the Bitcoin network regularly polls a server to request updates or might register for push notification, but usually doesn’t process the entire blockchain itself. If your wallet is only online intermittently, it will learn about the transactions as soon as it comes online and catches up to the chaintip.</p>
<ol>
<li><strong>Full node</strong><br />
If you run a full node, it will learn about new blocks from peer announcements and process the blocks itself. The Bitcoin Core wallet will scan each transaction as it enters the mempool and scan every transaction on each block as it comes in. It will identify any transactions that contain known output scripts, and any transactions that spend any of its own UTXOs.</li>
<li><strong>Light client</strong><br />
If you run a light client (that does not keep a full copy of the blockchain), it may use bloom filters, the Electrum protocol, or compact block filters to learn about payments. Whenever a new block is announced on the network, the light client attempts to learn about new confirmed transactions that pay it. Some mechanisms also let it learn about unconfirmed transactions paying it.
<ol>
<li><strong>Compact block filters</strong><br />
Since about 2020, many full nodes offer <a href="https://bitcoinops.org/en/topics/compact-block-filters/" rel="nofollow noreferrer">compact block filters</a> (BIP 157, BIP 158). You can think of them as a register for looking up &quot;addresses&quot; in blocks. Some light clients download this compact block filter whenever a new block is found, and then client-side check whether any of their output scripts or UTXOs produce hits on the filter. If they get a hit, they download the whole block and parse each transaction to find the ones relevant to them. This has pretty decent privacy, as the wallet could even download the compact block filter and the block from different peers, so that the peers actually learn next to nothing about what the wallet was interested. It trades this privacy off with a higher bandwidth usage and more implementation work, as the node actually needs to be able to parse blocks and implement BIP 157 and BIP 158. Also, the compact block filter protocol cannot inform about unconfirmed transactions, so a light client that only depends on it will only learn about transactions once they are confirmed.</li>
<li><strong>Bloom filters</strong><br />
<a href="https://bitcoinops.org/en/topics/transaction-bloom-filtering/" rel="nofollow noreferrer">Transaction bloom filtering</a> was introduced by BIP 37 in 2012. The client would craft a bloom filter from its addresses, hand this filter to the server, the server would scan its mempool and recent blocks with the filter and return any transactions that produced a hit. The bloom filter had a configurable false-positive rate, which was supposed to provide some plausible deniability. This scheme has since fallen out of use, since it had multiple issues. Firstly, the false positive rate had to be set so high to actually achieve any privacy, that it would have dramatically increased bandwidth use. Therefore most wallets set the false positive rate low and essentially leaked their entire address list to any peer they requested the bloom filter service from. Secondly, the nodes offering this service would need to run a separate filter for each client which could cause a lot of computation, especially on a rescan of an old wallet. Offering the bloom filter network service opened a node up to several DOS vectors. Bitcoin Core 0.19 disabled this service by default.</li>
<li><strong>Electrum protocol</strong><br />
Most light clients use the Electrum protocol. The light client connects to a pre-defined or random Electrum server on the network and tells the server exactly what output scripts it is interested in. The server checks whether it has any hits in its database and serves the corresponding data. This is simple to implement and uses minimal bandwidth, but the light client leaks its entire body of addresses to the Electrum server including even addresses that never got paid.</li>
</ol>
</li>
<li><strong>Account with custodian</strong><br />
If you have an account with a custodian, your &quot;wallet&quot; software
connects to the service provider’s backend to look up its account information. The service provider pushes notifications when a new payment is spotted or a payment is confirmed.</li>
</ol>

CC BY-SA 4.0
2024-08-26T14:17:27.927Z
2024-08-26T14:17:27.927Z
Murch
<p>I'm curious how a wallet learns of an incoming transaction. Is it constantly searching the blockchain for blocks containing addresses it generated? </p>

<transactions><blockchain>
How does a wallet learn of a transaction it has received?
autr3go
# How does a wallet learn of a transaction it has received?

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

I'm curious how a wallet learns of an incoming transaction. Is it constantly searching the blockchain for blocks containing addresses it generated?

**Tags:** transactions, blockchain


---

## 2 answers

### Answer by username_1 on 2017-12-28. Score: 1

A bitcoin wallet application that runs as a full node client contains a copy of every unspent transaction in the blockchain. This allows a wallet to construct transaction inputs as well as quickly verify incoming transactions as having correct inputs. However, most user wallets run lightweight clients that only track a users own unspent outputs. If the wallet does not maintain a copy of unspent transaction outputs it can query the bitcoin network using a variety of APIs. The API's will return all the unspent transaction outputs for an address. Most wallets will not run continuously and so when a user starts up the application it will query the network to synchronize with it.

> **Comments:**
> **username_0**: How does a wallet (e.g. Bitcoin.com mobile wallet) know to send me a notification when I receive a transaction? It is almost instantaneous so I wonder how that works.  
> **username_2**: @username_0 - he never answered your question!  

---

### Answer by username_3 on 2024-08-26. Score: 1

Some wallets scan every transaction, other wallets use different mechanisms to learn about payments. Bitcoin is a peer-to-peer gossip network. Nodes on the Bitcoin network announce new blocks immediately to all their peers, so if your wallet software interacts with the Bitcoin network, it will know to scan for updates whenever a new block is announced. Wallet software that does not directly participate in the Bitcoin network regularly polls a server to request updates or might register for push notification, but usually doesn’t process the entire blockchain itself. If your wallet is only online intermittently, it will learn about the transactions as soon as it comes online and catches up to the chaintip.

1. **Full node**  
   If you run a full node, it will learn about new blocks from peer announcements and process the blocks itself. The Bitcoin Core wallet will scan each transaction as it enters the mempool and scan every transaction on each block as it comes in. It will identify any transactions that contain known output scripts, and any transactions that spend any of its own UTXOs.
2. **Light client**  
   If you run a light client (that does not keep a full copy of the blockchain), it may use bloom filters, the Electrum protocol, or compact block filters to learn about payments. Whenever a new block is announced on the network, the light client attempts to learn about new confirmed transactions that pay it. Some mechanisms also let it learn about unconfirmed transactions paying it.
   1. **Compact block filters**  
      Since about 2020, many full nodes offer [compact block filters](https://bitcoinops.org/en/topics/compact-block-filters/) (BIP 157, BIP 158). You can think of them as a register for looking up "addresses" in blocks. Some light clients download this compact block filter whenever a new block is found, and then client-side check whether any of their output scripts or UTXOs produce hits on the filter. If they get a hit, they download the whole block and parse each transaction to find the ones relevant to them. This has pretty decent privacy, as the wallet could even download the compact block filter and the block from different peers, so that the peers actually learn next to nothing about what the wallet was interested. It trades this privacy off with a higher bandwidth usage and more implementation work, as the node actually needs to be able to parse blocks and implement BIP 157 and BIP 158. Also, the compact block filter protocol cannot inform about unconfirmed transactions, so a light client that only depends on it will only learn about transactions once they are confirmed.
   2. **Bloom filters**  
      [Transaction bloom filtering](https://bitcoinops.org/en/topics/transaction-bloom-filtering/) was introduced by BIP 37 in 2012. The client would craft a bloom filter from its addresses, hand this filter to the server, the server would scan its mempool and recent blocks with the filter and return any transactions that produced a hit. The bloom filter had a configurable false-positive rate, which was supposed to provide some plausible deniability. This scheme has since fallen out of use, since it had multiple issues. Firstly, the false positive rate had to be set so high to actually achieve any privacy, that it would have dramatically increased bandwidth use. Therefore most wallets set the false positive rate low and essentially leaked their entire address list to any peer they requested the bloom filter service from. Secondly, the nodes offering this service would need to run a separate filter for each client which could cause a lot of computation, especially on a rescan of an old wallet. Offering the bloom filter network service opened a node up to several DOS vectors. Bitcoin Core 0.19 disabled this service by default.
   3. **Electrum protocol**  
      Most light clients use the Electrum protocol. The light client connects to a pre-defined or random Electrum server on the network and tells the server exactly what output scripts it is interested in. The server checks whether it has any hits in its database and serves the corresponding data. This is simple to implement and uses minimal bandwidth, but the light client leaks its entire body of addresses to the Electrum server including even addresses that never got paid.
3. **Account with custodian**  
   If you have an account with a custodian, your "wallet" software
   connects to the service provider’s backend to look up its account information. The service provider pushes notifications when a new payment is spotted or a payment is confirmed.


---

