Lettre d'information Bitcoin Optech n° 430

La lettre d’information de cette semaine résume les discussions en cours concernant l’utilisation du « TCP hole punching » pour rendre accessibles les nœuds situés derrière des routeurs domestiques et présente un projet de BIP visant à normaliser les politiques de dépense que les cosignataires appliquent lorsqu’ils émulent des clauses restrictives. Vous y trouverez également nos rubriques habituelles résumant les propositions et les discussions concernant la modification des règles de consensus de Bitcoin, annonçant les nouvelles versions et les versions candidates, et décrivant les changements notables apportés aux logiciels d’infrastructure Bitcoin les plus utilisés.

Actualités

• ● Poursuite des discussions sur le TCP hole punching pour les nœuds domestiques : Suite à

notre résumé de mai du fil de discussion « Delving Bitcoin » de 0xB10C sur l’utilisation du « hole punching » pour permettre aux nœuds situés derrière des routeurs domestiques d’accepter des connexions les uns des autres, 0xB10C a indiqué que les travaux avaient repris sur une spécification et une implémentation expérimentale dans Bitcoin Core. Les nœuds domestiques ne peuvent généralement établir que des connexions sortantes, et l’activation par défaut du mappage de ports NAT-PMP dans Bitcoin Core 30.0 n’a pas permis de rendre beaucoup plus d’entre eux accessibles, comme on l’espérait. Le « hole punching », qui consiste pour deux nœuds domestiques à ouvrir des connexions l’un vers l’autre au même moment afin que chaque routeur laisse passer le trafic de l’autre, constituerait un complément « au mieux » à la redirection de ports. Un plus grand nombre de nœuds honnêtes accessibles rendrait la tâche plus difficile aux attaquants, dont les nœuds sont plus faciles à atteindre, pour saturer les créneaux de connexion sortants d’un nœud.

0xB10C a récapitulé les quatre conceptions discutées jusqu’à présent et a proposé une nouvelle option ne nécessitant aucun coordinateur : un nœud annonce son adresse « punchable » et une clé publique temporaire dans un nouveau type addr v2, et chaque paire de nœuds déduit la même liste de candidats et le même timing de « hole punching » à partir de leur secret partagé et de chaque nouveau bloc. En réponse à l’objection d’Anthony Towns selon laquelle un attaquant pourrait inonder le système d’adresses réelles, et après avoir constaté par la suite que les nœuds inaccessibles reçoivent ces annonces de manière bien moins fiable que les nœuds à l’écoute, il a esquissé une alternative de type « tableau d’affichage » dans laquelle les nœuds à l’écoute conservent les adresses vérifiées des nœuds d’origine à la recherche d’un pair.

Towns s’est demandé si les connexions entrantes aléatoires aidaient réellement les nœuds d’origine et a fait valoir que le « hole punching » permettait plus facilement à un attaquant d’atteindre directement des nœuds honnêtes, tout en ne contribuant guère à garantir une connexion avec un nœud honnête. Il a estimé qu’un attaquant diffusant environ 10 000 adresses serait rapidement repéré par la plupart des nœuds honnêtes et a suggéré des connexions de courte durée avec des pairs aléatoires comme alternative à moindre risque . Jonathan Harvey-Buschel a cité des données montrant que les nœuds honnêtes sont moins accessibles que ceux contrôlés par des attaquants et s’est prononcé en faveur d’une coordination via le service Tor propre à chaque nœud. Towns a ensuite demandé si les récentes vulnérabilités du protocole TCP et d’autres protocoles faisaient du refus des connexions entrantes le paramètre par défaut le plus sûr pour les utilisateurs particuliers. La discussion se poursuit.

• ● Projet de BIP pour des politiques de dépenses standardisées des cosignataires : Luke Carriere

a publié sur Delving Bitcoin sa proposition visant à standardiser les politiques de dépenses appliquées par les cosignataires lors de l’émulation de clauses restrictives. Plusieurs conceptions récentes, notamment celles de Johan Halseth concernant les cosignataires aveugles et la délégation de code de chaîne, définissent chacun leur propre politique ; ainsi, un portefeuille conçu pour l’une ne peut pas utiliser un cosignataire ou un oracle conçu pour une autre. Carriere ne demande pas de numéro BIP pour ce projet et a demandé s’il s’agissait du bon niveau pour la normalisation.

Le projet suit plusieurs principes de conception :

Tout ce qui peut être mis en œuvre par le script Bitcoin doit l’être à ce niveau, les politiques de cosignataires ne définissant que ce que le script ne peut pas faire.

• Au moins un chemin de dépense ne nécessitant aucun cosignataire doit toujours être

disponible.

• La manière dont un cosignataire vérifie une dépense, ainsi que ce qui garantit son honnêteté, relèvent de

profils modulables choisis en fonction de chaque politique.

• Les cosignataires doivent accepter les attestations d’oracle au format

DLC afin que les oracles déjà disponibles puissent être réutilisés sans aucune modification.

Une politique comporte cinq parties. La sortie définit le descripteur Taproot qui contient les fonds, le groupe de cosignataires indique quels cosignataires participent et combien doivent signer, les modèles énumèrent les transactions que les cosignataires peuvent signer avec leurs sorties exactes, les conditions précisent ce qui doit être vrai avant que chaque modèle puisse être signé, et les profils définissent le mode de vérification, les formats de preuve et tout mécanisme de responsabilité. Certaines questions restent en suspens, notamment celle de savoir s’il faut utiliser JSON ou TLV pour la sérialisation, si la vérification aveugle doit être spécifiée dès maintenant ou s’il vaut mieux attendre d’avoir acquis davantage d’expérience en matière de mise en œuvre , s’il faut spécifier le format d’attestation des déclarations dans la proposition ou dans les spécifications DLC, et si la voie de secours doit être soumise à un verrouillage temporel.

Au cours de la discussion qui a suivi, PREDGE a souligné que l’un des profils de preuve , appelé `statement-v0`, ne dispose pas d’un indicateur de finalité, ce qui signifie qu’un cosignataire pourrait agir sur la base d’une attestation provisoire corrigée ultérieurement. De plus, tehiyadu a déclaré que le hachage de politique devait respecter strictement la sémantique du vérificateur afin d’empêcher que différentes implémentations n’acceptent les mêmes octets tout en appliquant des conditions différentes. Carriere s’est déclaré d’accord avec ces deux points et a indiqué qu’il ajouterait un indicateur de finalité et préciserait les règles du vérificateur.

Modification du consensus

*Une rubrique mensuelle résumant les propositions et les discussions concernant la modification des règles de consensus de Bitcoin.*

• ● Poursuite de la discussion sur le BIP54 : Antoine Riard a publié un message sur

la liste de diffusion Bitcoin-Dev pour exposer son point de vue sur l’état d’avancement du soft fork de nettoyage du consensus (BIP54). L’interdiction des transactions dont la taille après suppression du « witness » est exactement de 64 octets reste la règle la plus contestée. Une implémentation Bitcoin Core est en cours d’examen et de test ; il s’agit de l’implémentation de référence mentionnée dans le BIP (Bitcoin Core #35793). La pull request active les nouvelles règles sur regtest sans activation sur le réseau principal. Il a également mentionné le travail d’interopérabilité dans btcd (btcd #2537) et a indiqué qu’à sa connaissance, aucune implémentation de libbitcoin n’existait. Selon lui, il reste à procéder à davantage d’examens et de tests, à rédiger de la documentation afin que les portefeuilles soient informés de la limite proposée de 2 500 opérations de signature dans le script pré-SegWit et de la règle des 64 octets, puis, seulement par la suite, à mettre en place la logique d’activation. S’exprimant uniquement en son nom propre, il a estimé qu’il serait réaliste de commencer à envisager l’activation au cours du second semestre 2027 si la communauté s’accorde d’ici là.

Pieter Wuille a mis à jour son fil de discussion « Delving Bitcoin » sur la manière dont les deux règles de horodatage du BIP54 limitent la longueur de la chaîne (voir la Lettre d’information n° 425). Le message en tête du fil inclut désormais la formule exacte pour la borne inférieure du travail, et cette formule ainsi que l’approximation décimale sont désormais prouvées dans le code Lean lié.

Riard a répondu à une objection soulevée lors de la conception du BIP54 : selon laquelle la correction du bug de décalage temporel rendrait impossible, pour le reste de l’histoire de Bitcoin, un changement de consensus du type des forward blocks proposés par Mark Friedenbach. Comme le correctif limite la manipulation des horodatages plutôt que de la supprimer, une proposition de « blocs avancés » beaucoup plus restreinte pourrait encore être mise en œuvre. Il a estimé que la fenêtre de 7 200 secondes toujours autorisée par la correction pourrait réduire la difficulté d’environ 0,60 % par période de réajustement, et augmenter le taux de blocs d’environ autant, ce qui est bien en deçà de l’augmentation de capacité prévue par la proposition initiale. Riard a également fait valoir que l’idée n’était pas viable, même avec les anciennes règles : les validateurs traiteraient les transactions une première fois sur la chaîne principale, puis une seconde fois lorsqu’elles seraient synchronisées sur la chaîne de compatibilité, pour les mêmes frais, à moins que les utilisateurs ne paient deux fois, et les nœuds n’ayant pas effectué la mise à jour devraient tout de même télécharger les données supplémentaires. Riard proposera une brève note de bas de page dans le BIP54 pour exposer cet argument, et demandera à Friedenbach de présenter des contre-arguments.

• ●

Prototype de protection contre la relecture avec option d’adhésion : Sjors Provoost a donné suite au fil de discussion « Delving Bitcoin » concernant la protection contre la relecture avec option d’adhésion en cas de scission de la chaîne (voir la Lettre d’information n° 420 ) avec un prototype utilisant une nouvelle version de « witness ». Une annexe dont la charge utile commence par l’octet 0x01 désigne un bloc par une hauteur de 4 octets, et chaque signature sur cette entrée s’engage sur le hachage du bloc sur la chaîne souhaitée. Le hachage lui-même n’est pas présent dans la transaction. Il a estimé le coût supplémentaire à 1,75 vbytes. Le bloc désigné doit dater d’au moins 100 blocs, soit le même horizon que la maturité de la coinbase. Il a indiqué que si le hashrate était réparti de manière égale, le délai d’attente avant que les pièces puissent être divisées serait de deux jours au pire, car la règle ne doit s’appliquer que d’un seul côté. Il a suggéré de publier la version « witness » en même temps qu’une autre proposition qui en nécessite une, telle que CISA (BIP460), BIP360 , ou une sortie de type P2TRv2

avec un chemin de clé pouvant être désactivé ultérieurement.

Anthony Towns a répondu qu’une nouvelle version « witness » était inutile, et qu’un nouvel encodage de clé publique pour la vérification des signatures Taproot, à la manière du BIP118, suffirait. Provoost a répondu qu’il avait envisagé cet encodage et qu’il le considérait comme un « hack », et que, d’après ce qu’il en comprenait, cela ne fonctionnerait pas pour une dépense via un chemin de clé.

Moonsettler s’est demandé s’il était souhaitable d’exiger 100 blocs dans le cas d’une scission où cette fonctionnalité serait la plus importante, et a suggéré de conserver ce délai en tant que règle de politique pouvant être assouplie. Provoost a répondu qu’une fois que les pièces passent du côté le plus rapide et accumulent des confirmations, le côté le plus lent n’a plus besoin de cette protection. Provoost a également écrit qu’il s’attendait à ce que la règle soit déployée avant un hard fork controversé, afin que les deux branches l’héritent et qu’aucune des deux ne puisse s’en débarrasser facilement : le hachage du bloc ne figure que dans le message de signature, donc supprimer la règle impliquerait de modifier la sérialisation des transactions pour y inclure le hachage.

• ● QSAVE pour les pièces non migrées : James Tagg a publié sur la

liste de diffusion Bitcoin-Dev cinq projets de BIP pour QSAVE (Quantum Secure Asset Verification and Escrow), une transition post-quantique qui ne brûle pas les pièces. Il les a décrits comme une alternative au BIP361 et à Hourglass. Du point de vue de l’application, qui pourrait être activée à tout moment sous forme de soft fork, toute entrée ne figurant pas dans un registre des types post-quantiques connus serait traitée comme non migrée, y compris les types de scripts inconnus et futurs. Une entrée non migrée devrait tout de même satisfaire à son script de verrouillage, ainsi qu’à un deuxième facteur : soit une preuve à connaissance nulle démontrant qu’une seule graine dérive à la fois le script de dépense et une clé post-quantique, soit une liaison post-quantique engagée avant une date butoir. Si une entrée non migrée dans une transaction ne dispose pas de ce deuxième facteur, chaque sortie dépensable doit être une sortie de récupération. Dans QSAVE, il n’y a pas de date d’expiration, donc l’absence du deuxième facteur ne détruit pas la pièce. Une preuve sur la chaîne peut toujours la dépenser directement, sans tiers. Sinon, il a décrit un processus hors chaîne de gestion des biens perdus, dont il a placé le traitement juridique et économique en dehors du consensus, dans lequel un ensemble de dépositaires décentralisés détenait les sorties de récupération, avec un dépositaire de secours et un contrôleur disposant d’un droit de veto, et les fonds pouvaient générer un rendement prudent de 0,5 % reversé à des œuvres caritatives. Les ébauches précisent également des filigranes de pré-coupe, une clé ML-DSA-87 optionnelle qu’il a appelée QD5, et une feuille de dépense zk-STARK pour les sorties BIP360 (P2MR) .

• ● Preuve de dépréciation pour les sorties non migrées : bitKingAE

a publié sur Delving Bitcoin une ébauche visant à réduire les sorties exposées aux attaques post-quantiques, telles que les premières pièces P2PK , qui ne sont pas déplacées pendant un délai de grâce. Une fois ce délai expiré, la valeur de la sortie diminuerait selon un calendrier lié à la hauteur du bloc. Les satoshis perdus seraient brûlés ou versés sous forme de récompenses de minage plutôt que de voir les pièces gelées ou laissées à la disposition de quiconque capable de produire une signature. L’ exemple donné dans le message correspondait à un faible pourcentage du solde tous les 50 000 blocs. Vinicius Cestari a répondu en soulevant trois objections : un attaquant quantique peut attendre la fin du délai de grâce et balayer les sorties exposées avant que la dépréciation n’ait eu d’effet significatif ; une amélioration soudaine des attaques quantiques pourrait les vider encore plus tôt ; et ce barème réduit le solde d’ un détenteur passif, y compris celui dont les clés ont déjà été volées.

• ● Censure des paquets BIP300 : Ori Newman a fait valoir sur la

liste de diffusion Bitcoin-Dev qu’un mineur disposant de 26 % du hashrate peut censurer indéfiniment un paquet de retrait valide dans la proposition relative aux drivechains (BIP300). Il a écrit que si ce mineur détenant 26 % de la puissance de hachage envoie une ALARME dans chaque bloc qu’il mine, chacun de ces blocs réduit de 1 le score de chaque paquet en attente. Si les 74 % restants de la puissance de hachage votent en faveur d’un ensemble dans chaque bloc, son score attendu serait de 12 624 à la fin de la fenêtre de 26 300 blocs, ce qui est inférieur aux 13 150 requis. Il a suggéré d’interdire l’ALARM et tout autre vote négatif, ce qui rétablirait l’hypothèse d’une majorité honnête : un lot soutenu par 51 % de la puissance de hachage serait presque certainement adopté, et un lot soutenu par 49 % serait presque certainement rejeté. Si la règle actuelle est intentionnelle, il a demandé que le BIP stipule plutôt une hypothèse de majorité honnête de 75 %. Il a qualifié cela de forte divergence par rapport au modèle de sécurité de Bitcoin, et a déclaré qu’un argument en sa faveur est qu’il serait plus difficile pour un attaquant disposant de moins de 75 % du hashrate de voler des fonds.

Versions et versions candidates

*Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Pensez à effectuer la mise à jour vers les nouvelles versions ou à contribuer au test des versions candidates.*

• ● LND v0.21.6-beta et v0.20.7-beta sont des versions de sécurité

pour les branches 0.21 et 0.20 de cette implémentation populaire de nœud LN . Elles incluent toutes deux la mesure corrective relative à la vulnérabilité du noyau Linux CVE-2026-98432 décrite ci-dessous sous LND #11456. Les opérateurs Linux doivent effectuer la mise à jour, désactiver MPTCP sur l’hôte pour protéger les autres services, et installer un noyau corrigé, car la mesure corrective de LND ne résout pas la vulnérabilité sous-jacente.

• ● Core Lightning 26.06.10 est une version de sécurité de cette implémentation populaire de nœud LN

. Elle corrige des vulnérabilités liées au double financement, au splicing, à la résolution HTLC sur la chaîne, aux contrôles d’accès et à d’autres composants. Le code source des correctifs de sécurité est disponible, tandis que les tests associés sont temporairement suspendus afin de laisser aux utilisateurs davantage de temps pour effectuer la mise à jour. Le projet recommande vivement de procéder à cette mise à jour.

-

● BTCPay Server 2.4.7 est une version de sécurité de ce processeur de paiement auto-hébergé. Elle corrige 85 failles de sécurité signalées par le programme OSS Scanner d’Anthropic, notamment des problèmes liés aux limites de paiement, à l’accès aux données d’autres boutiques, à l’authentification et à l’épuisement des ressources . Elle corrige également des problèmes liés à la comptabilité des paiements et à la fiabilité. La mise à jour est vivement recommandée, en particulier pour les serveurs partagés par plusieurs commerçants.

Modifications notables du code et de la documentation

*Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet (HWI), Rust Bitcoin, BTCPay Server, BDK, les propositions d’amélioration de Bitcoin (BIP), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition et BINANAs.*

• ● Bitcoin Core #36539 rétablit le format PSBTv0 pour les transactions non signées

et les augmentations de frais exportées depuis l’interface graphique. Bitcoin Core 32.1 exportait ces PSBT en utilisant la version 2, ce qui empêchait les utilisateurs de les signer avec des outils ne prenant en charge que la version 0. Le workflow distinct avec signataire externe configuré avec `-signer` (voir la Lettre d’information n° 138) continue d’utiliser PSBTv2 ; ces utilisateurs ont donc besoin d’un signataire externe qui le prenne en charge, tel que HWI 2.1.0 ou une version ultérieure.

• ● Bitcoin Core #35714 corrige un bug qui permettait au nœud de mettre à jour son

index de blocs et sa base de données UTXO après avoir échoué à vider les données de bloc ou d’annulation sur le disque. Bien que cet échec ait déclenché l’arrêt du nœud, le code gérant ces écritures pouvait encore mettre à jour les bases de données avant l’arrêt du nœud. Si ces mises à jour aboutissaient, les bases de données pouvaient enregistrer un état pour lequel le bloc correspondant ou les données d’annulation n’avaient pas encore été sauvegardés en toute sécurité. Cela pouvait rendre l’état local du nœud incohérent et compliquer la récupération. Le code ignore désormais ces écritures dans la base de données lors d’une tentative de vidage ayant échoué. Cela vient compléter les protections antérieures relatives à l’ordre de vidage pour les index optionnels, abordées dans la lettre d’information n° 414.

• ● Bitcoin Core #35492 corrige un bug pour lequel `bitcoin-wallet dump` (voir la

lettre d’information n° 130) pouvait signaler une réussite après avoir écrit une exportation de portefeuille incomplète. Auparavant, la commande vérifiait si elle pouvait ouvrir le fichier de destination, mais ne détectait pas les échecs d’écriture ultérieurs, tels que le manque d’espace disque. Par conséquent, les utilisateurs pouvaient croire à tort que l’exportation était terminée, pour finalement découvrir des données manquantes lorsqu’ils tentaient de restaurer le portefeuille. Désormais, la commande vérifie l’écriture, la vidange et la fermeture du fichier. Elle signale les échecs et supprime les fichiers de sauvegarde incomplets.

• ● Les BIP n° 2205, 2210 et 2212 ajoutent trois projets de

spécifications pour l’agrégation de signatures entre plusieurs entrées. Le BIP 458 spécifie l’agrégation partielle non interactive, combinant `n` les signatures existantes du BIP 340 en `32 × (n + 1)` octets au lieu de `64 × n` octets. Le BIP459 spécifie DahLIAS, un protocole interactif qui produit une seule signature agrégée de 64 octets pour plusieurs clés et messages. Le BIP460 propose d’utiliser ces schémas pour les dépenses « keypath » des nouvelles sorties « witness-version-2 » , tout en conservant des signatures individuelles pour les dépenses de type « scriptpath » et en permettant aux entrées de type « keypath » de se désengager. Depuis que la proposition a été abordée dans la Lettre d’information n° 417 , les entrées désengagées ont été modifiées pour utiliser des signatures BIP341 ordinaires sans marqueur spécial, ce qui permet aux portefeuilles d’ adopter le nouveau type de sortie tout en réutilisant leur logique de signature existante. Cela permettrait de réduire le poids et les frais des transactions comportant plusieurs entrées participantes, y compris les coinjoins et les payjoins . Le déploiement de l’agrégation de transactions proposée nécessiterait un soft fork. Le BIP460 ne précise pas le mécanisme d’activation ni les paramètres.

• ● Core Lightning #9419 ajoute un champ facultatif `failure_reason` au

`listforwards` RPC et aux `forward_event` notifications pour les tentatives de transfert ayant échoué localement . Auparavant, plusieurs problèmes distincts partageaient le même code d’échec de protocole, ce qui rendait difficile pour les opérateurs de déterminer pourquoi le transfert avait échoué. Le nouveau champ permet de distinguer les causes telles que une liquidité sortante insuffisante, un pair sortant hors ligne et des limites sur le nombre ou la valeur totale des HTLC en attente.

• ● Core Lightning #9592 met à jour `xpay` (voir la lettre d’information n° 330)

afin d’éviter qu’un nœud de transfert ne traite le reste d’un paiement après avoir renvoyé deux fois une `unknown_next_peer`. Auparavant, chaque échec n’excluait que le canal concerné ; ainsi, des tentatives successives pouvaient continuer à sélectionner d’autres canaux via le même nœud jusqu’à l’expiration du délai de réessai du paiement. Désormais, après le deuxième échec provenant du même nœud, `xpay` celui-ci est exclu de la couche de routage `askrene` . Cette heuristique peut exclure des canaux utilisables, mais limite les tentatives répétées via le même nœud.

• ● LDK #5089 met à jour l’augmentation des frais lors des fermetures forcées de canaux comportant des

sorties d’ancrage. Si LDK ne parvient pas à obtenir les fonds nécessaires pour une transaction enfant CPFP qui dépense une sortie d’ancrage , il diffuse désormais uniquement la transaction d’engagement. Auparavant, cet échec pouvait empêcher la diffusion des deux transactions, retardant ainsi la récupération des fonds du canal. L’engagement inclut déjà des frais, qui peuvent encore être suffisants pour la confirmation si l’estimation des frais était prudente ou si la demande sur le réseau diminue. Cependant, cette solution de secours exclut les transactions d’engagement sans frais, qui nécessitent une transaction enfant payante pour être relayées. Le problème a été signalé par Project Loupe.

• ● LND #11456 désactive par défaut les écouteurs Multipath TCP (MPTCP) afin d’

atténuer la vulnérabilité CVE-2026-98432, une faille du noyau Linux pour laquelle l’exécution de code à distance a été démontrée à l’aide de MPTCP. Go 1.24 et les versions ultérieures activent ces écouteurs par défaut sur les systèmes Linux pris en charge, ce qui pourrait exposer les opérateurs LND même s’ils ne configurent pas explicitement MPTCP. La modification définit `multipathtcp=0` les paramètres par défaut de Go pour LND. Cela bloque la voie d’exploitation démontrée via les écouteurs de LND, mais ne corrige pas le bug sous-jacent du noyau. Les systèmes concernés nécessitent toujours un noyau corrigé. Les opérateurs utilisant des binaires existants peuvent appliquer la même mesure de protection en redémarrant LND avec la variable d’environnement `GODEBUG=multipathtcp=0`.

• ● LND #11357 renforce la validation des factures BOLT11 conformément aux BOLT

#1357 (voir la Lettre d’information n° 428). Au lieu d’utiliser le premier et d’ignorer les autres, le système rejette désormais les champs de secret de paiement en double, ce qui évite toute ambiguïté entre les analyseurs syntaxiques qui sélectionnent des occurrences différentes. Cette mesure s'appuie sur le rejet antérieur des hachages de paiement en double (voir la lettre d’information n° 425). Les tests ajoutés par la mise à jour de la spécification ont également révélé que les exigences existantes n’étaient pas appliquées. Le décodeur rejette désormais les longueurs incorrectes lors de l’analyse du hachage de paiement, du hachage de description, du secret de paiement et de la clé publique du destinataire, au lieu de considérer ces champs comme absents. Auparavant, un champ de clé publique du destinataire de taille incorrecte pouvait amener LND à se rabattre sur la récupération de la clé à partir de la signature. Pour les factures contenant une clé publique du destinataire explicite, une signature ECDSA à faible S est également requise. Cependant, cette restriction ne s’applique pas lorsque la clé publique est récupérée à partir de la signature (voir la Lettre d’information n° 381).

• ● LND #11413 accélère le nettoyage au démarrage des résultats de paiements sortants stockés

sur les nœuds utilisant SQLite ou PostgreSQL. En fonctionnement normal, le nœud accumule un résultat pour chaque tentative HTLC résolue et initiée localement. Au démarrage, il supprime les résultats qui ne sont plus nécessaires. Auparavant, la lecture et la suppression individuelles des entrées nécessitaient des allers-retours répétés vers la base de données, ce qui pouvait faire durer le nettoyage plusieurs heures sur un nœud très sollicité utilisant PostgreSQL à distance. Désormais, le nettoyage regroupe les opérations sur la base de données tout en conservant les résultats nécessaires à la reprise des paiements en attente.

• ● LND #11151 ajoute des vérifications concernant les taux de frais d’engagement excessifs et les

soldes initiaux insuffisants lors de l’acceptation de canaux entrants. LND rejette désormais tout taux de frais proposé supérieur à la plus grande des deux valeurs suivantes : dix fois son estimation sur trois blocs ou 100 sat/vbyte. Il applique également la règle de réserve initiale de BOLT2 et rejette séparément les canaux pour lesquels le solde initial d’aucune des parties ne dépasse la réserve que cette partie doit maintenir. Bien que l’initiateur paie les frais d’engagement, des frais excessifs peuvent épuiser son solde utilisable, gaspillant ainsi la capacité de canal en attente du destinataire lors de l’ouverture et laissant derrière lui un canal inutilisable une fois la transaction de financement confirmée. Cela complète les vérifications du taux de frais minimum abordées dans la lettre d’information n° 429.

• ● Rust Bitcoin #7067 étend les fonctions d’aide au hachage de signature Taproot

(sighash) pour accepter une annexe facultative et, pour les dépenses de type scriptpath, la position en opcode du dernier OP_CODESEPARATOR exécuté avant la vérification de la signature. Ces deux éléments affectent le message auquel une signature se rattache. Auparavant, ces fonctions de commodité supposaient l’absence d’annexe et l’absence d’exécution `OP_CODESEPARATOR`; ainsi, les appelants gérant de telles dépenses devaient utiliser la fonction sighash plus générale pour éviter de produire un résumé incorrect. Les fonctions d’aide acceptent désormais ces valeurs directement, bien que les appelants doivent toujours déterminer la position du séparateur. Les appelants gérant des dépenses sans annexe ni `OP_CODESEPARATOR` peuvent passer `None` pour les nouveaux arguments afin de conserver le comportement précédent. Voir la Newsletter n° 427 pour les modifications associées de l’API `sighash` concernant les dépenses héritées et SegWit v0 .