Bulletin hebdomadaire Bitcoin Optech #269

Bulletin d’information hebdomadaire Bitcoin Optech du 20 septembre 2023 traduit par @copinmalin.

Le bulletin de cette semaine partage l’annonce d’un prochain événement autour de la recherche et inclut 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

• Bitcoin, journée de la recherche : Sergi Delgado Segura et Clara Shikhelman ont publié sur les listes de diffusion Bitcoin-Dev et Lightning-Dev pour annoncer un événement intitulé Bitcoin Research Day qui se tiendra à New York le 27 octobre. Il s’agira d’un événement en présentiel avec des présentations de plusieurs chercheurs bien connus dans le domaine de Bitcoin. Les réservations sont nécessaires et quelques créneaux de présentation courts (5 minutes) étaient encore disponibles au moment de la publication.

Modifications apportées aux services et aux logiciels clients

• Sortie de Bitcoin-like Script Symbolic Tracer (B’SST) : B’SST est un outil d’analyse de scripts Bitcoin et Elements qui fournit des informations sur les scripts, y compris les “conditions que le script impose, les échecs possibles, les valeurs possibles pour les données”.
• Démo du vérificateur de chaîne d’en-têtes STARK : Le projet ZeroSync a annoncé une démonstration et un dépôt utilisant les STARK pour prouver et vérifier une chaîne d’en-têtes de blocs Bitcoin.
• Sortie de JoinMarket v0.9.10 : La version v0.9.10 ajoute la prise en charge de RBF pour les transactions non-coinjoin et des mises à jour d’estimation des frais, entre autres améliorations.
• BitBox ajoute miniscript : Le dernier micrologiciel BitBox02 ajoute la prise en charge de miniscript en plus d’une correction de sécurité et d’améliorations de convivialité.
• Machankura annonce une fonctionnalité de regroupement additive : Le fournisseur de services Bitcoin Machankura a annoncé une fonctionnalité bêta qui prend en charge le regroupement additif en utilisant RBF dans un portefeuille taproot qui a une condition de dépense FROST threshold.
• Outil de simulation SimLN Lightning : SimLN est un outil de simulation pour les chercheurs LN et les développeurs de protocoles/applications qui génèrent une activité de paiement LN réaliste. SimLN prend en charge LND et CLN, avec des travaux en cours sur Eclair et LDK-Node.

Mises à jour et versions candidates

• Core Lightning 23.08.1 est une version de maintenance qui inclut plusieurs corrections de bugs.
• LND v0.17.0-beta.rc4 est une version candidate pour la prochaine version majeure de cette implémentation populaire de nœud LN. Une nouvelle fonctionnalité expérimentale majeure prévue pour cette version, qui pourrait bénéficier de tests, est la prise en charge des “canaux simples taproot”.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, CoreLightning, Eclair, LDK, LND, libsecp256k1, Interface Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’Amélioration Bitcoin (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

• Bitcoin Core #26152 s’appuie sur une interface précédemment ajoutée (voir le Bulletin #252) pour payer tout déficit de frais dans les entrées sélectionnées pour être incluses dans une transaction. Un déficit de frais se produit lorsque le portefeuille doit sélectionner des UTXO avec des ascendants non confirmés qui paient des frais bas. Afin que la transaction de l’utilisateur paie le taux de frais sélectionné par l’utilisateur, la transaction doit payer des frais suffisamment élevés pour payer à la fois ses ascendants non confirmés à faible taux de frais et elle-même. En bref, ce PR garantit qu’un utilisateur qui choisit un taux de frais—en définissant une priorité qui affectera la confirmation de la transaction—recevra réellement cette priorité même si le portefeuille doit dépenser des UTXO non confirmés. Tous les autres portefeuilles que nous connaissons ne peuvent garantir une certaine priorité basée sur le taux de frais que s’ils ne dépensent que des UTXO confirmés. Voir également le Bulletin #229 pour un résumé d’une réunion du Bitcoin Core PR Review Club sur ce PR.
• Bitcoin Core #28414 met à jour le RPC walletprocesspsbt pour inclure une transaction sérialisée complète (en hexadécimal) si l’étape de traitement du portefeuille a abouti à une transaction prête à être diffusée. Cela évite à l’utilisateur d’appeler finalizepsbt sur un PSBT déjà final.
• Bitcoin Core #28448 déprécie le paramètre de configuration rpcserialversion (version de sérialisation RPC). Cette option a été introduite lors de la transition vers le segwit v0 pour permettre aux anciens programmes d’accéder aux blocs et aux transactions au format réduit (sans aucun champ segwit). À ce stade, tous les programmes devraient être mis à jour pour gérer les transactions segwit et cette option ne devrait plus être nécessaire, bien qu’elle puisse être temporairement réactivée en tant qu’API dépréciée, comme décrit dans les notes de version ajoutées par le PR.
• Bitcoin Core #28196 ajoute une partie substantielle du code nécessaire pour prendre en charge le protocole de transport v2 tel que spécifié dans BIP324 ainsi qu’un test de brouillage approfondi du code. Cela n’active aucune nouvelle fonctionnalité, mais réduit la quantité de code qui devra être ajoutée pour activer ces fonctionnalités dans les futurs PR.
• Eclair #2743 ajoute un RPC bumpforceclose qui permettra de demander manuellement au nœud de dépenser la sortie d’ancrage d’un canal pour augmenter les frais CPFP d’une transaction d’engagement. Les nœuds Eclair effectuent automatiquement une augmentation des frais lorsque cela est nécessaire, mais cela permet à un opérateur d’accéder manuellement à la même capacité.
• LDK #2176 augmente la précision avec laquelle LDK tente de deviner de manière probabiliste la quantité de liquidité disponible dans les canaux distants à travers lesquels il a tenté de router des paiements. La précision est descendue jusqu’à 0,01500 BTC dans un canal de 1,00000 BTC ; la nouvelle précision descend maintenant à environ 0,00006 BTC dans un canal de même taille. Cela peut légèrement augmenter le temps nécessaire pour trouver un chemin pour un paiement, mais les tests indiquent qu’il n’y a pas de différence majeure.
• LDK #2413 prend en charge l’envoi de paiements vers des chemins masqués et permet de recevoir des paiements vers des chemins où un seul saut final est masqué (masqué) par le dépensier. PR #2514, également fusionné cette semaine, fournit un autre support pour les paiements masqués dans LDK.
• LDK #2371 ajoute la prise en charge de la gestion des paiements en utilisant des offres. Il permet à une application cliente utilisant LDK d’utiliser une offre pour enregistrer son intention de payer une facture, en chronométrant la tentative de paiement si une offre envoyée ne se traduit jamais par une facture reçue, puis en utilisant le code existant dans LDK pour payer la facture (y compris les nouvelles tentatives si les premières échouent).