Le bulletin de cette semaine résume une proposition de modification de la spécification de LN pour permettre des channel factories modulables, renvoie à un rapport et à un nouveau site web pour examiner les transactions sur le signet par défaut utilisant des propositions de soft forks, décrit une mise à jour de la proposition de soft fork multi-parties LNHANCE, et discute d’un document sur les covenants basés sur la rectification plutôt que sur des changements de consensus. Sont également inclus nos sections habituelles annoncant les mises à jour avec les versions candidates, et présente les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Channel factories modulables : ZmnSCPxj a posté sur Delving Bitcoin une proposition pour apporter un petit ensemble de modifications à la spécification BOLT afin de permettre aux logiciels LN existants de gérer des canaux de paiement LN-Penalty au sein d’une channel factory en utilisant un plugin logiciel. Les modifications de spécification permettraient au gestionnaire de la factory (par exemple, un fournisseur de services Lightning, LSP) d’envoyer des messages à un nœud LN qui seraient transmis à un plugin de factory local. De nombreuses opérations seraient similaires aux opérations de splicing, permettant au plugin de réutiliser une quantité significative de code. Les opérations de canal LN-Penalty au sein d’une factory seraient similaires aux canaux zero-conf, ils pourraient donc également réutiliser le code existant.

    La conception de ZmnSCPxj se concentre sur les factories de style SuperScalar (voir le Bulletin #327) mais serait probablement compatible avec d’autres styles de factory (et possiblement d’autres protocoles de contrat multiparte). Rene Pickhardt a répondu pour demander des modifications de spécification supplémentaires qui pourraient permettre d’annoncer les canaux au sein des factories, mais ZmnSCPxj a dit qu’il n’avait délibérément pas considéré ces aspects dans sa conception afin de permettre à la modification de spécification d’être adoptée le plus rapidement possible.

  • ● Rapport d’activité Signet : Anthony Towns a posté sur Delving Bitcoin un résumé de l’activité sur le signet par défaut lié aux proposition de soft forks disponibles via Bitcoin Inquisition. Le post examine l’utilisation de SIGHASH_ANYPREVOUT, y compris les tests de LN-Symmetry et l’émulation de OP_CHECKTEMPLATEVERIFY. Il examine ensuite directement l’utilisation de OP_CHECKTEMPLATEVERIFY, y compris ce qui sont probablement plusieurs constructions différentes de coffre-forts et quelques transactions porteuses de données. Enfin, le post examine l’utilisation de OP_CAT, y compris pour un faucet de preuve de travail (voir le Bulletin #306), un possible coffre-fort ou autre covenant, et la vérification d’une preuve à connaissance nulle STARK. Vojtěch Strnad a répondu qu’il a été inspiré par le post de Towns pour créer un site web qui répertorie “chaque transaction effectuée sur le signet Bitcoin qui utilise l’un des soft forks déployés.”

  • ● Mise à jour de la proposition LNHANCE : Moonsettler a publié sur Delving Bitcoin et également sur la liste de diffusion Bitcoin-Dev une proposition pour un nouvel opcode, OP_PAIRCOMMIT, à ajouter à la proposition de soft fork LNHANCE qui inclut OP_CHECKTEMPLATEVERIFY et OP_CHECKSIGFROMSTACK. Le nouvel opcode permet de faire un engagement de hachage sur une paire d’éléments ; cela est similaire à ce qui pourrait être réalisé en utilisant l’opcode de concaténation proposé OP_CAT ou les opcodes de hachage en flux tels que ceux disponibles dans les sidechains basées sur Elements mais est délibérément limité pour éviter de permettre des covenants récursifs.

    Moonsettler a également discuté sur la liste de diffusion d’autres petites modifications potentielles à la proposition LNHANCE.

  • ● Covenants basés sur la rectification plutôt que sur des changements de consensus : Ethan Heilman a publié sur la liste de diffusion Bitcoin-Dev le résumé d’un article qu’il a coécrit avec Victor Kolobov, Avihu Levy, et Andrew Poelstra. L’article décrit comment les covenants peuvent être créés facilement sans changements de consensus, bien que les dépenses de ces covenants nécessiteraient des transactions non standard et des millions (ou milliards) de dollars en matériel spécialisé et en électricité. Heilman note qu’une application du travail permet aujourd’hui aux utilisateurs d’inclure facilement un chemin de dépense taproot de secours qui peut être utilisé en toute sécurité si une résistance quantique est soudainement nécessaire et que les opérations de signature à courbe elliptique sur Bitcoin sont désactivées.

Changements notables dans le code et la documentation

Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des portefeuilles et services Bitcoin.

  • ● Annonce du protocole de seconde couche Spark : Spark est un protocole offchain, semblable à statechain, qui prend en charge le Lightning Network.

  • ● Annonce du portefeuille Unify : Unify est un portefeuille compatible BIP78 payjoin qui utilise Bitcoin Core et coordonne les PSBTs via NOSTR.

  • ● Lancement de bitcoinutils.dev : Le site bitcoinutils.dev propose une variété d’utilitaires Bitcoin incluant le débogage de scripts ainsi que diverses fonctions de codage et de hachage.

  • ● Disponibilité du Great Restored Script Interpreter : Le Great Restored Script Interpreter est un interpréteur expérimental pour la proposition Great Script Restoration.

Changements notables dans le code et la documentation

Changes récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware WalletInterface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition et BINANAs.

  • ● Bitcoin Core #30666 ajoute la fonction RecalculateBestHeader() pour recalculer le meilleur en-tête en itérant sur l’index des blocs, ce qui est automatiquement déclenché lorsque les commandes RPC invalidateblock et reconsiderblock sont utilisées, ou lorsque des en-têtes valides dans l’index des blocs sont ultérieurement trouvés invalides lors de la validation complète. Cela corrige un problème où la valeur était incorrectement définie après ces événements. Cette PR marque également les en-têtes qui se prolongent à partir d’un bloc invalide comme BLOCK_FAILED_CHILD, les empêchant d’être considérés pour m_best_header.

  • ● Bitcoin Core #30239 rend les sorties de poussière éphémère standard, permettant aux transactions sans frais avec une sortie de poussière d’apparaître dans le mempool, à condition qu’elles soient dépensées simultanément dans un package de transaction. Ce changement améliore l’utilisabilité de constructions avancées telles que les sorties avec connecteur, les ancres avec clé et sans clé (P2A), qui peuvent bénéficier de l’extension de protocoles tels que LN, Ark, arbres de timeout, BitVM2, et d’autres. Cette mise à jour s’appuie sur des fonctionnalités existantes telles que les relais 1P1C, les transactions TRUC et l’éviction de fratrie (voir le Bulletin #328).

  • ● Core Lightning #7833 active par défaut le protocole des offres, retirant son statut expérimental précédent. Cela fait suite à la fusion de sa PR dans le dépôt BOLTs (voir le Bulletin #323).

  • ● Core Lightning #7799 introduit le plugin xpay pour envoyer des paiements en construisant des paiements multipath optimaux, en utilisant le plugin askrene (voir le Bulletin #316) et la commande RPC injectpaymentonion. Il prend en charge le paiement des factures BOLT11 et BOLT12, la définition des durées de nouvelle tentative et des délais de paiement, l’ajout de données de routage à travers les couches, et la réalisation de paiements partiels pour des contributions multi-parties sur une seule facture. Ce plugin est plus simple et plus sophistiqué que l’ancien plugin ‘pay’, mais n’a pas toutes ses fonctionnalités.

  • ● Core Lightning #7800 ajoute une nouvelle commande RPC listaddresses qui retourne une liste de toutes les adresses bitcoin qui ont été générées par le nœud CLN. Cette PR définit également P2TR comme le type de script par défaut pour les dépenses de sortie d’ancrage et pour les adresses de changement de fermeture unilatérale.

  • ● Core Lightning #7102 étend la commande generatehsm pour exécuter non-interactivement avec des options de ligne de commande. Auparavant, vous ne pouviez générer un secret de Module de Sécurité Matérielle (HSM) qu’à travers un processus interactif au terminal, donc ce changement est particulièrement utile pour les installations automatisées.

  • ● Core Lightning #7604 ajoute les commandes RPC bkpr-editdescriptionbypaymentid et bkpr-editdescriptionbyoutpoint au plugin de comptabilité, qui mettent à jour ou définissent la description sur les événements correspondant à l’identifiant de paiement ou à point se sortie respectivement.

  • ● Core Lightning #6980 introduit une nouvelle commande splice qui prend soit un payload JSON soit un script de splice qui définit des actions de splicing complexes et liées, et combine toutes ces opérations multi-canaux en une seule transaction. Cette PR ajoute également la commande RPC addpsbtinput qui permet aux utilisateurs d’ajouter directement des entrées à un PSBT, et ajoute les commandes RPC stfu_channels et abort_channels qui permettent aux utilisateurs de mettre en pause l’activité des canaux ou d’abandonner plusieurs canaux pour activer les mises à niveau de l’engagement des canaux, ce qui est crucial lors de l’exécution d’actions de splice complexes.