Neutrino est le client léger en Go de Lightning Labs, conçu aussi pour un usage mobile avec Lightning Network. Il utilise BIP 157 et BIP 158 ; ce nom ne désigne ni tous les clients légers ni un remplacement autonome d’un Full Node.
L’application démarre ChainService, qui gère les connexions aux pairs, la base de données et la synchronisation des en-têtes. Le portefeuille s’appuie dessus pour chercher ses transactions entrantes et sortantes. Utiliser Neutrino ne détermine pas qui détient les clés privées ou approuve les paiements ; ces fonctions et les sauvegardes relèvent de l’application qui l’intègre. [Lightning Labs — Neutrino README]
Le client synchronise les en-têtes de blocs et de filtres, puis charge les filtres et blocs correspondants selon ses besoins. Il teste ses scripts localement. Une correspondance peut être un faux positif : il doit examiner le vrai bloc et y trouver la transaction. Le filtre seul ne donne ni montant ni preuve qu’un portefeuille contrôle une sortie. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Un client léger vérifie les en-têtes et leur enchaînement, sans vérifier indépendamment chaque transaction et condition de consensus comme un Full Node. De plus, la chaîne d’en-têtes de filtres n’est pas engagée dans les en-têtes Bitcoin. Vérifier leurs hashes ne suffit donc pas à exclure des filtres frauduleux pourtant cohérents entre eux. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 repose sur la comparaison des réponses et au moins un pair honnête pour détecter les filtres erronés. Plusieurs connexions aux machines d’un même attaquant ne satisfont pas cette condition. Isoler le client peut lui cacher des paiements ou un nouvel état de chaîne ; il faut des sources disponibles et variées, pas seulement un nombre de connexions non nul. [BIP 157 — Client Side Block Filtering]
Le README décrit Rescan avec des blocs de début et de fin facultatifs ; sans début, il part du dernier bloc connu. Cela ne parcourt pas automatiquement tout l’historique d’un portefeuille restauré. L’application doit fournir un point assez ancien et tous les scripts surveillés ; un filtre correct ne trouve pas une adresse que le client ne recherche pas. [Lightning Labs — Neutrino README]
Les événements documentés recvtx et redeemingtx arrivent à la confirmation, pas dès l’entrée dans le Mempool. Un portefeuille montrant des paiements non confirmés a donc besoin d’un mécanisme supplémentaire adapté. Diffusion, acceptation par un pair et confirmation dans un bloc sont distinctes ; l’absence de notification ne prouve pas à elle seule qu’aucun envoi n’a eu lieu. [Lightning Labs — Neutrino README]
Rescan signale les blocs connectés et déconnectés pour que l’application recalcule son état après une réorganisation. Un filtre correspondant exige toujours le vrai bloc ; son indisponibilité ne doit pas apparaître comme un solde nul. Le pair voit les demandes de blocs et les données réseau même sans recevoir la liste des adresses recherchées. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
Le README décrit le stockage des filtres demandés et le chargement des blocs sans conservation permanente ; vérifie le fonctionnement réel selon la version et la configuration. Neutrino fournit des données de chaîne, pas une sauvegarde de l’état actuel des canaux Lightning. Teste séparément restauration de l’historique, perte de pairs, réorganisation et récupération des canaux propre à l’application. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Pour une vision complète, lisez aussi Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. Cette entrée est également citée par Compact Block Filters, Compact Block Filters.