Le bulletin d’information de cette semaine décrit une proposition pour un nouveau protocole de gestion de joinpool et résume une idée pour relayer les transactions en utilisant le protocole Nostr. Vous y trouverez également une autre partie de notre série hebdomadaire limitée sur la politique mempool, ainsi que nos sections régulières résumant les principales questions et réponses postées sur le Bitcoin Stack Exchange, listant les nouvelles versions de logiciels et les versions candidates, et décrivant les changements notables apportés aux principaux logiciels de l’infrastructure Bitcoin.

Nouvelles

  • ● Proposition d’un protocole de gestion des joinpool : Cette semaine, Burak Keceli a posté sur la liste de diffusion Bitcoin-Dev une idée pour Ark, un nouveau protocole de type joinpool où les propriétaires de bitcoins choisissent d’utiliser une contrepartie comme cosignataire pour toutes les transactions pendant une certaine période de temps. Les propriétaires peuvent soit retirer unilatéralement leurs bitcoins sur la chaîne après l’expiration du délai, soit les transférer instantanément et en toute confiance hors de la chaîne à la contrepartie avant l’expiration du délai.

    Comme tout utilisateur de Bitcoin, la contrepartie peut diffuser à tout moment une transaction onchain qui ne dépense que ses propres fonds. Si une sortie de cette transaction est utilisée comme entrée dans la transaction offchain qui transfère des fonds du propriétaire à la contrepartie, le transfert offchain devient invalide à moins que la transaction onchain ne soit confirmée dans un délai raisonnable. Dans ce cas, la contrepartie ne signera pas sa transaction onchain tant qu’elle n’aura pas reçu la transaction offchain signée. Il s’agit d’un protocole de transfert atomique sans confiance, à un seul saut et dans une seule direction, entre le propriétaire et la contrepartie. Keceli décrit trois utilisations de ce protocole de transfert atomique :

    • ● Mélange de pièces : plusieurs utilisateurs du joinpool peuvent tous, avec la coopération de la contrepartie, procéder à des échanges atomiques de leurs valeurs offchain actuelles contre un montant équivalent de nouvelles valeurs offchain. Cette opération peut être réalisée rapidement, car une défaillance de la composante onchain annulera simplement l’échange, ce qui ramènera tous les fonds à leur point de départ. Un protocole d’aveuglement similaire à ceux utilisés par certaines implémentations existantes de coinjoin peut empêcher tout utilisateur ou la contrepartie de déterminer quel utilisateur s’est retrouvé avec quels bitcoins.

    • ● Effectuer des transferts internes : un utilisateur peut transférer ses fonds hors chaîne à un autre utilisateur avec la même contrepartie. L’atomicité garantit que le destinataire recevra son argent ou que le prêteur sera remboursé. Un destinataire qui ne fait pas confiance à l’émetteur et à la contrepartie devra attendre autant de confirmations qu’il le ferait pour une transaction onchain normale.

      Keceli et un commentateur lient à une recherche précédente décrivant comment un paiement zéro-conf peut être rendu non profitable à la double dépense en l’associant à une liaison de fidélité qui peut être réclamée par tout mineur qui a observé les deux versions de la transaction doublement dépensée. Cela pourrait permettre aux destinataires d’accepter un paiement en quelques secondes même s’ils n’ont pas confiance dans les autres parties individuelles.

    • ● Paiement des factures LN : un utilisateur peut rapidement s’engager à verser ses fonds hors chaîne à la contrepartie si cette dernière connaît un secret, ce qui permet à l’utilisateur de payer des factures de type LN HTLC par l’intermédiaire de la contrepartie.

      Comme dans le cas des virements internes, un utilisateur ne peut pas recevoir des fonds en toute confiance. Il ne doit donc pas révéler un secret avant qu’un paiement ait reçu un nombre suffisant de confirmations ou qu’il soit garanti par une clause de fidélité qu’il juge convaincante.

    M. Keceli affirme que le protocole de base peut être mis en œuvre sur Bitcoin aujourd’hui en utilisant une interaction fréquente entre les membres du groupe. Si une proposition de covenant comme OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, ou OP_CAT + OP_CHEKSIGFROMSTACK est mise en œuvre, les membres du joinpool n’auront besoin d’interagir avec la contrepartie que lorsqu’ils participeront à un coinjoin, effectueront un paiement, ou rafraîchiront le timelock sur leurs fonds offchain.

    Chaque coinjoin, paiement ou rafraîchissement nécessite la publication d’un engagement dans une transaction onchain, bien qu’un nombre pratiquement illimité d’opérations puisse être regroupé dans la même petite transaction. Pour permettre aux opérations de se terminer rapidement, Keceli suggère qu’une transaction onchain soit effectuée toutes les cinq secondes environ, afin que les utilisateurs n’aient pas à attendre plus longtemps. Chaque transaction est séparée—il n’est pas possible de combiner les engagements de plusieurs transactions en utilisant replace-by-fee sans rompre les engagements ou exiger la participation de tous les utilisateurs impliqués dans les tours précédents—de sorte que plus de 6,3 millions de transactions pourraient devoir être confirmées chaque année pour une contrepartie, bien que les transactions individuelles soient relativement petites.

    Les commentaires sur le protocole envoyés à la liste de diffusion sont les suivants :

    • ● Une demande de documentation supplémentaire : au moins deux répondants ont demandé une documentation supplémentaire sur le fonctionnement du système, estimant qu’il était difficile de l’analyser à partir de la description de haut niveau fournie à la liste de diffusion. Keceli a depuis commencé à publier des projets de spécifications.

    • ● Inquiétude quant à la lenteur de la réception par rapport au LN : Plusieurs personnes ont noté que, dans la conception initiale, il n’est pas possible de recevoir en toute confiance un paiement du joinpool (que ce soit offchain ou onchain) sans attendre un nombre suffisant de confirmations. Cela peut prendre des heures, alors que de nombreux paiements LN s’effectuent actuellement en moins d’une seconde. Même avec des bons de fidélité, le LN serait plus rapide en moyenne.

    • ● Inquiétude quant à l’importance de l’empreinte onchain : Une réponse a noté qu’à raison d’une transaction toutes les cinq secondes, environ 200 contreparties de ce type consommeraient la totalité de l’espace de chaque bloc. Une autre réponse a supposé que chacune des transactions onchain de la contrepartie sera à peu près de la taille d’une transaction d’ouverture ou de fermeture coopérative de canal LN, de sorte qu’une contrepartie avec un million d’utilisateurs qui crée 6,3 millions de transactions onchain par an utiliserait une quantité d’espace équivalente à chacun de ces utilisateurs ouvrant ou fermant en moyenne 6,3 canaux chacun par an ; ainsi, les coûts onchain de LN pourraient être inférieurs à l’utilisation de la contrepartie jusqu’à ce qu’elle ait atteint une échelle massive.

    • ● Inquiétude au sujet d’un grand hot wallet et des coûts d’investissement : Une réponse a estimé que la contrepartie devrait conserver un montant de bitcoins (probablement dans un “hot wallet”) égal au montant que les utilisateurs pourraient dépenser dans un avenir proche. Après une dépense, la contrepartie ne recevrait pas ses bitcoins pendant une période pouvant aller jusqu’à 28 jours selon la proposition de conception actuelle. Si la contrepartie appliquait un taux d’intérêt faible de 1,5 % par an à son capital, cela équivaudrait à une charge de 0,125 % sur le montant de chaque transaction effectuée avec la participation de la contrepartie (y compris les coinjoins, les transferts internes et les paiements LN). À titre de comparaison, les statistiques publiques disponibles au moment de la rédaction (collectées par 1ML) indiquent un taux médian par saut pour les transferts LN de 0,0026 %, soit près de 50 fois moins.

    Plusieurs commentaires sur la liste étaient également enthousiastes quant à la proposition et attendaient avec impatience de voir Keceli et d’autres explorer l’espace de conception des “managed joinpools”.

  • ● Relais de transaction sur Nostr : Joost Jager a posté sur la liste de diffusion Bitcoin-Dev pour demander des commentaires sur l’idée de Ben Carman d’utiliser le protocole Nostr pour relayer les transactions qui pourraient ne pas bien se propager sur le réseau P2P des nœuds complets Bitcoin qui fournissent des services de relais.

    En particulier, Jager examine la possibilité d’utiliser Nostr pour le relais des paquets de transactions, comme le relais d’une transaction ancestrale avec un taux inférieur à la valeur minimale acceptée en l’associant à un descendant qui paie des frais suffisamment élevés pour compenser la déficience de son ancêtre. Cela rend la substitution de frais CPFP plus fiable et plus efficace, et c’est une fonctionnalité appelée package relay que les développeurs de Bitcoin Core ont travaillé à mettre en œuvre pour le réseau P2P de Bitcoin. L’un des défis de l’examen de la conception et de la mise en œuvre du relais de paquet est de s’assurer que les nouvelles méthodes de relais ne créent pas de nouvelles vulnérabilités de déni de service (DoS) contre des nœuds et des mineurs individuels (ou le réseau en général).

    Jager note que les relais Nostr ont la possibilité d’utiliser facilement d’autres types de protection contre les dénis de service à partir du réseau de relais P2P, par exemple en exigeant un petit paiement pour relayer une transaction. Selon lui, cela peut permettre de relayer des paquets ou d’autres transactions alternatives, même si une transaction ou un paquet malveillant peut entraîner le gaspillage d’une petite quantité de ressources du nœud.

    Le message de M. Jager contenait un lien vers une vidéo où il faisait une démonstration de la fonction. À l’heure où nous écrivons ces lignes, son message n’a reçu que quelques réponses, toutes positives.

Attente de la confirmation #3 : Enchères pour l’achat d’un bloc d’espace

Une série hebdomadaire limitée sur le relais de transaction, l’inclusion dans le mempool et la sélection des transactions minières—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.

La semaine dernière, nous avons indiqué que les transactions payaient des frais pour l’espace de blocs utilisé plutôt que pour le montant transféré, et nous avons établi que les mineurs optimisent leur sélection de transactions pour maximiser les frais perçus. Il s’ensuit que seules sont confirmées les transactions qui se trouvent en tête du pool de mémoire lorsqu’un bloc est trouvé. Dans ce billet, nous discuterons de stratégies pratiques pour tirer le meilleur parti de nos frais. Supposons que nous disposons d’une source décente d’estimations de taux de change—nous parlerons plus en détail de l’estimation des taux de change dans l’article de la semaine prochaine.

Lors de l’élaboration des transactions, certaines parties de la transaction sont plus flexibles que d’autres. Chaque transaction nécessite les champs d’en-tête, les sorties du destinataire sont déterminées par les paiements effectués, et la plupart des transactions nécessitent une sortie de changement. L’expéditeur et le destinataire doivent privilégier les types de sorties efficaces en termes d’espace de blocs afin de réduire le coût futur de la dépense de leurs sorties de transaction, mais c’est au cours de la sélection des entrées qu’il est le plus possible de modifier la composition et le poids finaux de la transaction. Comme les transactions se concurrencent par taux [frais/poids], une transaction plus légère nécessite des frais moins élevés pour atteindre le même taux.

Certains portefeuilles, comme le portefeuille Bitcoin Core, essaient de combiner les entrées de manière à éviter d’avoir besoin de changer les sorties. Éviter le changement permet d’économiser le poids d’une sortie maintenant, mais aussi le coût futur de la dépense de la sortie de changement plus tard. Malheureusement, de telles combinaisons d’entrées ne seront que rarement disponibles, à moins que le portefeuille ne dispose d’un grand pool d’UTXO avec une grande variété de montants.

Les types de sortie modernes sont plus efficaces en termes d’espace de blocs que les types de sortie plus anciens. Par exemple, dépenser une entrée P2TR coûte moins de 2/5e du poids d’une entrée P2PKH (essayez-le avec notre calculateur de taille de transaction). Pour les portefeuilles à plusieurs signatures, le schéma MuSig2 et le protocole FROST récemment finalisés permettent de réaliser d’énormes économies en autorisant l’encodage d’une fonctionnalité à plusieurs signatures dans ce qui ressemble à une entrée à une seule signature. En particulier à une époque où la demande d’espace de blocs explose, un portefeuille utilisant des types de sortie modernes se traduit à lui seul par d’importantes économies.

Overview of input and output weights

Les portefeuilles intelligents modifient leur stratégie de sélection en fonction du taux : lorsque le taux est élevé, ils utilisent peu d’entrées et des types d’entrées modernes afin d’obtenir le poids le plus faible possible pour l’ensemble d’entrées. Le fait de toujours sélectionner l’ensemble d’entrées le plus léger minimiserait localement le coût de la transaction en cours, mais réduirait également le pool d’UTXO d’un portefeuille en petits fragments. Cela pourrait préparer l’utilisateur à effectuer plus tard des transactions avec des ensembles d’entrées énormes à des taux élevés. Par conséquent, il est judicieux que les portefeuilles sélectionnent également des entrées plus nombreuses et plus lourdes à des taux faibles afin de consolider de manière opportuniste les fonds dans des sorties modernes moins nombreuses en prévision de pics de demande ultérieurs dans l’espace de blocs.

Les portefeuilles à fort volume regroupent souvent plusieurs paiements en une seule transaction afin de réduire le poids de la transaction par paiement. Au lieu de supporter les frais généraux liés aux octets d’en-tête et à la sortie des modifications pour chaque paiement, ils ne supportent les frais généraux qu’une seule fois, pour tous les paiements. Le simple fait de regrouper quelques paiements permet de réduire rapidement le coût par paiement.

Savings from payment batching with P2WPKH

Néanmoins, même si de nombreux portefeuilles estiment que les taux se trompent sur les paiements excessifs, en cas de bloc lent ou d’augmentation des soumissions de transactions, les transactions restent parfois non confirmées plus longtemps que prévu. Dans ce cas, l’expéditeur ou le destinataire peuvent souhaiter redéfinir les priorités de la transaction.

Les utilisateurs disposent généralement de deux outils pour accroître la priorité de leur transaction : l’enfant paie pour le parent (CPFP) et le remplacement par des frais (RBF). Dans CPFP, un utilisateur dépense le résultat de sa transaction pour créer une transaction enfant à haut degré de priorité. Comme décrit dans l’article de la semaine dernière, les mineurs sont incités à choisir le parent dans le bloc afin d’inclure l’enfant riche en frais. Le CPFP est accessible à tout utilisateur rémunéré par la transaction, de sorte que le destinataire ou l’expéditeur (s’il a créé une sortie de changement) peut l’utiliser.

Dans le cas du RBF, l’expéditeur est l’auteur d’un remplacement de la transaction d’origine à un taux plus élevé. La transaction de remplacement doit réutiliser au moins une entrée de la transaction originale pour garantir un conflit avec l’original et pour qu’une seule des deux transactions puisse être incluse dans la blockchain. En général, ce remplacement inclut les paiements de la transaction originale, mais l’expéditeur peut également rediriger les fonds dans la transaction de remplacement ou combiner les paiements de plusieurs transactions en une seule lors du remplacement. Comme décrit dans l’article de la semaine dernière, les nœuds évincent la transaction initiale en faveur de la transaction de remplacement, plus compatible avec les incitations.

Bien que la demande et la production d’espace de blocs soient hors de notre contrôle, il existe de nombreuses techniques que les portefeuilles peuvent utiliser pour faire des offres d’espace de blocs de manière efficace. Les portefeuilles peuvent économiser des frais en créant des transactions plus légères en éliminant la sortie de changement, en dépensant les sorties segwit natives et en défragmentant leur pool UTXO dans les environnements à faible taux de feerate. Les portefeuilles qui prennent en charge CPFP et RBF peuvent également commencer avec un taux de rafraîchissement conservateur, puis mettre à jour la priorité de la transaction à l’aide de CPFP ou de RBF si nécessaire.

Selection de Q&R du Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les collaborateurs d’Optech cherchent des réponses à leurs questions—ou, lorsqu’ils ont quelques moments libres, aident les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en avant certaines des questions et réponses les plus populaires depuis notre dernière mise à jour.

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.

  • ● Bitcoin Core 25.0 est une version pour la prochaine version majeure de Bitcoin Core. Cette version ajoute une nouvelle RPC scanblocks, simplifie l’utilisation de bitcoin-cli, ajoute le support miniscript à la RPC finalizepsbt, réduit l’utilisation de la mémoire par défaut avec l’option de configuration blocksonly, et accélère les rescans de portefeuilles lorsque les filtres de blocs compacts sont activés—parmi beaucoup d’autres nouvelles fonctionnalités, améliorations de performance, et corrections de bugs. Voir les notes de version pour plus de détails.

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.

  • ● Bitcoin Core #27469 accélère le téléchargement du bloc initial (IBD) lorsqu’un ou plusieurs portefeuilles sont utilisés. Avec ce changement, un bloc ne sera analysé pour les transactions correspondant à un portefeuille particulier que s’il a été miné après la date de naissance du portefeuille, c’est-à-dire la date enregistrée dans le portefeuille comme étant celle de sa création.

  • ● Bitcoin Core #27626 permet à un pair qui a demandé à notre nœud de fournir un relais de bloc compact en mode large bande passante de faire jusqu’à trois demandes de transactions à partir du dernier bloc que nous lui avons annoncé. Notre nœud répondra à la demande même si nous ne lui avons pas fourni de bloc compact au départ. Cela permet à un pair qui reçoit un bloc compact de l’un de ses autres pairs de nous demander les transactions manquantes, ce qui peut s’avérer utile si cet autre pair ne répond plus. Cela peut aider notre pair à valider le bloc plus rapidement, ce qui peut également l’aider à l’utiliser plus tôt dans des fonctions critiques, telles que l’exploitation minière.

  • ● Bitcoin Core #25796 ajoute un nouveau descriptorprocesspsbt qui peut être utilisé pour mettre à jour un PSBT avec des informations qui l’aideront plus tard à être signé ou finalisé. Un descripteur fourni à la RPC sera utilisé pour récupérer les informations du mempool et de l’ensemble UTXO (et, si disponible, les transactions complètes confirmées lorsque le noeud a été démarré avec l’option de configuration txindex). Les informations récupérées seront ensuite utilisées pour remplir le PSBT.

  • ● Eclair #2668 empêche Eclair d’essayer de payer plus de frais pour réclamer un HTLC sur la chaîne que la valeur qu’il recevra en résolvant avec succès ce HTLC.

  • ● Eclair #2666 permet à un pair distant recevant un HTLC de l’accepter même si les frais de transaction qui devraient être payés pour l’accepter réduisent le solde du pair en dessous de la réserve minimale du canal. La réserve de canal existe pour garantir qu’un pair perdra au moins une petite somme d’argent s’il tente de fermer un canal dans un état obsolète, ce qui le décourage de tenter un vol. Cependant, si l’homologue distant accepte un HTLC qui le paiera en cas de succès, il aura de toute façon plus en jeu que la réserve. En cas d’échec, son solde reviendra au montant précédent, qui aura été supérieur à la réserve.

    Il s’agit d’une mesure d’atténuation d’un problème de fonds bloqués, qui se produit lorsqu’un paiement oblige la partie responsable du paiement des frais à payer une valeur supérieure à son solde disponible actuel, même s’il s’agit de la partie qui reçoit le paiement. Pour une discussion précédente sur ce problème, voir Newsletter #85.

  • ● BTCPay Server 97e7e commence à définir le paramètre BIP78 minfeerate (“ taux de frais minimum “) pour les paiements payjoin. Voir aussi le rapport de bug qui a conduit à ce commit.

  • ● BIPs #1446 apporte une petite modification et un certain nombre d’ajouts à la spécification BIP340 des signatures schnorr pour les protocoles liés à Bitcoin. Le changement consiste à permettre au message à signer d’être d’une longueur arbitraire ; les versions précédentes du BIP exigeaient que le message soit exactement de 32 octets. Voir une modification connexe de la bibliothèque Libsecp256k1 décrite dans le Bulletin n°157. Cette modification n’a aucun effet sur l’utilisation de BIP340 dans les applications de consensus, car les signatures utilisées avec taproot et tapscript (respectivement, BIPs 341 et 342) utilisent des messages de 32 octets.

    Les ajouts décrivent comment utiliser efficacement des messages de longueur arbitraire, recommandent l’utilisation d’un préfixe de balise haché et fournissent des recommandations pour accroître la sécurité lors de l’utilisation de la même clé dans différents domaines (tels que la signature de transactions ou la signature de messages en texte clair).