Neutrino

Anna opens her wallet expecting to see a payment she received. To display the right state, the app needs to obtain and process data from the Bitcoin network. Neutrino can be the part that handles this without permanently storing the entire chain of blocks on her phone. A block is a group of transactions recorded in the Bitcoin network’s shared history. Neutrino’s data service is called ChainService: it handles connections, a local database and header synchronization. A header is a short summary of a block’s basic information. A private key is a secret number used to create a digital signature authorizing a spend. Using Neutrino alone does not tell us who holds Anna’s private keys or approves sending. Key management, screens and user backups belong to the wallet using the library. [1]

Think of a compact filter as a small search index for one block. The wallet downloads it and tests locally whether it matches what it is looking for. In practice it compares scripts, the conditions under which particular Bitcoin outputs can be spent. An output is the part of a transaction that specifies an amount and the conditions for spending it later. The wallet need not send the other party its entire address list. On a match, it downloads the relevant block and looks for the actual transaction. A correctly constructed filter can also give a false positive: the block is downloaded unnecessarily because the item is not actually there. A match alone therefore proves neither receipt, amount nor the wallet’s ability to spend the money. [1] [2] [3]

Anna replaces her phone and restores her wallet. Looking only from today’s blocks onward is insufficient if she received payments earlier. The app must supply the correct watched scripts and a sufficiently early starting point. According to the documentation, Rescan without a specified start block begins at the latest known block, not automatically at the beginning of all history. A working filter cannot find an address the wallet never searches for, nor can it recover old payments in a skipped range. Completed recovery must therefore be distinguished from scanning still in progress. An empty overview during recovery does not by itself prove that the funds are gone. [1]

Neutrino synchronizes block headers and filter headers. Block headers allow checks of linkage and Proof of Work, the evidence of computational work, and tracking of the chain with the greatest cumulative work. That is substantially more than blindly accepting a server’s balance, but less than independently validating every transaction and rule as a Full Node does. These are also two different header chains. Bitcoin block headers do not directly commit to the correctness of these filters. Merely checking hashes, cryptographic fingerprints, therefore cannot rule out a fraudulent but internally consistent filter set. The reduction in work comes with a specific trust boundary. [2] [4]

A peer is another computer on the network from which the client obtains data. BIP 157 relies on comparing responses and having at least one honest peer to expose incorrect filters. If one attacker controls every connection, the number of connected computers does not help on its own. They can agree on the same false response or conceal a newer state. Cutting a client off from honest sources in this way is related to an Eclipse Attack. A wallet needs available, sufficiently independent sources, not just connections. A green connection icon does not prove it already has a current and complete payment history. [2]

Suppose Jan has just sent Anna money. His transaction may first wait in a Mempool, a node’s local collection of unconfirmed transactions, until a miner includes it in a block. Neutrino’s documented recvtx and redeemingtx notifications arrive upon block confirmation, not when the transaction enters a Mempool. An app that wants to show incoming unconfirmed payments needs another suitable mechanism. A block filter alone cannot reveal something before that block exists. Sending, acceptance by a peer and confirmation are separate events; a missing notification does not yet prove that Jan sent nothing. [1]

A filter match is useful only if the client can also obtain the required block. If the network cannot supply it at the moment, the right conclusion is “data are not available yet”, not “the balance is zero”. State can also change during a reorganization, when the network adopts another branch with more cumulative work and disconnects previously attached blocks. Rescan reports both connected and disconnected blocks so the app can recalculate its records. Privacy is not absolute either: a peer does not receive the watched address list, but sees requests for particular blocks and network information about the connection. How data are obtained still matters. [1] [2]

Lightning Network is a payment network built on Bitcoin. In a payment channel, two participants update how their shared funds are divided between them, rather than recording every payment in a Bitcoin block. Neutrino supplies chain data; it does not itself preserve the recovery material needed for the current state of those channels on the user’s behalf. Recovering wallet history and recovering channels are therefore separate tasks. The README describes storing requested filters and fetching blocks without saving them permanently; actual requirements must be assessed for the app’s version and configuration. Before relying on such a wallet, a person should understand its own backup and recovery procedure and its behavior when data sources fail. A smaller phone database does not remove these responsibilities. [1] [4]