Matt Corallo

Sur GitHub, Matt Corallo utilise TheBlueMatt. Son profil indique que de nombreux dépôts ont déménagé vers git.bitcoin.ninja. Un dépôt conserve le code source et l’historique de ses modifications : un ancien emplacement vide ne signifie donc pas nécessairement un projet abandonné. Pour savoir qui a apporté quoi, mieux vaut suivre cet historique, les propositions et leurs auteurs. Chez Corallo, ce parcours mène d’une transmission plus efficace des blocs aux outils pour Lightning. [1]

Les ordinateurs qui vérifient Bitcoin échangent en permanence des transactions non confirmées. À l’arrivée d’un bloc, ils peuvent donc en connaître déjà une grande partie. Compact Block Relay exploite cette situation. La spécification technique publique BIP 152 nomme Corallo comme auteur et remercie Gregory Maxwell pour l’idée initiale, la conception et les tests. Son objectif principal est de réduire les données transmises. Le transfert peut aussi s’accélérer, mais les règles de validité des blocs restent les mêmes. [2]

Imaginez une liste commune de documents : vous en avez déjà la plupart et devez seulement savoir lesquels composent le nouveau dossier. BIP 152 utilise de même des identifiants courts de transactions et le mempool, la réserve locale de transactions non confirmées. Le destinataire réclame les données manquantes avec getblocktxn. Des identifiants peuvent entrer en collision, c’est-à-dire désigner de la même façon des transactions différentes. L’économie de transmission ne dispense donc pas d’obtenir les données réelles et de vérifier la bonne reconstruction du bloc. [2]

Dans des conditions précises, BIP 152 permet une annonce compacte avant la vérification complète de toutes les transactions. Cela n’autorise pas l’envoi de n’importe quoi : l’en-tête, son rattachement à la chaîne validée, la preuve de travail et son engagement envers les transactions incluses doivent être contrôlés. Une fois reconstitué, le bloc est traité normalement. Le destinataire vérifie toujours que les fonds existent et sont dépensés conformément aux règles. « Le bloc est arrivé » ne veut pas dire « le bloc est valide ». [2]

Internet transporte les données en petits morceaux, les paquets. Si l’un manque, attendre sa retransmission ajoute du délai. Le 7 juillet 2016, Corallo présentait FIBRE : des blocs compacts associés à UDP, un transport sans renvoi automatique des paquets perdus, et à FEC, un codage permettant de récupérer des parties manquantes. Les données supplémentaires aident à reconstituer le contenu sans nouvelle demande. Cela augmente le volume transmis ; ce n’est pas une garantie de transmission parfaite dans toutes les circonstances. [3]

FIBRE peut retransmettre des paquets avant de les vérifier. Cela fait gagner du temps, mais exige une forte confiance interne entre ses nœuds. Il ne s’agit pas d’accepter librement toute connexion non vérifiée. Le code public permet de créer d’autres réseaux, sans empêcher l’opérateur d’un réseau donné de choisir ses partenaires. Selon la FAQ, w0xlt et Justin, de Localhost Research, ont repris la maintenance en 2025 avec les conseils de Corallo et Maxwell. Le projet se poursuit donc grâce à d’autres personnes. [4]

Une autre partie du travail de Corallo concerne Lightning, un réseau de paiements par canaux au-dessus de Bitcoin. Le manifeste, autrement dit la description du paquet lightning dans rust-lightning, indique Matt Corallo comme auteur. Écrite en Rust, cette bibliothèque fournit les fonctions centrales de Lightning. L’application choisit sa gestion du portefeuille, son interaction avec la chaîne, son stockage et sa mise en réseau. Cette attribution ne signifie ni qu’une seule personne a écrit chaque modification ultérieure, ni que la bibliothèque constitue à elle seule un portefeuille prêt à l’emploi. [5]

LDK s’intègre à l’application sous forme de SDK, une boîte à outils destinée aux développeurs. Ceux-ci doivent raccorder le stockage et les autres composants nécessaires. Le résultat d’un paiement n’arrive pas forcément au moment de son lancement : LDK signale plus tard sa réussite ou son échec par un événement que l’application traite. Déclencher l’opération ne confirme donc pas sa réussite. Pour l’utilisateur du portefeuille, l’exigence est simple : l’écran doit distinguer un paiement en cours d’un paiement terminé. [6]