Bulletin hebdomadaire Bitcoin Optech #254

Bulletin d’information hebdomadaire Bitcoin Optech du 7 juin 2023 traduit par@copinmalin.

---

La bulletin de cette semaine résume les discussions de la liste de diffusion sur l’utilisation de la proposition MATT pour gérer les joinpools et répliquer les fonctions de la proposition OP_CHECKTEMPLATEVERIFY. Vous y trouverez également une autre contribution à notre série hebdomadaire limitée sur la politique du mempool, ainsi que nos sections régulières pour annoncer les nouvelles versions de logiciels et les versions candidates, et pour décrire les changements notables apportés aux principaux logiciels de l’infrastructure Bitcoin.

Nouvelles

• Utilisation de MATT pour répliquer CTV et gérer les joinpools : Johan Torås Halseth a posté sur la liste de diffusion Bitcoin-Dev à propos de l’utilisation de l’opcode OP_CHECKOUTPUTCONTRACTVERIFY (COCV) de la proposition Merklize All The Things (MATT) (voir les lettres d’information #226 et #249) pour répliquer la fonctionnalité de la proposition OP_CHECKTEMPLATEVERIFY. Pour engager une transaction avec plusieurs sorties, chaque sortie nécessiterait l’utilisation d’un opcode COCV différent. En comparaison, un seul opcode CTV pourrait valider toutes les sorties. COCV est donc moins efficace, mais, comme il le fait remarquer, “suffisamment simple pour être intéressant”.Au-delà de la simple description de la fonctionnalité, Halseth fournit également une démo de l’opération à l’aide de Tapsim, un outil de “débogage des transactions Bitcoin Tapscript […] destiné aux développeurs souhaitant jouer avec les primitives de script Bitcoin, faciliter le débogage des scripts et visualiser l’état de la VM lors de l’exécution des scripts”.Dans un autre fil de discussion, Halseth a posté sur l’utilisation de MATT plus OP_CAT pour créer un joinpool (également appelé coinpool ou payment pool). Là encore, il fournit une démo interactive utilisant Tapsim. Il a également suggéré plusieurs modifications aux opcodes de la proposition MATT sur la base des résultats de sa mise en œuvre expérimentale. Salvatore Ingala, l’auteur de la proposition MATT, a répondu favorablement.

En attente de confirmation #4 : Estimation du taux de frais

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 exploré des techniques pour minimiser les frais payés sur une transaction avec un taux de commission. Mais quel devrait être ce tarif ? Idéalement, aussi bas que possible pour économiser de l’argent, mais suffisamment haut pour garantir une place dans un bloc adapté à la préférence temporelle de l’utilisateur.

L’objectif de l’estimation des frais est de traduire un délai cible de confirmation en un taux de frais minimal que la transaction devrait payer.

L’estimation des frais est compliquée par l’irrégularité de la production d’espace de bloc. Si un utilisateur doit payer un commerçant dans l’heure pour recevoir ses marchandises, l’utilisateur peut s’attendre à ce qu’un bloc soit miné toutes les 10 minutes, et donc espérer une place dans les 6 prochains blocs. Cependant, il est tout à fait possible qu’un bloc prenne 45 minutes pour être trouvé. Les estimateurs de frais doivent trancher entre l’urgence ou le délai souhaité par l’utilisateur (quelque chose comme « Je veux que cela soit confirmé d’ici la fin de la journée ») et une offre d’espace de bloc (un certain nombre de blocs). De nombreux estimateurs de frais relèvent ce défi en désignant les objectifs de confirmation en nombre de blocs en plus du temps.

En l’absence d’informations sur les transactions avant leur confirmation, on peut créer un estimateur de frais naïf qui utilise des données historiques sur les frais des transaction qui ont tendance à intégrer un bloc. Comme cet estimateur est aveugle aux transactions en attente de confirmation dans les mempools, il deviendrait très imprécis lors de fluctuations inattendues de la demande d’espace de bloc et des longs intervalles de bloc qui se produisent occasionnellement. Son autre faiblesse est sa dépendance à l’égard d’informations entièrement contrôlées par les mineurs, qui pourraient faire grimper les taux en incluant de fausses transactions à taux élevé dans leurs blocs.

Heureusement, le marché de l’espace en blocs n’est pas une vente aux enchères à l’aveugle. Nous avons mentionné dans notre premier article que le fait de conserver un mempool et de participer au réseau de relais de transaction peer-to-peer permet à un nœud de voir ce que les utilisateurs enchérissent. L’estimateur de frais de Bitcoin Core utilise également des données historiques pour calculer la probabilité d’une transaction à un taux de confirmation dans n blocs, mais suit spécifiquement la hauteur à laquelle le nœud voit une transaction pour la première fois et quand il confirme. Cette méthode contourne l’activité qui se produit en dehors du marché des frais publics en l’ignorant. Si les mineurs incluent des transactions artificiellement élevées dans leurs propres blocs, cet estimateur de frais n’est pas biaisé car il n’utilise que les données des transactions qui ont été relayées publiquement avant la confirmation.

Nous avons également des informations sur la manière dont les transactions sont sélectionnées pour les blocs. Dans un article précédent, nous avons mentionné que les nœuds émulaient les politiques de minage afin de conserver les transactions compatibles avec les incitations dans leurs mempools. En développant cette idée, au lieu de regarder uniquement les données passées, nous pourrions créer un estimateur de frais qui simule ce que ferait un mineur. Pour savoir quel tarif une transaction devrait confirmer dans les n blocs suivants, l’estimateur de frais pourrait utiliser l’algorithme d’assemblage de blocs pour projeter les n modèles de bloc suivants à partir de son mempool et calculer le tarif qui dépasserait la ou les dernières transactions faites dans le bloc n.

De toute évidence, l’efficacité de l’approche de cet estimateur de frais dépend de la similitude entre le contenu de son mempool et celui des mineurs, qui ne peut jamais être garantie. Il ne voit pas non plus les transactions qu’un mineur pourrait inclure en raison de motivations extérieures, par exemple les transactions qui appartiennent au mineur ou les frais payés en dehors du protocole. La projection doit également tenir compte des diffusions de transactions supplémentaires entre le moment considéré et le celui où les blocs projetés sont trouvés. Il peut le faire en diminuant la taille de ses blocs projetés pour tenir compte d’autres transactions – mais de combien ?

Cette question souligne une fois de plus l’utilité des données historiques. Un modèle intelligent peut être en mesure d’incorporer des modèles d’activité et de tenir compte des événements externes qui influencent les frais tels que les heures d’ouverture typiques, la consolidation UTXO prévue d’une entreprise et l’activité en réponse aux changements du prix du Bitcoin. Le problème de la prévision de la demande d’espace de bloc reste à explorer et laisse de la place pour l’innovation.

L’estimation des frais est un problème complexe. Une mauvaise estimation des frais peut gaspiller des fonds en payant trop cher, ajouter des frictions à l’utilisation de Bitcoin pour les paiements et faire perdre de l’argent aux utilisateurs L2 en manquant une fenêtre dans laquelle un UTXO verrouillé dans le temps avait un autre tarif de dépense. Une bonne estimation des frais permet aux utilisateurs de communiquer clairement et précisément l’urgence de la transaction aux mineurs, et CPFP et RBF permettent aux utilisateurs de mettre à jour leurs offres si les estimations initiales sont inférieures. Des politiques mempool compatibles avec les incitations, combinées à des outils d’estimation des frais et à des portefeuilles bien conçus, permettent aux utilisateurs de participer à une enchère publique efficace pour l’espace de bloc.

Les estimateurs de frais ne renvoient généralement jamais rien en dessous de 1sat/vB, quelle que soit la durée de l’horizon temporel ou le nombre de transactions en attente de confirmation. Beaucoup considèrent 1sat/vB comme le tarif plancher de facto dans le réseau Bitcoin, en raison du fait que la plupart des nœuds du réseau (y compris les mineurs) n’acceptent jamais rien en dessous de ce tarif, quel que soit le niveau de remplissage de leurs mempools. L’article de la semaine prochaine explorera cette politique et s’intéressera à une autre motivation pour utiliser les frais dans le relais de transaction : la protection contre l’épuisement des ressources.

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.

• LND 0.16.3-beta est une version de maintenance pour cette implémentation populaire de nœuds LN. Les notes de version indiquent que “cette version ne contient que des corrections de bogues et a pour but d’optimiser la logique de surveillance du mempool récemment ajoutée, ainsi que de corriger plusieurs vecteurs de fermeture forcée par inadvertance”. Pour plus d’informations sur la logique de surveillance du mempool, voir Newsletter #248.

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 #26485 permet aux méthodes RPC qui acceptent un paramètre objet options d’accepter les mêmes champs que les paramètres nommés. Par exemple, la méthode RPC bumpfee peut maintenant être appelée avec src/bitcoin-cli -named bumpfee txid fee_rate=10 au lieu de src/bitcoin-cli -named bumpfee txid options='{"fee_rate" : 10}'.
• Eclair #2642 ajoute une RPC closedchannels qui fournit des données sur les canaux fermés du noeud. Voir aussi une PR similaire de Core Lightning mentionnée dans Newsletter #245.
• LND #7645 s’assure que tout taux de frais fourni par l’utilisateur dans les appels RPC à OpenChannel, CloseChannel, SendCoins, et SendMany n’est pas inférieur à un “taux de frais de relais”. Le changement note que “le taux de frais de relais peut avoir une signification légèrement différente selon le backend. Pour bitcoind, c’est effectivement max(relay fee, min mempool fee)”.
• LND #7726 dépensera toujours tous les HTLCs en payant le nœud local si un canal doit être réglé onchain. Il balayera ces HTLC même si cela peut coûter plus cher en frais de transaction qu’ils ne valent. Comparez cela à un PR d’Eclair décrit dans la newsletter de la semaine dernière où ce programme n’essaiera plus de réclamer un HTLC qui est [non économique] topic uneconomical outputs]. Les commentaires dans le fil des RP mentionnent que LND travaille à d’autres changements qui amélioreront sa capacité à calculer les coûts et les gains liés au règlement des HTLC (à la fois offchain et onchain), ce qui lui permettra de prendre des décisions optimales à l’avenir.
• LDK #2293 se déconnecte puis se reconnecte aux pairs s’ils n’ont pas répondu dans un délai raisonnable. Cela peut atténuer un problème avec d’autres logiciels LN qui cessent parfois de répondre, ce qui entraîne la fermeture forcée des canaux.