Le bulletin de cette semaine décrit une proposition permettant au LN de supporter des frais initiaux et de rétention basés sur des sorties brûlables, résume la discussion concernant les testnets 3 et 4 (incluant une proposition de hard fork), et annonce un plan pour commencer à relayer certaines transactions contenant des annexes taproot. Sont également incluses nos sections régulières résumant des questions et réponses sélectionnées du Bitcoin Stack Exchange, annonçant de nouvelles versions et versions candidates, et décrivant des changements notables dans des projets d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Frais initiaux et de rétention du LN utilisant des sorties brûlables : John Law a publié sur Delving Bitcoin le résumé d’un document qu’il a écrit concernant un protocole que les nœuds peuvent utiliser pour facturer deux types supplémentaires de frais pour le transfert de paiements. Un frais initial serait payé par le dépensier final pour compenser les d’allocations concurrentes disponibles dans un canal pour faire respecter les HTLCs). Des frais de rétention seront payés par tout nœud qui retarde le règlement d’un HTLC ; le montant de ces frais augmenterait avec la longueur du retard jusqu’à ce que le montant maximum soit atteint au moment de l’expiration de l’HTLC. Son post et son document citent plusieurs discussions antérieures sur les frais initiaux et de rétention, telles que celles résumées dans les Bulletins #86, #119, #120, #122, #136, et #263.

    Le protocole proposé s’appuie sur les idées du protocole de résolution de paiement offchain (OPR) de Law (voir le Bulletin #329), qui fait en sorte que chaque co-propriétaire de canal alloue 100% du montant des fonds en jeu (donc 200% au total) à une sortie brûlable que l’un d’eux peut détruire unilatéralement. Les fonds en jeu dans ce cas sont les frais initiaux plus les frais de rétention maximum. Si les deux parties sont plus tard satisfaites que le protocole a été correctement suivi, par exemple que tous les frais ont été correctement payés, elles retirent la sortie brûlable des futures versions de leurs transactions offchain. Si l’une des parties n’est pas satisfaite, elles ferment le canal et détruisent les fonds brûlables. Bien que la partie insatisfaite perde des fonds dans ce cas, l’autre partie également, empêchant l’une ou l’autre des parties de bénéficier d’une violation du protocole.

    Law décrit le protocole comme une solution pour les attaques de blocage de canal, une faiblesse dans le LN décrite pour la première fois il y a presque une décennie qui permet à un attaquant de prévenir presque sans coût l’utilisation par d’autres nœuds de certains ou de tous leurs fonds. Dans une réponse, il a été noté que l’ajout de frais de rétention pourrait rendre les factures de rétention plus durables pour le réseau.

  • ● Discussion sur les testnets 3 et 4 : Sjors Provoost a publié sur la liste de diffusion Bitcoin-Dev pour demander si quelqu’un utilisait encore testnet3 maintenant que testnet4 était disponible depuis environ six mois (voir le Bulletin #315). Andres Schildbach a répondu avec l’intention de continuer à utiliser testnet3 dans la version testnet de son portefeuille populaire pendant au moins un an. Olaoluwa Osuntokun a noté que testnet3 a récemment été beaucoup plus stable que testnet4. Il a illustré son point en incluant des captures d’écran des arbres de blocs pour les deux testnets prises depuis le site web Fork.Observer. Ci-dessous, trouvez notre propre capture d’écran montrant l’état de testnet4 au moment de la rédaction :

    Fork Monitor montrant l'arbre des blocs sur testnet4 le 2025-03-25

    Après le post d’Osuntokun, Antoine Poinsot a commencé un fil séparé pour se concentrer sur les problèmes de testnet4. Il dit que les problèmes de testnet4 sont une conséquence de la règle de réinitialisation de la difficulté. Cette règle, qui s’applique uniquement au testnet, permet à un bloc d’être valide avec une difficulté minimale si son temps d’en-tête est 20 minutes plus tard que son bloc parent. Provoost donne plus de détails sur le problème. Poinsot propose un hard fork de testnet4 pour supprimer la règle. Mark Erhardt suggère une date pour le fork : le 08-01-2026.

  • ● Plan pour relayer certains annexes de taproot : Peter Todd a annoncé à la liste de diffusion Bitcoin-Dev son plan pour mettre à jour son nœud basé sur Bitcoin Core, Libre Relay, pour commencer à relayer les transactions contenant des annexes taproot si elles suivent des règles particulières :

    • Préfixe 0x00 : “toutes les annexes non vides commencent par l’octet 0x00, pour les distinguer des annexes [futures] pertinentes pour le consensus.”

    • Tout ou rien : “Toutes les inputs ont une annexe. Cela garantit que l’utilisation de l’annexe est sur une base volontaire, prévenant les attaques de fixation de transaction dans les protocoles multi-parties.”

    Le plan est basé sur une pull request de 2023 par Joost Jager, qui était elle-même basée sur une discussion précédente commencée par Jager (voir le Bulletin #255). Dans les mots de Jager, la précédente pull request “limit[ait] également la taille maximale des données d’annexe non structurées à 256 octets […] protégeant quelque peu les participants d’une transaction multi-parties qui utilise l’annexe contre l’inflation de l’annexe.” La version de Todd n’inclut pas cette règle ; il croit que “l’exigence d’opter pour l’utilisation de l’annexe devrait être suffisante”. Si ce n’est pas le cas, il décrit un changement de relais supplémentaire qui pourrait prévenir l’épinglage de contrepartie.

    À l’heure actuelle, personne dans le fil de discussion actuel de la liste de diffusion n’a décrit comment ils s’attendent à ce que l’annexe soit utilisée.

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 plus votées postées depuis notre dernière mise à jour.

Mises à jour et versions candidates

Nouvelles mises à jour et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● Bitcoin Core 29.0rc2 est une version candidate pour la prochaine mise-à-jour majeure du nœud complet prédominant du réseau. Veuillez consulter le guide de test de la version 29.

  • ● LND 0.19.0-beta.rc1 est une version candidate pour ce nœud LN populaire. L’une des principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de frais basé sur RBF pour les fermetures coopératives décrit ci-dessous dans la section des changements de code notables.

Changements de code et de documentation notables

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

  • ● Bitcoin Core #31603 met à jour le parseur ParsePubkeyInner pour rejeter les clés publiques avec des espaces blancs au début ou à la fin, alignant le comportement de parsing avec le projet rust-miniscript. Il n’aurait pas dû être possible d’ajouter accidentellement des espaces blancs auparavant en raison de la protection du checksum du descripteur. Les commandes RPC getdescriptorinfo et importdescriptors renvoient désormais une erreur si le fragment de clé publique d’un descripteur contient de tels espaces blancs.

  • ● Eclair #3044 augmente le nombre minimum par défaut de confirmations pour la sécurité des canaux contre les réorganisations de blocs de 6 à 8. Il supprime également l’échelle de cette valeur basée sur le montant du financement du canal parce que la capacité du canal peut être modifiée de manière significative lors du splicing, convaincant le nœud d’accepter un faible nombre de confirmations pour ce qui est en réalité une grande montant d’argent en jeu.

  • ● Eclair #3026 ajoute le support pour les portefeuilles Bitcoin Core utilisant des adresses Pay-to-Taproot (P2TR), y compris les portefeuilles en observation gérés par Eclair, comme base pour l’implémentation de canaux taproot simples. Les scripts P2WPKH sont toujours nécessaires pour certaines transactions de fermeture mutuelle, même lors de l’utilisation d’un portefeuille P2TR.

  • ● LDK #3649 ajoute le support pour payer les Prestataires de Services Lightning (LSPs) avec des offres BOLT12 en ajoutant les champs nécessaires. Auparavant, seules les options de paiement BOLT11 et onchain étaient activées. Cela a également été proposé dans le BLIPs #59.

  • ● LDK #3665 augmente la limite de taille de facture BOLT11 de 1 023 octets à 7 089 octets pour correspondre à la limite de LND, qui est basée sur le nombre maximum d’octets pouvant tenir sur un code QR. L’auteur du PR argue que les codes QR compatibles avec le codage utilisé dans une facture BOLT11 sont en réalité limités à 4 296 caractères, mais la valeur de 7 089 est choisie pour LDK parce que “la cohérence à l’échelle du système est probablement plus importante.”

  • ● LND #8453, #9559, #9575, #9568, et LND #9610 introduisent un flux de fermeture coopérative RBF basé sur BOLTs #1205 (voir le Bulletin #342) qui permet à l’un ou l’autre des pairs d’augmenter le taux de frais en utilisant les fonds de leur propre canal. Auparavant, les pairs devaient parfois convaincre leur contrepartie de payer pour les augmentations de frais, ce qui se soldait souvent par des tentatives échouées. Pour activer cette fonctionnalité, le drapeau de configuration protocol.rbf-coop-close doit être défini.

  • ● BIPs #1792 met à jour BIP119 qui spécifie OP_CHECKTEMPLATEVERIFY en révisant le langage pour une meilleure clarté, en supprimant la logique d’activation, en renommant Eltoo en LN-Symmetry, et en ajoutant des mentions de nouvelles propositions de covenant et de projets comme Ark qui utilisent OP_CTV.

  • ● BIPs #1782 reformate la section de spécification de BIP94, qui décrit les règles de consensus de testnet4, pour une meilleure clarté et lisibilité.