Bulletin d’information hebdomadaire Bitcoin Optech du 7 décembre 2022 traduit par @copinmalin. La lettre d’information de cette semaine décrit une mise en œuvre des ancrages éphémères et comprend nos sections habituelles avec le résumé d’une réunion du club de révision des PR de Bitcoin Core, des annonces de nouvelles versions et de versions candidates, et des descriptions de changements notables dans les projets d’infrastructure Bitcoin les plus répandus. Nouvelles Mise en œuvre d’ancrages éphémères : Greg Sanders a posté sur la liste de diffusion de Bitcoin-Dev qu’il a mis en œuvre son idée d’ancres éphémères (voir Newsletter #223). Les sorties d’ancrages sont une technique existante d’exclusions du CPFP mise à disposition
Topics:
Ailleurs considers the following as important:
This could be interesting, too:
Wayne Jones writes South Korea’s Crypto Investor Base Increased by 21% in 2024 H1: Report
Jordan Lyanchev writes Is This The Last Week Bitcoin (BTC) Will Ever Be Below K?
Wayne Jones writes RWA Sector Poised for 0B Growth by 2030: Report
CryptoVizArt writes Ripple Price Analysis: is XRP About to Crash Much Lower Than %related_posts%.5?
Bulletin d’information hebdomadaire Bitcoin Optech du 7 décembre 2022 traduit par @copinmalin.
La lettre d’information de cette semaine décrit une mise en œuvre des ancrages éphémères et comprend nos sections habituelles avec le résumé d’une réunion du club de révision des PR de Bitcoin Core, des annonces de nouvelles versions et de versions candidates, et des descriptions de changements notables dans les projets d’infrastructure Bitcoin les plus répandus.
Nouvelles
- Mise en œuvre d’ancrages éphémères : Greg Sanders a posté sur la liste de diffusion de Bitcoin-Dev qu’il a mis en œuvre son idée d’ancres éphémères (voir Newsletter #223). Les sorties d’ancrages sont une technique existante d’exclusions du CPFP mise à disposition par Bitcoin Core et utilisée dans le protocole LN pour s’assurer que les deux parties impliquées dans un contrat peuvent percevoir des frais pour une transaction liée à ce contrat CPFP. Les sorties d’ancrages présentent plusieurs inconvénients, dont certains sont fondamentaux (voir la Newsletter #224), mais d’autres peuvent être résolus. Les ancrages éphémères s’appuient sur la proposition de relais de transaction v3 pour permettre aux transactions v3 d’inclure une sortie à valeur nulle payant un script qui est essentiellement
OP_TRUE, ce qui permet à cette transaction d’avoir des frais majorés en CPFP par n’importe qui sur le réseau avec un UTXO dépensable. La transaction enfant peut elle-même être payée par n’importe qui d’autre avec un UTXO dépensable. En combinaison avec d’autres parties de la proposition de relais de transaction v3, on espère que cela éliminera toutes les préoccupations basées sur la politique concernant les attaques par épinglage de transaction contre les transactions de protocole de contrat sensibles au temps. Qui plus est, puisque n’importe qui peut faire payer une transaction contenant un résultat éphémère, elle peut être utilisée pour les protocoles contractuels impliquant plus de deux participants. La règle d’exclusion existante de Bitcoin Core ne fonctionne de manière fiable que pour deux participants et les tentatives précédentes pour l’augmenter nécessitaient une limite supérieure arbitraire de participants. La mise en œuvre des ancres éphémères par Sanders permet de commencer à tester l’idée conjointement avec les autres comportements de relais de transaction v3 précédemment mis en œuvre par l’auteur de cette proposition.
Bitcoin Core PR Review Club
Dans cette section mensuelle, nous résumons une récente réunion du Bitcoin Core PR Review Club en soulignant certaines des questions et réponses importantes. Cliquez sur une question ci-dessous pour voir un résumé de la réponse de la réunion.
Faire passer les transactions d’ascendants non confirmés au taux de frais cible est une PR de Xekyo (Murch) et glozow qui améliore la précision du calcul des frais du portefeuille dans le cas où des UTXOs non confirmés sont sélectionnés comme entrées. Sans le PR, les frais sont fixés trop bas si les taux de frais de certaines transactions non confirmées utilisées comme entrées sont inférieurs à ceux de la transaction en cours de construction. Le PR corrige ce problème en ajoutant des frais suffisants pour « accélérer » ces transactions sources à faible taux de frais vers le même taux de frais que celui visé par la nouvelle transaction.
Notez que même sans ce PR, le processus de sélection des pièces essaiera d’éviter les dépenses provenant de transactions non confirmées de faible valeur. Ce PR sera bénéfique dans les cas où cela ne peut être évité.
Ajuster les frais pour tenir compte de ces transactions ancestrales s’avère être similaire au choix des transactions à inclure dans un bloc, donc ce PR ajoute une classe appelée MiniMiner.
Cette revue des PR s’étendait sur deux semaines.
- Quel est le problème que cette PR règle ?
- En quoi consiste le “cluster” d’une transaction ?
- Ce PR introduit
MiniMiner& qui duplique certains des algorithmes du mineur actuel ; aurait-il été préférable d’unifier ces deux implémentations par une refactorisation ? - Pourquoi le
MiniMinernécessite-t-il un cluster entier ? Pourquoi ne peut-il pas simplement utiliser l’union des ensembles d’ascendants de chaque transaction ? - Si la transaction X a un taux de frais d’ascendance plus élevé que la transaction indépendante Y, est-il possible pour un mineur de donner la priorité à Y sur X (c’est-à-dire de miner Y avant X) ?
- Est-ce que
CalculateBumpFees()peut surestimer, sous-estimer, les deux, ou aucun des deux ? De combien ? - On donne au
MiniMinerune liste d’UTXOs (outpoints) que le portefeuille pourrait être intéressé à dépenser. Étant donné un point de sortie, quels sont ses cinq états possibles ? - Quelle est l’approche adoptée dans la commande “Transactions parentes de sauts non confirmées sur taux de frais cible” ?
- Comment le PR gère-t-il le fait de dépenser des UTXO non confirmés dont les ancêtres se chevauchent ?
Mises à jour et version candidate
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.
- BTCPay Server 1.7.1 est la dernière version du logiciel de traitement des paiements auto hébergés le plus largement utilisé pour Bitcoin.
- Core Lightning 22.11 est la prochaine version majeure de CLN. C’est également la première version à utiliser un nouveau système de numérotation des versions [1]. Plusieurs nouvelles fonctionnalités sont incluses, notamment un nouveau gestionnaire de plugins, et de multiples corrections de bogues.
- LND 0.15.5-beta est une version de maintenance de LND. Elle ne contient que des corrections de bogues mineurs, selon ses notes de publication.
- BDK 0.25.0 est une nouvelle version de cette bibliothèque pour la création de portefeuilles.
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 #19762 met à jour l’interface RPC (et, par extension, (
Bitcoin-cli) pour permettre aux arguments nommés et positionnels d’être utilisés ensemble. Ce changement rend plus pratique l’utilisation de valeurs de paramètres nommés sans avoir à les nommer tous. La description de la PR fournit des exemples démontrant la commodité accrue de cette approche ainsi qu’un alias shell pratique pour les utilisateurs fréquents debitcoin-cli. - Core Lightning #5722 ajoute la documentation sur la manière d’utiliser le plugin d’interface GRPC.
- Eclair #2513 met à jour la façon dont il utilise le portefeuille Bitcoin Core pour s’assurer qu’il envoie toujours de la monnaie aux sorties P2WPKH. Ceci est le résultat de Bitcoin Core #23789 (voir Newsletter #181) où le projet a abordé un problème de confidentialité pour les utilisateurs de nouveaux types de sortie (par exemple taproot). Auparavant, un utilisateur qui définissait le type d’adresse par défaut de son portefeuille sur taproot créait également des sorties de changement taproot lorsqu’il payait quelqu’un. S’il payait quelqu’un qui n’utilisait pas taproot, il était facile pour les tiers de déterminer quelle sortie était le paiement (la sortie non-taproot) et quelle sortie était la modification (la sortie taproot). Après le changement de Bitcoin Core, le système essayera par défaut d’utiliser le même type de sortie de changement que la sortie payée, par exemple, un paiement vers une sortie segwit native entraînera également une sortie de changement segwit native. Cependant, le protocole LN requiert certains types de sortie. Par exemple une sortie P2PKH ne peut pas être utilisée pour ouvrir un canal LN. Pour cette raison, les utilisateurs d’Eclair avec Bitcoin Core doivent s’assurer qu’ils ne génèrent pas de sorties de monnaie d’un type incompatible avec LN.
- Rust Bitcoin #1415 commence à utiliser le Kani Rust Verifier pour prouver certaines propriétés du code de Rust Bitcoin. Cela complète les autres tests d’intégration continue effectués sur le code, comme le fuzzing.
- BTCPay Server #4238 ajoute un endpoint de remboursement de facture à l’API Greenfield de BTCPay, une API plus récente différente de l’API originale inspirée de BitPay.
[1] Les éditions précédentes de ce bulletin d’information affirmaient que Core Lightning utilisait le schéma de versionnement sémantique et que les nouvelles versions continueraient à utiliser ce schéma à l’avenir. Rusty Russell a décrit pourquoi CLN ne peut pas adhérer complètement à ce schéma. Nous remercions Matt Whitlock de nous avoir informés de notre précédente erreur.