Rusty Russell est un développeur open source qui a largement contribué à Core Lightning, un logiciel pour exploiter un nœud Lightning Network. Il a aussi participé aux spécifications communes BOLT et défendu BOLT 12, qui permet d’obtenir de nouvelles demandes de paiement à partir d’une offre réutilisable. Lightning transporte des paiements en bitcoin par des canaux de paiement.
Les grands projets commencent souvent discrètement. La rétrospective de Blockstream du 9 juin 2026 rappelle le premier commit de Russell, daté du 26 mai 2015 : un petit outil pour construire un message d’ouverture de canal. Un commit enregistre une modification dans l’historique du code. Cet essai est devenu Core Lightning ; Russell a contribué au programme, aux tests et à l’accompagnement d’autres développeurs. L’article décrit aussi son départ après onze ans. Il n’annonce pas la fin de toutes ses contributions futures et ne transforme pas son ancienne direction en autorité permanente sur le réseau. [1]
Imaginez un café et un client utilisant des programmes différents. Payer ne devrait pas exiger de choisir le même fournisseur. Il faut des règles communes pour les messages et leur sens. Les spécifications BOLT décrivent cette communication dans Lightning. Russell a animé leur élaboration collective et encouragé l’interopérabilité, c’est-à-dire la capacité d’implémentations différentes à fonctionner ensemble. Le dépôt public accepte propositions et commentaires. Même un contributeur majeur ne peut imposer seul une modification à tous les nœuds : les règles doivent prendre corps dans les logiciels et leur utilisation. [1] [2]
Deux programmes peuvent interpréter différemment le même paragraphe. lnprototest, créé par Russell, fournit des outils en Python pour écrire des scénarios et tester les réponses aux messages du protocole. Le README, document introductif du projet, distingue un exécuteur simulé des tests face à une véritable implémentation. La simulation aide à préparer un test, mais sa réussite ne prouve pas le comportement d’un nœud réel. Il faut savoir ce qui a effectivement tourné et quelles situations ont été couvertes. Même une série de tests réussis n’est pas un audit de tous les défauts possibles. [3]
Avec BOLT 12, le café peut publier une offre réutilisable, par exemple sous forme de code QR. Le portefeuille du client envoie une invoice_request à partir de cette offre et reçoit une facture précise, c’est-à-dire une demande contenant les données du paiement concerné. Le paiement vient ensuite. L’offre peut ainsi être réutilisée tout en produisant des factures individuelles. Une facture déjà utilisée ne devient pas une nouvelle demande à chaque achat. Distinguer offre, requête et facture facilite le paiement sans mélanger les opérations. [4]
Core Lightning rend cette distinction visible. La commande fetchinvoice contacte l’émetteur de l’offre et récupère une facture. Le champ changes peut signaler des différences, par exemple sur le montant ou la description. Une réponse réussie n’envoie pas d’argent. C’est comme recevoir l’addition au café : on vérifie d’abord ce qu’il faut payer et combien. Le portefeuille doit traiter les conditions reçues puis lancer séparément le paiement. Terminer la récupération d’une demande ne signifie pas avoir terminé son règlement. [5]
La documentation de pay distingue complete, pending et failed : terminé, en attente et échoué. En attente ne signifie pas payé. Elle sépare aussi amount_msat, la somme reçue par le destinataire, et amount_sent_msat, le total envoyé avec les frais. msat signifie millisatoshi, un millième de satoshi. Le client peut donc dépenser les frais en plus de ce que reçoit le café. La documentation présente désormais pay comme obsolète et décrit la transition vers xpay. Il s’agit ici d’expliquer états et montants, pas d’installer une version précise ; les résultats doivent être lus selon le logiciel utilisé. [6]
Lorsque le café rembourse, il ne rembobine pas le paiement initial. BOLT 12 décrit aussi le trajet inverse : le commerçant indique la somme à envoyer, le client fournit une facture et le commerçant vérifie invoice_node_id, l’identifiant du nœud à payer. Un nouveau paiement part ensuite vers le client. Cela n’annule pas le transfert initial et ne crée pas automatiquement un droit au remboursement. Le protocole fournit un moyen de le réaliser ; les parties doivent régler séparément son motif et ses conditions. [4]
Lors d’un litige, il est utile de savoir ce que démontre réellement une preuve. BOLT 12 explique que le preimage, valeur secrète correspondant au hash de la demande de paiement, peut démontrer qu’une facture a été payée. Une fois publié, quelqu’un d’autre peut cependant le présenter : il n’identifie pas à lui seul l’expéditeur des fonds. Une clé incluse dans la requête permet de prouver qui a demandé la facture, sans vérifier automatiquement son identité civile. Facture réglée, contrôle d’une clé et identité du client restent des informations différentes. [4]
Pour une vision complète, lisez aussi Andrew Poelstra, Tadge Dryja, Lightning Network. Cette entrée est également citée par Andrew Poelstra, Tadge Dryja.