Le bulletin de cette semaine décrit le travail de Hornet Node sur une spécification exécutable déclarative des règles de consensus et résume une discussion à propos du brouillage par saturation des messages onion dans le réseau Lightning. Sont également incluses nos rubriques habituelles avec des questions et réponses sélectionnées de Bitcoin Stack Exchange, des annonces de nouvelles versions et versions candidates, et des descriptions de changements notables apportés aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Spécification exécutable déclarative des règles de consensus Bitcoin par Hornet Node : Toby Sharp a publié sur Delving Bitcoin et la liste de diffusion Bitcoin-Dev une mise à jour sur le projet de nœud Hornet. Sharp avait précédemment décrit une nouvelle implémentation de nœud, Hornet, qui réduisait les temps de téléchargement initial de la chaîne de 167 minutes à 15 minutes. Dans cette mise à jour, il indique avoir achevé une spécification déclarative des règles de validation de bloc hors-script, composée de 34 invariants sémantiques assemblés à l’aide d’une algèbre simple.

    Sharp présente également les travaux futurs, notamment l’extension de la spécification à la validation des scripts, et discute de comparaisons potentielles avec d’autres implémentations telles que libbitcoin en réponse aux retours d’Eric Voskuil.

  • ● Brouillage par saturation des messages onion dans le réseau Lightning : Erick Cestari a publié sur Delving Bitcoin à propos du problème de brouillage par saturation des messages onion affectant le réseau Lightning. BOLT4 reconnaît que les messages onion sont peu fiables, recommandant d’appliquer des techniques de limitation de débit. Selon Cestari, ces techniques sont ce qui rend possible le brouillage des messages. Des attaquants peuvent lancer des nœuds malveillants et inonder le réseau de messages indésirables déclenchant les limites de débit des pairs, les forçant à abandonner des messages légitimes. De plus, BOLT4 n’impose pas de longueur maximale de message, permettant aux attaquants de maximiser la portée d’un seul message.

    Cestari a examiné plusieurs mesures d’atténuation contre le brouillage par saturation des messages onion et a fourni une vue d’ensemble complète des techniques qu’il jugeait les plus appropriées :

    • ● Frais initiaux: Cette technique a été proposée pour la première fois par Carla Kirk-Cohen dans BOLTs #1052 comme solution au brouillage des canaux, mais peut être facilement étendue. Les nœuds annonceraient des frais fixes par message, à inclure dans la charge utile onion et à déduire à chaque saut. Dans le cas où les frais ne sont pas payés, le message serait simplement abandonné par le nœud. Cette méthode présente certaines limites, comme la possibilité de ne transférer des messages qu’aux pairs de canal et une surcharge p2p accrue.

    • ● Limite de sauts et preuve d’enjeu fondée sur les soldes des canaux: Cette technique a été proposée par Bashiri et Khabbazian à l’Université de l’Alberta et comporte deux composantes différentes :

      • Encadrement strict du nombre de sauts : soit fixer une limite dure au nombre maximal de sauts qu’un message peut effectuer (par ex. 3 sauts), soit demander à l’expéditeur de résoudre une énigme de preuve de travail, dont la difficulté augmente exponentiellement avec le nombre de sauts.

      • Règle de transfert par preuve d’enjeu : chaque nœud fixe des limites de débit par pair selon le solde agrégé des canaux du pair, accordant aux nœuds bien financés une plus grande capacité de transfert.

      Les compromis de cette approche sont liés à la pression à la centralisation, puisque les nœuds plus importants sont avantagés, tandis que la limite dure à 3 sauts pourrait réduire l’ensemble d’anonymat.

    • ● Paiement mesuré par bande passante: Proposée par Olaoluwa Osuntokun, cette technique a un objectif similaire à celui des frais initiaux, mais ajoute un état par session et règle via des paiements AMP. Un expéditeur enverrait d’abord le paiement AMP, déposant des frais à chaque étape intermédiaire et fournissant un identifiant pour la session. L’expéditeur inclurait ensuite cet identifiant dans le message onion. Les limites connues de cette approche sont liées à la capacité de ne transférer des messages qu’aux pairs de canal et à la possibilité de relier tous les messages appartenant à la même session.

    • ● Limitation de débit fondée sur la rétropropagation: Cette approche, proposée par Bastien Teinturier, utilise un mécanisme de contre-pression capable statistiquement de remonter le spam jusqu’à sa source. Lorsque la limitation de débit par pair est atteinte, le nœud renvoie un message d’abandon à l’expéditeur, qui à son tour le relaie au dernier pair ayant transféré le message d’origine en divisant par deux sa limite de débit. Bien que le bon expéditeur soit identifié statistiquement, le mauvais pair pourrait être pénalisé. De plus, un attaquant pourrait falsifier le message d’abandon, abaissant les limites de débit des nœuds honnêtes.

    Enfin, Cestari a invité les développeurs LN à rejoindre la discussion, déclarant qu’une fenêtre reste disponible pour atténuer le problème avant que des attaques DDoS prolongées ne frappent le réseau, comme cela est récemment arrivé à Tor.

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou quand nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées postées depuis notre dernière mise à jour.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles versions ou d’aider à tester les versions candidates.

  • ● Bitcoin Core 31.0 est la dernière version majeure de l’implémentation de nœud complet prédominante du réseau. Les notes de version décrivent plusieurs améliorations importantes, dont l’implémentation de la conception du cluster mempool, une nouvelle option -privatebroadcast pour sendrawtransaction (voir le Bulletin #388), des données asmap intégrées de manière optionnelle dans le binaire pour la protection contre les attaques par eclipse, et une augmentation du -dbcache par défaut à 1024 Mio sur les systèmes disposant d’au moins 4096 Mio de RAM, parmi de nombreuses autres mises à jour.

  • ● Core Lightning 26.04 est une version majeure de cette implémentation populaire de nœud LN. Elle active le splicing par défaut, ajoute de nouvelles commandes splicein et spliceout, incluant un mode cross-splice qui cible un second canal comme destination d’un splice-out, repense bkpr-report pour les résumés de revenus, ajoute la recherche de chemins en parallèle et plusieurs corrections de bogues dans askrene, ajoute une option fronting_nodes à la RPC offer ainsi qu’une configuration payment-fronting-node, et supprime la prise en charge de l’ancien format onion. Consultez les notes de version pour davantage de détails.

  • ● LND 0.21.0-beta.rc1 est la première version candidate de la prochaine version majeure de ce nœud LN populaire. Les utilisateurs exploitant des nœuds avec l’option --db.use-native-sql sur un backend SQLite ou PostgreSQL doivent noter que cette version migre le magasin de paiements du format clé-valeur (KV) vers SQL natif, avec une possibilité de désactivation via --db.skip-native-sql-migration. Consultez les notes de version.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

  • ● Bitcoin Core #33477 met à jour la manière dont le mode rollback de la RPC dumptxoutset (voir le Bulletin #72) construit des vidages historiques de l’ensemble UTXO utilisés pour les instantanés assumeUTXO. Au lieu de faire revenir en arrière le chainstate principal en invalidant des blocs, Bitcoin Core crée une base de données UTXO temporaire, la fait revenir à la hauteur demandée, puis écrit l’instantané depuis cette base temporaire. Cela préserve le chainstate principal, éliminant la nécessité de suspendre l’activité réseau et le risque d’interférences liées à une bifurcation avec le rollback, au prix d’un espace disque temporaire supplémentaire et de vidages plus lents. Une nouvelle option in_memory conserve l’intégralité de la base de données UTXO temporaire en RAM, permettant des rollbacks plus rapides mais nécessitant plus de 10 Go de mémoire libre sur le réseau principal. Pour des rollbacks profonds, il est recommandé de ne pas utiliser de délai d’expiration RPC (bitcoin-cli -rpcclienttimeout=0) car cela peut prendre plusieurs minutes.

  • ● Bitcoin Core #35006 ajoute une option -rpcid à bitcoin-cli pour définir une chaîne personnalisée comme id de requête JSON-RPC au lieu de la valeur codée en dur par défaut de 1. Cela permet de corréler les requêtes et les réponses lorsque plusieurs clients effectuent des appels concurrents. L’identifiant est également inclus dans le journal de débogage RPC côté serveur.

  • ● BIPs #1895 publie BIP361, une proposition abstraite pour la migration post-quantique et l’extinction progressive des signatures historiques. En supposant qu’un schéma de signature post-quantique (PQ) distinct soit standardisé et déployé, elle décrit une migration par étapes s’éloignant des schémas de signature ECDSA/schnorr. La version actuelle de la proposition est divisée en deux phases. La phase A interdit l’envoi de fonds vers des adresses vulnérables au quantique, accélérant ainsi l’adoption de types d’adresses PQ. La phase B restreint les dépenses ECDSA/schnorr et inclut un protocole de sauvetage résistant au quantique pour empêcher le vol d’UTXO vulnérables au quantique.

  • ● BIPs #2142 met à jour BIP352, la proposition de BIP sur les silent payments, en ajoutant un vecteur de test d’envoi/réception pour un cas limite où la somme courante des clés d’entrée atteint zéro après deux entrées mais où la somme finale sur toutes les entrées n’est pas nulle. Cela détecte les implémentations qui rejettent trop tôt pendant la sommation incrémentale au lieu de sommer d’abord toutes les entrées.

  • ● LDK #4555 corrige la manière dont les nœuds de transfert appliquent max_cltv_expiry pour les chemins de paiement aveuglés. Ce champ est destiné à garantir qu’une route aveuglée expirée soit rejetée au saut d’introduction plutôt que d’être transférée à travers le segment aveuglé puis d’échouer plus près du destinataire. Auparavant, LDK comparait la contrainte à la valeur CLTV sortante du saut ; il vérifie désormais comme prévu l’expiration CLTV entrante.

  • ● LND #10713 ajoute des limites de débit par pair et globales de type token-bucket pour les messages onion entrants, abandonnant le trafic excédentaire à l’entrée avant qu’il n’atteigne le gestionnaire onion. Cela renforce la prise en charge récemment ajoutée par LND du transfert de messages onion (voir le Bulletin #396) contre les abus à fort volume provenant de pairs rapides. La séparation entre limite par pair et limite globale reflète les anciennes limites de bande passante du gossip dans LND (voir le Bulletin #370).

  • ● LND #10754 cesse de transférer un message onion lorsque le prochain saut choisi est le même pair que celui qui l’a livré, évitant un rebond immédiat sur la même connexion.