Le bulletin d’information de cette semaine évoque la suite de la discussion sur l’autorisation facultative aux nœuds d’activer le Full RBF, relaie une demande de commentaires sur un élément de conception du protocole de transport chiffré BIP324 version 2, résume une proposition pour attribuer de manière fiable les défaillances et les retards LN à des nœuds particuliers, et renvoie à une discussion sur une alternative à l’utilisation des sorties d’ancrage pour les HTLC LN modernes. Sont également incluses nos sections régulières avec ne liste des nouvelles versions logicielles et des release candidate, ainsi que les principaux changements apportés aux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Cohérence Mempool : Anthony Towns a lancé une discussion sur la liste de diffusion Bitcoin-Dev à propos des conséquences de la simplification de la configuration des politiques de Bitcoin Core pour le relais de transaction et l’acceptation de mempool, comme cela a été fait par l’ajout de l’option mempoolfullrbf à la branche de développement de Bitcoin Core (voir Newsletters #205, #208, #222, and #223). Il affirme que “cela diffère de ce que Core faisait dans le passé, en ce sens qu’auparavant, nous essayions de nous assurer qu’une nouvelle politique est bénéfique pour tout le monde (du moins aussi bénéfique que possible), puis l’avons activée dès qu’elle est mise en œuvre. Toutes les options qui ont été l’étaient soit pour contrôler l’utilisation des ressources de manière à ne pas [affecter] de manière significative la propagation des tx, soit pour permettre aux gens de revenir à l’ancienne configuration lorsque la nouvelle était controversé (par exemple, l’option -mempoolreplacement=0 de 0.12 à 0.18), soit enfin pour faciliter le test/débogage de l’implémentation. Donner aux gens la possibilité d’adopter un nouveau comportement de relais alors que nous ne sommes nous-même pas suffisamment confiants pour l’activer par défaut ne correspond pas à l’approche adoptée par le passé.»

    Towns se demande alors s’il s’agit d’une nouvelle direction de développement : “full RBF est controversé depuis des lustres, mais largement apprécié par les développeurs […] alors peut-être que c’est juste un cas particulier et non un précédent. Des gens qui proposeraient de mauvaises options par défaut, se heurteraient à beaucoup plus de résistance quand il s’agirait de fusionner leur code, malgré toutes les discussions sur les options laissées aux utilisateurs que nous avons en ce moment.” Mais, en supposant qu’il s’agisse d’une nouvelle direction, il évalue ainsi certaines conséquences potentielles de cette décision:

    • ● Il devrait être plus facile de fusionner les options de relais alternatives désactivées par défaut : si le fait de donner plus d’options aux utilisateurs est considéré comme préférable, de nombreux aspects de la stratégie de relais peuvent être configurés. Par exemple, Bitcoin Knots fournit une option de script de réutilisation de la pubkey (spkreuse) pour configurer un nœud afin qu’il refuse de relayer toute transaction qui réutilise une adresse.

    • ● Des politiques plus permissives nécessitent une acceptation généralisée ou un meilleur appairage : un nœud Bitcoin Core par défaut relaie les transactions avec huit pairs via des connexions sortantes, de sorte qu’au moins 30% du réseau doive prendre en charge une politique plus permissive avant qu’un nœud ait 95% de chances de trouver au moins un pair sélectionné au hasard qui prend en charge la même politique. Moins il y a de nœuds prenant en charge une politique, moins il est probable qu’un nœud trouve un homologue prenant en charge cette politique.

    • ● Un meilleur apparairage implique des compromis : les nœuds Bitcoin peuvent annoncer leurs capacités en utilisant le champ de services des messages P2P addr, addrv2, et messages de version, permettant aux nœuds ayant des intérêts communs de se trouver et de former des sous-réseaux (appelés preferential peering). Alternativement, les opérateurs de nœuds complets ayant des intérêts communs peuvent utiliser d’autres logiciels pour former des réseaux de relais indépendants (tels qu’un réseau entre nœuds LN). Cela peut rendre le relais efficace même lorsque seuls quelques nœuds mettent en œuvre une politique, mais les nœuds mettant en œuvre une politique rare sont plus faciles à identifier et à censurer. Cela oblige également les mineurs à rejoindre ces sous-réseaux et réseaux alternatifs, ce qui augmente la complexité et le coût de l’exploitation minière. Cela augmente la pression pour centraliser la sélection des transactions, ce qui facilite également la censure.

      De plus, les nœuds mettant en œuvre des politiques différentes de certains de leurs pairs ne pourront pas tirer pleinement parti des technologies telles que le relais de bloc compact et erlay pour minimiser la latence et la bande passante lorsque deux pairs disposent déjà de certaines des mêmes informations.

    Le message de Towns a reçu de multiples réponses perspicaces, et la discussion est toujours en cours au moment de la rédaction de cet article. Nous fournirons une mise à jour dans la newsletter de la semaine prochaine.

  • ● Identifiants de message BIP324 : Pieter Wuille a posté sur la liste de diffusion Bitcoin-Dev une réponse à la mise à jour du projet de spécification BIP324 pour la version 2 du protocole de transport chiffré P2P (v2 transport). Pour économiser la bande passante, le transport v2 permet de remplacer les noms de message de 12 octets du protocole existant par des identifiants d’1 octet seulement. Par exemple, le nom du message version , qui est rempli sur 12 octets, peut être remplacé par 0x00. Cependant, des noms de message plus courts augmentent le risque de conflit entre différentes propositions futures d’ajout de messages au réseau. Wuille décrit les compromis entre quatre approches différentes de ce problème et demande des avis sur le sujet à la communauté.

  • ● Attribution de l’échec du routage LN: les tentatives de paiement LN peuvent se solder par un échec pour diverses raisons, du destinataire final refusant de libérer la préimage de paiement à l’un des nœuds de routage temporairement hors ligne. Les informations sur les nœuds qui ont provoqués l’échec d’un paiement seraient extrêmement utiles aux participants pour éviter ces nœuds pour des paiements à venir, mais le protocole LN ne fournit aujourd’hui aucune méthode authentifiée pour permettre aux nœuds de routage de communiquer ces informations à un participant.

    Il y a plusieurs années, Joost Jager a proposé une solution (voir la Newsletter #51), qu’il a récemment mis à jour avec des améliorations et des détails supplémentaires. Le mécanisme proposé assurerait l’identification de la paire de nœuds entre lesquels un paiement a échoué (ou entre lesquels un message d’échec antérieur a été censuré ou s’est altéré). Le principal inconvénient de la proposition de Jager est qu’elle augmenterait considérablement la taille des messages en oignon LN en cas d’échecs si les autres propriétés LN restaient les mêmes, bien que la taille des messages en oignon en cas d’échec n’ait pas besoin d’être aussi grande si le nombre maximal de sauts LN a été diminué.

    Alternativement, Rusty Russell a suggéré qu’un participant pourrait utiliser un mécanisme similaire aux paiements spontanés où chaque nœud de routage reçoit un sat même si le paiement final échoue. Le participant pourrait alors identifier à quel saut le paiement a échoué en comparant le nombre de satoshis qu’il a envoyé au nombre de satoshis qu’il a reçus en retour.

  • ● Solution de contournement des sorties d’ancrage : Bastien Teinturier a publié sur la liste de diffusion Lightning-Dev une proposition d’utilisation des sorties d’ancrage avec plusieurs versions pré-signées de chaque HTLC à différents taux de frais. Les sorties d’ancrage ont été introduites avec le développement de la règle d’exclusion CPFP permettant d’ajouter des frais à une transaction via le mécanisme du CPFP d’une manière qui ne serait pas épinglable pour le protocole de contrat bipartite de LN. Toutefois, Teinturier note que l’utilisation de CPFP nécessite que chaque nœud LN conserve un pool d’UTXO non-LN prêts à être dépensés à tout moment. En comparaison, présigner plusieurs versions de HTLC, chacune avec des frais différents, permet de payer ces frais directement à partir de la valeur du HTLC –aucune gestion UTXO supplémentaire n’est requise, sauf dans les cas où aucun des frais présignés n’était suffisamment élevé.

    Il recherche le soutien d’autres développeurs LN sur l’idée de fournir plusieurs HTLC payants. Toutes les discussions à ce jour ont eu lieu sur sa propre PR.

Mises à jour et release candidate

Nouvelles versions et release candidate pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les release candidate.

  • ● LND 0.15.4-beta et 0.14.4-beta sont des versions de sécurité critiques qui contiennent un correctif du récent bogue pour un problème sur le traitement des blocs. Tous les utilisateurs doivent mettre à niveau.

  • ● Bitcoin Core 24.0 RC2 est une release candidate pour la prochaine version de l’implémentation de nœud complet la plus largement utilisée du réseau. Un guide de test est disponible.

    Avertissement : cette release candidate inclut l’option de configuration mempoolfullrbfqui, selon plusieurs développeurs de protocoles et d’applications, pourrait entraîner des problèmes pour les services marchands, comme décrit dans les newsletters#222 et #223. Optech encourage tous les services qui pourraient être affectés à évaluer la RC et à participer au débat public.

Changements principaux dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), et Lightning BOLTs.

  • ● Bitcoin Core #23927 limite getblockfrompeer sur les noeuds partiels à des hauteurs inférieures à la progression de la synchronisation actuelle du nœud. Cela empêche de se tirer une balle dans le pied en récupérant de futurs blocs rendant les fichiers de blocs du nœud inéligibles à l’élagage.

    Bitcoin Core stocke les blocs dans des fichiers d’environ 130 Mo, quel que soit l’ordre dans lequel il les reçoit. L’élagage supprimera les fichiers de blocs entiers, mais ne supprimera aucun fichier contenant un bloc non traité par la synchronisation. La combinaison d’une petite allocation de données et d’une utilisation répétée du RPC getblockfrompeer pourrait rendre plusieurs fichiers de blocs inéligibles à l’élagage et faire en sorte qu’un nœud élagué dépasse son allocation de données.

  • ● Bitcoin Core #25957 améliore les performances des réanalyses pour les portefeuilles de descripteurs en utilisant l’index de filtre de bloc (s’il est activé) pour ignorer les blocs qui ne dépensent pas ou ne créent pas d’UTXO pertinents pour le portefeuille.

  • ● Bitcoin Core #23578 utilise HWI et a récemment fusionné la prise en charge du BIP371 (voir la Newsletter #207) pour permettre la prise en charge de la signature externe pour les dépenses de chemin de clé taproot.

  • ● Core Lightning #5646 met à jour la mise en œuvre expérimentale des offres pour supprimer les clés publiques x-only (au lieu d’utiliser des clés publiques compressées, qui contiennent un octet supplémentaire). Il implémente également la transmission des blinded payments, un autre protocole expérimental. La description du PR avertit qu’elle “n’inclut pas la génération et le paiement de factures avec des paiements en aveugle”.

  • ● LND #6517 ajoute un nouveau RPC et un nouvel événement qui permettent à un utilisateur de surveiller le moment où un paiement entrant (HTLC) est entièrement verrouillé par la transaction d’engagement mise à jour pour refléter la nouvelle distribution du solde du canal.

  • ● LND #7001 ajoute de nouveaux champs à l’historique de transfert un RPC (fwdinghistory) indiquant quel partenaire de distribution nous a transféré un paiement (HTLC) et le partenaire à qui nous avons relayé le paiement.

  • ● LND #6831 met à jour l’implémentation de l’intercepteur HTLC (voir la Newsletter #104) pour rejeter automatiquement un paiement entrant (HTLC) si le client connecté à l’intercepteur n’a pas fini de le traiter dans un délai raisonnable. Si un HTLC n’est pas accepté ou rejeté avant son expiration, le partenaire de distribution devra forcer la fermeture du canal pour protéger ses fonds. La fusion de ce PR de rejet automatique avant expiration garantit que le canal reste ouvert. Le participant peut toujours essayer d’envoyer à nouveau le paiement.