Bulletin Hebdomadaire Bitcoin Optech #250

by
Ailleurs
My articles My books
Follow on:

Bulletin d’information hebdomadaire Bitcoin Optech du 10 mai 2023 traduit par @copinmalin.

Le bulletin de cette semaine résume un article sur le protocole PoWswap et comprend nos sections habituelles avec le résumé d’une réunion du Bitcoin Core PR Review Club, des annonces de nouvelles versions et de versions candidates, et des descriptions des principaux changements apportés aux logiciels d’infrastructure Bitcoin les plus répandus. Nous avons également inclus une courte section célébrant les cinq ans de Bitcoin Optech et notre 250e bulletin.

Nouvelles

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.

• Core Lightning 23.05rc2 est une version candidate de la prochaine version de l’implémentation du LN.
• Bitcoin Core 24.1rc2 est une version candidate pour une version de maintenance de la version actuelle de Bitcoin Core.
• Bitcoin Core 25.0rc1 est une version candidate de la prochaine version majeure de Bitcoin Core.

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.

Ajout de getprioritisationmap, suppression d’une entrée mapDeltas lorsque delta==0 est un PR de Gloria Zhao (glozow) qui améliore la fonctionnalité de Bitcoin Core permettant aux mineurs de modifier les frais de mempool effectifs, et donc la priorité minière (plus élevée ou plus basse), de certaines transactions (voir la prioritisetransaction RPC). L’augmentation (si elle est positive) ou la diminution (si elle est négative) des frais est appelée fee delta. Les valeurs de priorisation des transactions sont conservées sur disque dans le fichier mempool.dat et sont restaurées au redémarrage du noeud.

L’une des raisons pour lesquelles un mineur peut donner la priorité à une transaction est de tenir compte d’un paiement de frais de transaction hors bande ; la transaction concernée sera traitée comme si elle avait des frais plus élevés lorsqu’il s’agira de choisir les transactions à inclure dans le modèle de bloc du mineur.

La PR ajoute une nouvelle RPC, getprioritisationmap, qui retourne l’ensemble des transactions priorisées. La PR supprime également les entrées de priorisation inutiles, qui peuvent survenir si l’utilisateur remet les deltas à zéro.

• Qu’est-ce que la structure de données mapDeltas et pourquoi est-elle nécessaire ? C’est là que sont stockées les valeurs de priorité par transaction. Ces valeurs affectent les décisions locales d’extraction et d’éviction, ainsi que les calculs des taux d’ascendants et de descendants. ➚
• La hiérarchisation des transactions affecte-t-elle l’algorithme d’estimation des frais ? L’estimation des frais doit prédire avec précision les décisions attendues des mineurs (dans ce cas, d’autres mineurs), et ces mineurs n’ont pas les mêmes priorités que nous, puisqu’elles sont locales. ➚
• Comment une entrée est-elle ajoutée à mapDeltas ? Quand est-elle supprimée ? Elle est ajoutés par la RPC prioritisetransaction, et aussi quand le noeud redémarre, à cause d’une entrée dans mempool.dat. Ils sont supprimés lorsqu’un bloc contenant la transaction est ajouté à la chaîne, ou lorsque la transaction est remplacée. ➚
• Pourquoi ne pas supprimer l’entrée d’une transaction dans mapDeltas lorsqu’elle quitte le mempool (parce que, par exemple, elle a expiré ou a été expulsée parce que le feerate est tombé en dessous du feerate minimum) ? La transaction peut revenir dans le mempool. Si son entrée mapDeltas avait été supprimée, l’utilisateur devrait redonner la priorité à la transaction. ➚
• Si une transaction est retirée de mapDeltas parce qu’elle est incluse dans un bloc, mais que le bloc est ensuite ré-organisé, la priorité de la transaction ne devra-t-elle pas être rétablie ? Oui, mais les réorganisations devraient être rares. En outre, le paiement hors bande peut en fait prendre la forme d’une transaction en bitcoins, et il peut donc être nécessaire de la refaire également. ➚
• Pourquoi devrions-nous autoriser la priorisation d’une transaction qui n’est pas présente dans le pool de mémoire ? Parce que la transaction peut ne pas être dans le mempool yet. Et il se peut même qu’elle ne soit pas en mesure d’entrer dans le pool de mémoire en premier lieu sur la base de ses propres frais (sans la priorisation). ➚
• Quel est le problème si nous ne nettoyons pas mapDeltas ? Le principal problème est l’allocation de mémoire inutile. ➚
• Quand le fichier mempool.dat (y compris mapDeltas) est-il écrit de la mémoire vers le disque ? Lors d’un arrêt complet, et en exécutant la commande RPC savemempool. ➚
• Sans le PR, comment les mineurs peuvent-ils nettoyer les mapDeltas (c’est-à-dire supprimer les entrées dont la valeur de priorité est nulle) ? Le seul moyen est de redémarrer le nœud, puisque les priorisations à valeur nulle ne sont pas chargées dans mapDeltas lors du redémarrage. Avec le PR, l’entrée mapDeltas est supprimée dès que sa valeur est fixée à zéro. Ceci a l’effet bénéfique supplémentaire que les priorisations à valeur nulle ne sont pas écrites sur le disque. ➚

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 #26094 ajoute les champs block hash et height à getbalances, gettransaction, et getwalletinfo. Ces appels RPC verrouillent l’état de la chaîne pour s’assurer qu’ils sont à jour avec le dernier bloc et ils bénéficient donc de l’inclusion du hash et de la hauteur du bloc dans la réponse.
• Bitcoin Core #27195 permet de supprimer tous les récepteurs externes d’une transaction qui est remplacée en utilisant la RPC bumpfee du portefeuille interne de Bitcoin Core. L’utilisateur fait cela en faisant en sorte que la seule sortie de la transaction de remplacement paie sa propre adresse. Si la transaction de remplacement est confirmée, cela empêche les destinataires originaux d’être payés, ce qui est parfois décrit comme “l’annulation” d’un paiement Bitcoin.
• Eclair #1783 ajoute une API cpfpbumpfees pour CPFP l’augmentation des frais d’une ou plusieurs transactions. Le PR met également à jour la liste des paramètres recommandés pour l’exécution de Bitcoin Core afin de s’assurer que la création d’une transaction avec majoration des frais est une option viable.
• LND #7568 ajoute la possibilité de définir des bits de caractéristiques LN supplémentaires lors du démarrage du nœud. Il supprime également la possibilité de désactiver tout bit de caractéristique codé en dur ou défini pendant l’exécution (mais des bits supplémentaires peuvent toujours être ajoutés et désactivés ultérieurement). Une mise à jour de la proposition connexe dans BLIPs #24 note que les bits de caractéristique personnalisés BOLT11 sont limités à une valeur exprimée maximale de 5114.
• LDK #2044 apporte plusieurs modifications à la suggestion d’itinéraire de LDK pour les factures BOLT11, le mécanisme qu’un nœud LN récepteur peut utiliser pour suggérer des itinéraires à utiliser par un nœud utilisateur. Avec cette fusion, seuls trois canaux sont suggérés, la prise en charge des nœuds fantômes de LDK est améliorée (voir Newsletter #188), et les trois canaux choisis le sont pour des raisons d’efficacité et de confidentialité. La discussion sur le PR inclut plusieurs commentaires perspicaces sur les implications pour la vie privée de la fourniture d’indications d’itinéraires.

Célébration de la lettre d’information Optech #250

Bitcoin Optech a été fondé, en partie, pour “faciliter l’amélioration des relations entre les entreprises et la communauté open source”. Cette lettre d’information hebdomadaire a été lancée pour donner aux cadres et aux développeurs des entreprises utilisant Bitcoin un meilleur aperçu de ce que la communauté open source est en train de construire. En tant que tel, nous nous sommes d’abord concentrés sur la documentation des travaux susceptibles d’affecter les entreprises.

Nous avons rapidement découvert que les lecteurs professionnels n’étaient pas les seuls à être intéressés par ces informations. De nombreux contributeurs aux projets Bitcoin n’avaient pas le temps de lire toutes les discussions sur les listes de diffusion relatives au développement du protocole ou de surveiller les changements majeurs dans d’autres projets. Ils appréciaient que quelqu’un les informe des développements qu’ils pourraient trouver intéressants ou qui pourraient affecter leur travail.

Depuis près de cinq ans, nous avons le plaisir de fournir ce service. Nous avons essayé d’élargir cette simple mission en proposant également un guide de compatibilité des technologies du portefeuille, un index de plus de 100 sujets d’intérêt, et un podcast de discussion hebdomadaire avec des invités qui incluent de nombreux contributeurs dont nous avons eu le privilège d’écrire sur leurs travaux.

Rien de tout cela ne serait possible sans nos nombreux contributeurs qui, au cours de l’année écoulée, ont été les suivants : Adam Jonas, Copinmalin, David A. Harding, Gloria Zhao, Jiri Jakes, Jon Atack, Larry Ruane, Mark “Murch” Erhardt, Mike Schmidt, nechteme, Patrick Schwegler, Shashwat Vangani, Shigeyuki Azuchi, Vojtěch Strnad, Zhiwei “Jeffrey” Hu, et plusieurs autres personnes qui ont apporté des contributions spéciales à des sujets particuliers.

Nous sommes également éternellement reconnaissants à nos sponsors fondateurs Wences Casares, John Pfeffer et Alex Morcos, ainsi qu’à nos nombreux soutiens financiers.

Nous vous remercions de votre lecture. Nous espérons que vous continuerez à le faire lorsque nous publierons les 250 prochains bulletins d’information.