Neutrino est un client léger Bitcoin développé en Go par Lightning Labs, conçu notamment pour les applications mobiles utilisant Lightning Network. Il s’appuie sur BIP 157 et BIP 158 pour les filtres compacts de blocs. C’est une bibliothèque logicielle précise, pas un nom générique pour les portefeuilles légers ni un remplacement du Full Node, qui vérifie lui-même toutes les règles.
Anna ouvre son portefeuille et s’attend à y voir un paiement reçu. Pour afficher le bon état, l’application doit obtenir et traiter des données du réseau Bitcoin. Neutrino peut assurer cette tâche sans conserver durablement toute la chaîne de blocs sur le téléphone. Un bloc est un ensemble de transactions inscrit dans l’historique commun du réseau Bitcoin. Dans le logiciel, ce service s’appelle ChainService : il gère les connexions, une base locale et la synchronisation des en-têtes. Un en-tête résume les informations essentielles d’un bloc. Une clé privée est un nombre secret qui sert à créer une signature numérique autorisant une dépense. Utiliser Neutrino ne dit toutefois pas qui détient les clés privées d’Anna ni qui autorise les envois. Gestion des clés, écrans et sauvegardes relèvent du portefeuille qui emploie la bibliothèque. [1]
Un filtre compact ressemble à un petit index de recherche pour un bloc. Le portefeuille le télécharge et vérifie sur son propre appareil s’il correspond à ce qu’il cherche. Il compare en pratique des scripts, les conditions permettant de dépenser certaines sorties Bitcoin. Une sortie est la partie d’une transaction qui indique un montant et les conditions pour le dépenser ensuite. Le portefeuille n’a pas à transmettre à son interlocuteur toute sa liste d’adresses. En cas de correspondance, il télécharge le bloc concerné et cherche la transaction réelle. Même un filtre correctement construit peut donner un faux positif : le bloc est téléchargé inutilement, car l’élément recherché n’y figure finalement pas. Une correspondance seule ne prouve donc ni la réception d’un paiement, ni son montant, ni la possibilité de le dépenser. [1] [2] [3]
Anna remplace son téléphone et restaure son portefeuille. Chercher uniquement à partir des blocs d’aujourd’hui ne suffit pas si elle a reçu des paiements auparavant. L’application doit fournir les bons scripts à surveiller et un point de départ assez ancien. Selon la documentation, Rescan sans bloc de départ indiqué commence au dernier bloc connu, pas automatiquement au début de toute l’histoire. Un filtre fonctionnel ne trouve ni une adresse que le portefeuille ne cherche pas ni des paiements dans une période ignorée. Il faut donc distinguer une restauration terminée d’une recherche encore en cours. Une liste momentanément vide ne prouve pas que les fonds ont disparu. [1]
Neutrino synchronise les en-têtes de blocs et les en-têtes de filtres. Les premiers permettent de vérifier leur enchaînement et le Proof of Work, la preuve d’un travail de calcul, puis de suivre la chaîne ayant le plus de travail cumulé. C’est bien plus que reprendre aveuglément le solde annoncé par un serveur, mais moins que vérifier chaque transaction et chaque règle soi-même, comme le fait un Full Node. Il s’agit aussi de deux chaînes d’en-têtes distinctes. Les en-têtes des blocs Bitcoin n’engagent pas directement la validité de ces filtres. Vérifier seulement leurs hashes, des empreintes cryptographiques, n’exclut donc pas une série de filtres frauduleuse mais cohérente en interne. L’économie de travail a une limite de confiance précise. [2] [4]
Un pair est un autre ordinateur du réseau auprès duquel le client obtient des données. BIP 157 repose sur la comparaison des réponses et sur la présence d’au moins un pair honnête pour détecter des filtres incorrects. Si un même attaquant contrôle toutes les connexions, leur nombre ne suffit pas. Ses ordinateurs peuvent donner la même réponse fausse ou cacher un état plus récent. Cette coupure des sources honnêtes est liée à une Eclipse Attack. Le portefeuille a besoin de sources disponibles et suffisamment indépendantes, pas seulement de connexions. Une icône verte ne prouve pas qu’il possède déjà un historique complet et à jour. [2]
Jan vient d’envoyer de l’argent à Anna. Sa transaction peut d’abord attendre dans un Mempool, l’ensemble local des transactions non confirmées d’un nœud, avant qu’un mineur l’inclue dans un bloc. Les notifications documentées recvtx et redeemingtx de Neutrino arrivent lors de la confirmation dans un bloc, pas dès l’entrée dans un Mempool. Une application souhaitant montrer les paiements entrants non confirmés a besoin d’un autre mécanisme adapté. Un filtre de bloc ne peut pas le faire avant que ce bloc existe. Envoi, acceptation par un pair et confirmation sont des événements distincts ; une notification absente ne prouve pas encore que Jan n’a rien envoyé. [1]
Une correspondance de filtre n’est utile que si le client obtient aussi le bloc nécessaire. Si le réseau ne le fournit pas pour le moment, la bonne conclusion est « les données manquent encore », pas « le solde est nul ». L’état peut également changer lors d’une réorganisation : le réseau adopte une autre branche avec davantage de travail cumulé et détache des blocs précédemment rattachés. Rescan signale les blocs rattachés et détachés pour permettre à l’application de recalculer ses données. La confidentialité n’est pas absolue non plus : le pair ne reçoit pas la liste des adresses recherchées, mais voit les demandes de blocs et les informations réseau de la connexion. La manière d’obtenir les données compte donc toujours. [1] [2]
Lightning Network est un réseau de paiement construit sur Bitcoin. Dans un canal de paiement, deux participants mettent à jour la répartition des fonds qu’ils y partagent, au lieu d’inscrire chaque paiement dans un bloc Bitcoin. Neutrino fournit les données de la chaîne ; il ne conserve pas à lui seul, pour l’utilisateur, les informations permettant de restaurer l’état actuel de ces canaux. Retrouver l’historique du portefeuille et restaurer les canaux sont donc deux tâches différentes. Le README décrit le stockage des filtres demandés et le téléchargement des blocs sans conservation permanente ; les besoins réels dépendent de la version et de la configuration de l’application. Avant de s’appuyer sur ce portefeuille, il faut comprendre sa procédure de sauvegarde et de restauration, ainsi que son comportement quand les sources deviennent indisponibles. Une base plus petite sur le téléphone ne supprime pas ces responsabilités. [1] [4]
Pour une vision complète, lisez aussi Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse Attack, Bitcoin. Cette entrée est également citée par Compact Block Filters, Compact Block Filters.