Christian Decker est chercheur et développeur pour Bitcoin et Lightning, un réseau de paiements par canaux. Il a travaillé sur la propagation des données, eltoo, BIP 118 et Greenlight. Ses contributions se comprennent à travers les problèmes traités : informations différentes dans le réseau, accords de solde périmés et contraintes liées à l’exploitation d’un nœud.
En cherchant les travaux de Decker, on rencontre le compte cdecker et le nom Snyke. Lors de la vérification en octobre 2026, son profil public mentionnait aussi Blockstream. Cela relie un auteur à du code et à des propositions, sans suffire à établir son poste actuel. Dans un réseau ouvert, une proposition vaut par le problème qu’elle résout et sa résistance à l’examen. Ni un nom ni un employeur ne donnent le pouvoir de changer les règles des autres. [1]
Un nouveau bloc circule par étapes : un ordinateur le transmet à d’autres, ce qui prend du temps. Christian Decker et Roger Wattenhofer ont mesuré ce phénomène en 2013. Ils ont étudié la propagation des transactions et des blocs, ainsi que le lien entre délais et bifurcations temporaires, lorsque des parties du réseau travaillent sur des blocs récents différents. Ces mesures historiques éclairent le fonctionnement réel du réseau, pas sa vitesse actuelle : logiciels et méthodes de transmission ont évolué. [2]
Dans un canal de paiement, les participants conviennent régulièrement de la part de chacun dans les fonds engagés ensemble. Que faire si une personne ferme le canal avec un ancien accord qui l’avantage ? La proposition eltoo de Decker, Rusty Russell et Olaoluwa Osuntokun permet d’imposer un état plus récent avant le règlement définitif. C’est comme remplacer un décompte périmé par le dernier accord. Il s’agit d’un mécanisme proposé, pas d’une fonction automatiquement présente dans tous les canaux Lightning actuels. [3]
Pouvoir corriger ne suffit pas. Avec eltoo, la transaction corrective doit être confirmée avant que l’ancien état puisse être réglé définitivement. OP_CSV ménage ce délai de réaction : une certaine dépense n’est autorisée qu’après une attente prescrite à compter de la confirmation de la sortie concernée. L’utilisateur ou un service mandaté doit donc surveiller la chaîne. La proposition change le traitement des anciens états, mais ne rend pas sûres des périodes hors ligne illimitées. [3]
Appliquer un nouvel accord à différents anciens états demande des règles de signature adaptées. BIP 118, signé par Decker et Anthony Towns, propose SIGHASH_ANYPREVOUT. En octobre 2026, le document portait le statut Draft, c’est-à-dire projet, et décrivait un changement de consensus par soft fork : une modification des règles de validation des nœuds Bitcoin. Sa publication ou le soutien de développeurs ne prouve pas son activation. Proposition, programmation et adoption restent des étapes distinctes. [4]
Habituellement, une signature engage aussi la sortie de transaction précise que l’on dépense : un montant assorti de conditions. BIP 118 assouplit ce lien dans un mode choisi. Une transaction signée peut alors être rattachée à une autre sortie compatible, afin de remplacer un ancien état de canal. Cela ne permet pas de dépenser arbitrairement l’argent d’autrui. Les possibilités accrues de réutilisation d’une signature imposent une conception prudente. Selon le mode, les engagements sur le montant et les conditions de dépense comptent aussi. [4]
Faire fonctionner un nœud Lightning demande un suivi. Blockstream a annoncé le lancement public de Greenlight le 12 octobre 2023, en présentant Decker comme responsable du projet. Les rôles sont séparés : l’utilisateur détient ses clés privées, le prestataire exploite l’infrastructure du nœud. Une clé privée autorise une dépense ; la détenir n’équivaut donc pas à gérer un serveur. Ce modèle ne garantit ni une disponibilité ininterrompue ni des conditions commerciales immuables. Ces aspects doivent être examinés séparément. [5]
Core Lightning est un logiciel permettant d’exploiter un nœud Lightning. Des plugins, ou extensions, adaptent ses fonctions aux besoins de l’opérateur ; reckless aide à les installer et à les activer. Cette modification n’est pas de même nature qu’une nouvelle règle de signature Bitcoin. Installer une extension n’ajoute pas BIP 118 aux règles du réseau entier. Les travaux de Decker relient recherche, propositions de protocole et outils pratiques, mais chaque domaine suit son propre chemin jusqu’à l’utilisation. [6]
Pour une vision complète, lisez aussi Elizabeth Stark, Andreas Antonopoulos, Lightning Network. Cette entrée est également citée par Elizabeth Stark, Andreas Antonopoulos.