Neutrino is Lightning Labs’ Go light-client implementation, designed also for mobile use with Lightning Network. It uses BIP 157 and BIP 158; it is neither a name for every light client nor a standalone replacement for a Full Node.
The application starts ChainService, which manages peer connections, the database and header synchronization. The wallet uses it to find incoming and outgoing transactions. Using Neutrino alone does not establish who holds private keys or approves payments; those functions and user backups belong to the surrounding application. [Lightning Labs — Neutrino README]
The client synchronizes block and filter headers, fetching filters and matching blocks as needed. It tests its scripts locally. A match may be a false positive, so it must inspect the actual block and find the transaction. The filter alone supplies neither an amount nor proof that a particular wallet controls an output. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
A light client checks headers and their linkage but does not independently verify every transaction and consensus condition like a Full Node. Moreover, the filter-header chain is not committed in Bitcoin block headers. Merely verifying their hashes therefore cannot rule out internally consistent fraudulent filters. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 relies on comparing responses and having at least one honest peer to detect incorrect filters. Several connections to the same attacker’s machines do not meet that condition. Isolating a client can hide payments or a new chain state; available, diverse sources matter, not merely a nonzero connection count. [BIP 157 — Client Side Block Filtering]
The README describes Rescan with optional start and end blocks; without a start it scans from the latest known block. That does not automatically search a restored wallet’s entire history. The application must provide an early enough starting point and the complete set of watched scripts; a correct filter cannot find an address the client is not looking for. [Lightning Labs — Neutrino README]
Documented recvtx and redeemingtx events arrive on confirmation, not when the transaction enters Mempool. A wallet showing unconfirmed payments therefore needs an appropriate additional mechanism. Broadcasting, peer acceptance and block confirmation are separate events; no notification alone does not prove nothing was sent. [Lightning Labs — Neutrino README]
Rescan reports both connected and disconnected blocks so the application can recalculate its state after a reorganization. A matching filter still requires the actual block to be available; unavailability must not be presented as a zero balance. A peer sees block requests and network data even without receiving the client’s list of watched addresses. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
The README describes storing requested filters and loading blocks without saving them permanently; check actual operation against the version and configuration. Neutrino supplies chain data, not a backup of the current Lightning channel state. Before deployment, separately test history recovery, peer loss, reorganization and the application’s channel recovery procedure. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
For the clearest picture, read this entry together with Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. The reverse links also lead from Compact Block Filters, Compact Block Filters.