Le bulletin de cette semaine résume une discussion sur l’extension des factures BOLT11 pour demander deux paiements. Vous y trouverez également une autre contribution à notre série hebdomadaire limitée sur la politique de mempool, ainsi que nos sections régulières décrivant les mises à jour des clients et des services, les nouvelles versions et les versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Proposition d’extension des factures BOLT11 pour demander deux paiements : Thomas Voegtlin a posté sur la liste de diffusion de Lightning-Dev pour suggérer que les factures BOLT11 soient étendues pour permettre optionnellement à un destinataire de demander deux paiements séparés à un utilisateur, avec chaque paiement ayant un secret et un montant séparés. Voegtlin explique comment cela pourrait être utile à la fois pour les submarine swaps et les canaux JIT :

    • ● Les swaps sous-marins, où le paiement d’une facture LN offchain permet de recevoir des fonds onchain (les swaps sous-marins peuvent également fonctionner dans l’autre sens, de onchain à offchain, mais cela n’est pas discuté ici). Le bénéficiaire onchain choisit un secret et le payeur offchain paie un HTLC au hash de ce secret, qui est acheminé par LN à un fournisseur de services d’échange sous-marin. Le fournisseur de services reçoit un HTLC offchain pour ce secret et crée une transaction onchain en payant ce HTLC. Lorsque l’utilisateur est convaincu que la transaction onchain est sécurisée, il divulgue le secret pour régler le HTLC onchain, ce qui permet au prestataire de services de régler le HTLC offchain (et tous les paiements transmis sur le LN qui dépendent également du même secret).

      Toutefois, si le destinataire ne divulgue pas son secret, le prestataire de services ne recevra aucune compensation et devra dépenser la sortie onchain qu’il vient de créer, ce qui implique des coûts pour aucun gain. Pour éviter cet abus, les services d’échange sous-marin existants exigent que le créditeur paie une redevance en utilisant le LN avant que le service ne crée une transaction onchain (le service peut éventuellement rembourser une partie ou la totalité de cette redevance si la HTLC onchain est réglée). Les frais initiaux et l’échange sous-marin portent sur des montants différents et doivent être réglés à des moments différents, de sorte qu’ils doivent utiliser des secrets différents. Une facture BOLT11 actuelle ne peut contenir qu’un seul engagement pour un secret et un seul montant, de sorte que tout portefeuille effectuant des échanges sous-marins doit être programmé pour gérer l’interaction avec le serveur ou nécessite que l’expéditeur et le destinataire complètent un flux de travail en plusieurs étapes.

    • ● Les canaux JIT (Just-in-Time), où un utilisateur sans canaux (ou sans liquidité) crée un canal virtuel avec un fournisseur de services ; lorsque le premier paiement de ce canal virtuel arrive, le fournisseur de services crée une transaction onchain qui finance le canal et contient ce paiement. Comme pour tout HTLC LN, le paiement offchain est effectué selon un secret que seul le destinataire (l’utilisateur) connaît. Si l’utilisateur est convaincu que la transaction de financement du canal JIT est sécurisée, il divulgue le secret pour réclamer le paiement.

      Cependant, si l’utilisateur ne divulgue pas son secret, le fournisseur de services ne recevra aucune compensation et pourrait avoir des coûts onchain sans le moindre gain. Thomas Voegtlin pense que les fournisseurs de services de canaux JIT existants évitent ce problème en demandant à l’utilisateur de divulguer son secret avant que la transaction de financement ne soit sécurisée, ce qui, selon lui, peut créer des problèmes juridiques et empêcher les portefeuilles non hébergés d’offrir un service similaire.

    Il suggère qu’autoriser une facture BOLT11 à contenir deux engagements distincts en matière de secrets, chacun pour un montant différent, permettra d’utiliser un secret et un montant pour une commission initiale destinée à payer les coûts de transaction onchain et l’autre secret et montant pour le swap sous-marin ou le financement du canal JIT proprement dit. La proposition a reçu plusieurs commentaires, nous en résumons quelques-uns :

    • ● Une logique dédiée est nécessaire pour les échanges sous-marins : Olaoluwa Osuntokun note que le destinataire d’un swap sous-marin doit créer un secret, le distribuer, puis effectuer un paiement onchain. Le moyen le plus économique de régler ce paiement est d’interagir avec le fournisseur de services d’échange. Si l’émetteur et le récepteur interagissent de toute façon avec le fournisseur de services, comme c’est souvent le cas dans certaines implémentations existantes où l’émetteur et le récepteur sont la même entité, ils n’ont pas besoin de communiquer des informations supplémentaires à l’aide d’une facture. Voegtlin a répondu qu’un logiciel dédié peut gérer l’interaction, éliminant le besoin d’une logique supplémentaire dans le portefeuille offchain qui paie les fonds et le portefeuille onchain qui reçoit les fonds—mais cela n’est possible que si le portefeuille LN peut payer deux secrets et montants distincts dans la même facture.

    • ● ossification de BOLT11 : Matt Corallo répond qu’il n’a pas encore été possible de faire en sorte que toutes les implémentations LN mettent à jour leur support BOLT11 pour supporter les factures qui ne contiennent pas de montant (pour permettre les paiements spontanés), donc il ne pense pas que l’ajout d’un champ supplémentaire soit une approche pratique pour le moment. Bastien Teinturier fait un commentaire similaire, suggérant d’ajouter un support aux offres à la place. Voegtlin n’est pas d’accord et pense que l’ajout d’un soutien est pratique.

    • ● Alternative au splice-out : Corallo demande également pourquoi le protocole devrait être modifié pour supporter les submarine swaps si splice outs devient disponible. Cela n’a pas été mentionné dans le fil de discussion, les swaps sous-marins et les splice outs permettent tous deux de déplacer des fonds offchain vers une sortie onchain—mais les splice outs peuvent être plus efficaces onchain et ne sont pas vulnérables aux problèmes de frais non compensés. Voegtlin répond que les échanges sous-marins permettent à un utilisateur de LN d’augmenter sa capacité à recevoir de nouveaux paiements LN, ce qui n’est pas le cas du splicing.

    La discussion semblait être en cours au moment de la rédaction du présent document.

En attente de confirmation #6 : Cohérence des politiques

Une série hebdomadaire limitée sur les relais de transaction, l’inclusion dans le mempool et la sélection des transactions de minage, y compris pourquoi Bitcoin Core a une politique plus restrictive que celle permise par le consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace possible.

Le billet de la semaine dernière présentait la politique, un ensemble de règles de validation des transactions appliquées en plus des règles de consensus. Ces règles ne s’appliquent pas aux transactions dans les blocs, de sorte qu’un nœud peut rester dans le consensus même si sa politique diffère de celle de ses pairs. Tout comme un opérateur de nœud peut décider de ne pas participer au relais de transaction, il est également libre de choisir n’importe quelle politique, voire aucune (exposant son nœud au risque de déni de service). Cela signifie que nous ne pouvons pas supposer une homogénéité totale des politiques de mempool dans le réseau. Cependant, pour que la transaction d’un utilisateur soit reçue par un mineur, elle doit passer par un chemin de nœuds qui l’acceptent tous dans leur mempool—la divergence de politique entre les nœuds affecte directement la fonctionnalité du relais de transaction.

Pour donner un exemple extrême des différences de politique entre les nœuds, imaginons une situation dans laquelle chaque opérateur de nœud choisirait une nVersion aléatoire et n’accepterait que les transactions avec cette nVersion. Comme la plupart des relations d’égal à égal auraient des politiques incompatibles, les transactions ne se propageraient pas aux mineurs.

De l’autre côté du spectre, des politiques identiques à travers le réseau aident à faire converger les contenus des mempools. Un réseau avec des mempools correspondants relaie les transactions le plus facilement, et est également idéal pour l’estimation des frais et le relais de bloc compact comme mentionné dans les posts précédents.

Étant donné la complexité de la validation des mempools et les difficultés qui découlent des disparités entre les politiques, Bitcoin Core a historiquement été conservateur avec la configurabilité des politiques. Alors que les utilisateurs peuvent facilement modifier la façon dont les sigops sont comptés (bytespersigop) et limiter la quantité de données intégrées dans les sorties OP_RETURN (datacarriersize et datacarrier), ils ne peuvent pas renoncer au poids standard maximum de 400 000 unités de poids ou appliquer un ensemble différent de règles RBF liées aux frais sans modifier le code source.

Certaines options de configuration de la politique de Bitcoin Core existent pour tenir compte des différences entre les environnements d’exploitation des nœuds et les objectifs d’exploitation d’un nœud. Par exemple, les ressources matérielles d’un mineur et la raison pour laquelle il conserve un mempool diffèrent de celles d’un utilisateur quotidien qui fait fonctionner un nœud léger sur son ordinateur portable ou son Raspberry Pi. Un mineur peut choisir d’augmenter la capacité de son mempool (maxmempool) ou son délai d’expiration (mempoolexpiry) pour stocker des transactions à faible taux d’échange pendant les pics de trafic, puis les exploiter plus tard lorsque le trafic diminue. Les sites web fournissant des visualisations, des archives et des statistiques sur le réseau peuvent utiliser plusieurs noeuds pour collecter autant de données que possible et afficher le comportement par défaut du mempool.

Sur un nœud individuel, le choix de la capacité du mempool affecte la disponibilité des outils de substitution de frais. Lorsque les taux minimums du mempool augmentent en raison de soumissions de transactions dépassant la taille par défaut du mempool, les transactions purgées du “bas” du mempool et les nouvelles qui sont en dessous de ce taux ne peuvent plus être surtaxées en utilisant CPFP.

D’un autre côté, puisque les entrées utilisées par les transactions purgées ne sont plus dépensées par aucune transaction dans le mempool, il peut être possible de faire du fee-bump via RBF alors que ce n’était pas le cas auparavant. La nouvelle transaction ne remplace rien dans le mempool du noeud, donc elle n’a pas besoin de prendre en compte les règles habituelles de RBF. Cependant, les nœuds qui n’ont pas expulsé la transaction originale (parce qu’ils ont une plus grande capacité de mempool) traitent la nouvelle transaction comme un remplacement proposé et exigent qu’elle respecte les règles RBF. Si la transaction purgée ne signalait pas la remplaçabilité BIP125, ou si les frais de la nouvelle transaction ne répondent pas aux exigences RBF en dépit d’un taux élevé, le mineur peut refuser la nouvelle transaction. Les portefeuilles doivent traiter les transactions purgées avec précaution : les résultats de la transaction ne peuvent pas être considérés comme disponibles pour la dépense, mais les entrées sont également indisponibles pour la réutilisation.

À première vue, il peut sembler qu’un nœud ayant une plus grande capacité de mempool rend le CPFP plus utile et le RBF moins utile. Cependant, le relais des transactions est soumis au comportement émergent du réseau et il se peut qu’il n’y ait pas de chemin de nœuds acceptant le CPFP depuis l’utilisateur jusqu’au mineur. Les nœuds ne transmettent généralement les transactions qu’une fois qu’ils les ont acceptées dans leur mempool et ignorent les annonces de transactions qui existent déjà dans leur mempool - les nœuds qui stockent davantage de transactions agissent comme des trous noirs lorsque ces transactions leur sont rediffusées. À moins que l’ensemble du réseau n’augmente la capacité de ses mempools - ce qui serait un signe de changement de la valeur par défaut - les utilisateurs ne doivent pas s’attendre à ce que l’augmentation de la capacité de leurs propres mempools leur apporte beaucoup d’avantages. Le taux de frais minimum fixé par les mempools par défaut limite l’utilité de CPFP pendant les périodes de fort trafic. Un utilisateur ayant réussi à soumettre une transaction CPFP à son propre mempool, dont la taille a été augmentée, pourrait ne pas remarquer que la transaction ne s’est pas propagée à d’autres utilisateurs.

Le réseau de relais de transactions est composé de nœuds individuels qui rejoignent et quittent dynamiquement le réseau, chacun d’entre eux devant se protéger contre l’exploitation. En tant que tel, le relais de transaction ne peut être que le fruit d’un effort et nous ne pouvons pas garantir que chaque nœud est informé de chaque transaction non confirmée. En même temps, le réseau Bitcoin est plus performant si les nœuds convergent vers un ensemble de politiques de relais de transactions qui rend les mempools aussi homogènes que possible. Le prochain article examinera les mesures qui ont été adoptées afin de répondre aux intérêts du réseau dans son ensemble.

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

  • ● Les bibliothèques Greenlight sont en source ouverte : Le fournisseur de services de nœuds CLN non privatifs Greenlight a annoncé un dépôt de bibliothèques client et de liaisons linguistiques ainsi qu’un guide du cadre de test.

  • ● Débogueur pour Tapscript Tapsim : Tapsim est un outil de débogage de l’exécution des scripts (voir Bulletin #254) et de visualisation pour tapscript utilisant btcd.

  • ● Annonce de Bitcoin Keeper 1.0.4 : Bitcoin Keeper est un portefeuille mobile qui supporte le multisig, les supports de signature matériels, BIP85, et avec la dernière version, coinjoin qui utilise le protocole Whirlpool.

  • ● Annonce du portefeuille lightning EttaWallet : Le portefeuille mobile EttaWallet a été récemment annoncé avec des fonctionnalités Lightning activées par LDK et une forte orientation vers la facilité d’utilisation inspirée par la conception de référence du portefeuille de dépenses quotidiennes de la Bitcoin Design Community.

  • ● Annonce d’un PoC de synchronisation d’en-tête de bloc basé sur zkSNARK : BTC Warp est une preuve de concept de synchronisation de client léger utilisant les zkSNARKs pour prouver et vérifier une chaîne d’en-têtes de blocs Bitcoin. Un billet de blog fournit des détails sur les approches adoptées.

  • ● Lancement de lnprototest v0.0.4 : Le projet lnprototest est une suite de tests pour LN comprenant “un ensemble d’aides au test écrits en Python3, conçus pour faciliter l’écriture de nouveaux tests lorsque vous proposez des changements au protocole du réseau Lightning, ainsi que pour tester les implémentations existantes”.

Mises à jour et versions candidates

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

  • ● Eclair v0.9.0 est une nouvelle version de cette implémentation du LN qui “contient beaucoup de travail préparatoire pour des fonctionnalités importantes (et complexes) : dual-funding, splicing et les offres BOLT12”. Ces fonctionnalités sont pour l’instant expérimentales. La version “rend les plugins plus puissants, introduit des mesures d’atténuation contre divers types de déni de service et améliore les performances dans de nombreux domaines du code de base”.

Changements notables 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), Lightning BOLTs, et Bitcoin Inquisition.

  • ● LDK #2294 ajoute la prise en charge de la réponse aux messages en oignons et rapproche LDK de la prise en charge complète des offres.

  • ● LDK #2156 ajoute la prise en charge des paiements keyend qui utilisent les paiements simplifiés par trajets multiples. LDK prenait auparavant en charge ces deux technologies, mais uniquement lorsqu’elles étaient utilisées séparément. Les paiements par trajets multiples doivent utiliser des secrets de paiement mais LDK rejetait auparavant les paiements par keyend avec des secrets de paiement. Des erreurs descriptives, une option de configuration et un avertissement sur la rétrogradation ont donc été ajoutés pour atténuer tout problème potentiel.