La newsletter de cette semaine résume une approche plus efficace des circuits embrouillés et inclut un lien vers une mise à jour de LN-Symmetry. Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Argo : un schéma de circuits embrouillés avec un calcul offchain plus efficace : Robin Linus a posté sur Delving Bitcoin à propos d’un nouveau document de Liam Eagen et Ying Tong Lai décrivant une technique qui permettra une efficacité 1000 fois supérieure pour les verrous embrouillés. La nouvelle technique utilise un MAC (code d’authentification de message) qui encode les fils d’un circuit embrouillé en points de courbe elliptique (EC). Le MAC est conçu pour être homomorphe, permettant à de nombreuses opérations au sein du circuit embrouillé d’être représentées directement comme des opérations sur des points EC. L’amélioration clé est que Argo fonctionne sur des circuits arithmétiques, par opposition aux circuits binaires. Avec un circuit binaire, des millions de portes binaires sont nécessaires pour représenter une multiplication de point de courbe, tandis qu’avec ce circuit arithmétique, vous avez besoin d’une seule porte arithmétique. Le document actuel est le premier de plusieurs éléments nécessaires pour appliquer cette technique à des constructions similaires à BitVM sur Bitcoin.

  • ● Mise à jour LN-Symmetry : Gregory Sanders a posté une mise à jour sur Delving Bitcoin concernant ses travaux précédents sur LN-Symmetry (voir le Bulletin #284).

    Sanders a rebasé son travail précédent de preuve de concept sur les spécifications BOLTs et l’implémentation CLN avec les dernières mises à jour. L’implémentation mise à jour fonctionne désormais sur Bitcoin Inquisition 29.x sur signet avec TRUC, poussière éphémère, P2A, et le relais de paquets 1p1c. Elle prend en charge la fermeture coopérative des canaux, corrige un crash qui empêchait le nœud de redémarrer correctement, et élargit la couverture des tests. Sanders a demandé à d’autres développeurs de tester son nouveau concept sur signet avec Bitcoin Inquisition.

    Sanders a également exploité les capacités LLM pour migrer son travail de APO à OP_TEMPLATEHASH+OP_CSFS+IK (voir le Bulletin #365), a modifié un brouillon BOLT et créé une implémentation basée sur CLN. Cependant, Sanders a ajouté que puisque OP_TEMPLATEHASH n’est pas encore actif sur Bitcoin Inquisition, cette mise à jour ne peut être testée qu’en regtest.

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou quand nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées postées depuis notre dernière mise à jour.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles versions ou d’aider à tester les versions candidates.

  • ● Libsecp256k1 0.7.1 est une version de maintenance de cette bibliothèque pour les opérations cryptographiques liées à Bitcoin qui inclut une amélioration de sécurité augmentant le nombre de cas où la bibliothèque tente d’effacer les secrets de la pile. Elle introduit également un nouveau cadre de tests unitaires et quelques changements dans le système de construction.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #33822 ajoute le support de l’en-tête de bloc à l’interface API libbitcoinkernel (voir le Bulletin #380). Un nouveau type btck_BlockHeader et ses méthodes associées permettent de créer, copier et détruire des en-têtes, ainsi que de récupérer des champs d’en-tête tels que le hash, le hash précédent, le timestamp, la cible de difficulté, la version et le nonce. Une nouvelle méthode btck_chainstate_manager_process_block_header() valide et traite les en-têtes de bloc sans nécessiter le bloc complet, et btck_chainstate_manager_get_best_entry() retourne l’entrée de l’arbre de blocs avec la preuve de travail cumulative la plus importante.

  • ● Bitcoin Core #34269 interdit la création ou la restauration de portefeuilles sans nom lors de l’utilisation des RPC createwallet et restorewallet, ainsi que des commandes create et createfromdump de l’outil portefeuille (voir les Bulletins #45 et #130). Bien que l’interface graphique imposait déjà cette restriction, les RPC et les fonctions sous-jacentes ne le faisaient pas. La migration de portefeuille peut toujours restaurer des portefeuilles sans nom. Voir le Bulletin #387 pour un bug lié aux portefeuilles sans nom.

  • ● Core Lightning #8850 supprime plusieurs fonctionnalités obsolètes : option_anchors_zero_fee_htlc_tx, renommé en option_anchors pour refléter les changements sur les sorties d’ancrage, le RPC decodepay (remplacé par decode), les champs tx et txid dans la réponse de la commande close (remplacés par txs et txids), et estimatefeesv1, le format de réponse original utilisé par le plugin bcli pour retourner les estimations de frais.

  • ● LDK #4349 ajoute une validation pour le padding bech32 lors de l’analyse des offres BOLT12, comme spécifié dans BIP173. Auparavant, LDK acceptait les offres avec un padding invalide, tandis que d’autres implémentations, telles que Lightning-KMP et Eclair, les rejetaient correctement. Une nouvelle variante d’erreur InvalidPadding est ajoutée à l’énumération Bolt12ParseError.

  • ● Rust Bitcoin #5470 ajoute une validation au décodeur pour rejeter les transactions sans sorties, car les transactions Bitcoin valides doivent avoir au moins une sortie.

  • ● Rust Bitcoin #5443 ajoute une validation sur le décodeur pour rejeter les transactions où la somme des valeurs de sortie dépasse MAX_MONEY (21 millions de bitcoins). Cette vérification est liée à CVE-2010-5139, une vulnérabilité historique où un attaquant pourrait créer des transactions avec des valeurs de sortie extrêmement élevées.

  • ● BDK #2037 ajoute la méthode median_time_past() pour calculer le temps médian passé (MTP) pour les structures CheckPoint. Le MTP, défini dans BIP113, est le timestamp médian des 11 blocs précédents et est utilisé pour valider les verrous temporels. Voir le Bulletin #372 pour les travaux précédents permettant cela.

  • ● BIPs #2076 ajoute BIP434 qui définit un message de fonctionnalité P2P qui permettrait aux pairs d’annoncer et de négocier le support de nouvelles fonctionnalités. L’idée généralise le mécanisme de BIP339 (voir le Bulletin #87) mais au lieu de nécessiter un nouveau type de message pour chaque fonctionnalité, BIP434 fournit un message unique et réutilisable pour annoncer et négocier plusieurs mises à niveau P2P. Cela profite à divers cas d’utilisation P2P proposés, incluant le partage de modèles. Voir le Bulletin #386 pour la discussion sur la liste de diffusion.

  • ● BIPs #1500 ajoute BIP346 qui définit l’opcode OP_TXHASH pour tapscript qui pousse sur la pile un digest de hash de parties spécifiées de la transaction de dépense. Cela peut être utilisé pour créer des covenants et réduire l’interactivité dans les protocoles multi-parties. L’opcode généralise OP_CHECKTEMPLATEVERIFY et, combiné avec OP_CHECKSIGFROMSTACK, peut émuler SIGHASH_ANYPREVOUT. Voir les Bulletins #185 et #272 pour les discussions précédentes.