Le bulletin de cette semaine résume un projet de BIP pour le partage de modèles de bloc entre les nœuds complets et annonce une bibliothèque qui permet la délégation de confiance de l’évaluation de script (y compris pour les fonctionnalités non disponibles dans les langages de script natifs de Bitcoin). Sont également incluses nos sections régulières résumant les changements récents apportés aux clients et services, les annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Projet de BIP pour le partage de modèles de bloc : Anthony Towns a posté sur la liste de diffusion Bitcoin-Dev le projet d’un BIP sur la manière dont les nœuds peuvent communiquer à leurs pairs les transactions qu’ils tenteraient de miner dans leur prochain bloc (voir le Bulletin #366). Cela permet au nœud de partager les transactions qu’il acceptera via son mempool et sa politique de minage que ses pairs pourraient normalement rejeter selon leur propre politique, permettant à ces pairs de mettre en cache ces transactions au cas où elles seraient minées (ce qui améliore l’efficacité du relais de bloc compact). Les transactions dans un modèle de bloc d’un nœud sont généralement les transactions non confirmées les plus rentables connues de ce nœud, donc les pairs qui ont précédemment rejeté ces transactions pour des raisons de politique pourraient également les trouver dignes d’une considération supplémentaire.

    Le protocole spécifié dans le projet de BIP est simple. Peu après l’initiation d’une connexion avec un pair, le nœud envoie un message sendtemplate indiquant au pair qu’il est prêt à envoyer des modèles de blocs. À tout moment ultérieur, le pair peut demander un modèle avec un message gettemplate. En réponse à la demande, le nœud répond avec un message template qui contient une liste d’identifiants de transactions courts utilisant le même format qu’un message de bloc compact BIP152. Le pair peut alors demander les transactions qu’il souhaite en incluant l’identifiant court dans un message sendtransactions (également comme dans BIP152). Le projet de BIP permet aux modèles d’être jusqu’à un peu plus de deux fois la taille de la limite de poids de bloc maximum actuelle.

    Un ║fil de discussion Bitcoin sur le partage de modèles a vu cette semaine une discussion supplémentaire sur la manière d’améliorer l’efficacité de la bande passante de la proposition. Les idées discutées incluaient l’envoi uniquement de la différence depuis le modèle précédent (une économie de bande passante estimée à 90%), l’utilisation d’un protocole de réconciliation de l’ensemble tel que celui permis par minisketch (permettant de partager efficacement des modèles beaucoup plus grands), et l’utilisation du codage Golomb-Rice sur les modèles similaires aux filtres de bloc compact (une efficacité estimée à 25%).

  • ● Délégation de confiance pour l’évaluation de script : Josh Doman a posté sur Delving Bitcoin à propos d’une bibliothèque qu’il a écrite qui utilise un environnement d’exécution de confiance (TEE) qui ne signera une dépense de chemin de clé taproot que si la transaction contenant cette dépense satisfait un script. Le script peut contenir des opcodes qui ne sont actuellement pas actifs sur Bitcoin aujourd’hui ou une forme complètement différente de script (par exemple, Simplicity ou bll).

    Cette approche nécessite que ceux qui reçoivent des fonds vers le script fassent confiance au TEE—à la fois qu’il sera encore disponible pour signer à l’avenir et qu’il ne signera qu’une dépense qui satisfait son script d’encumbrance—mais elle permet une expérimentation rapide avec de nouvelles fonctionnalités proposées pour Bitcoin avec une valeur monétaire réelle. Pour réduire la confiance dans la disponibilité future du TEE, un chemin de dépense de secours peut être inclus; par exemple, un chemin timelocked qui permet à un participant de dépenser unilatéralement ses fonds un an après les avoir confiés au TEE.

    La bibliothèque est conçue pour être utilisée avec l’enclave Nitro d’Amazon Web Services (AWS).

Changements dans les services et logiciels clients

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

  • ● ZEUS v0.11.3 publié : La version v0.11.3 inclut des améliorations de la gestion des pairs, BOLT12, et des fonctionnalités de submarine swap.

  • ● Ressources Rust Utreexo : Abdelhamid Bakhta a publié des ressources basées sur Rust pour Utreexo, incluant des matériaux éducatifs interactifs et des liaisons WASM.

  • ● Outils d’observation des pairs et appel à l’action : 0xB10C a publié sur la motivation, l’architecture, le code, les bibliothèques de soutien, et les découvertes de son projet peer-observer. Il cherche à construire “Un groupe décentralisé de personnes qui partagent l’intérêt de surveiller le Réseau Bitcoin. Un collectif pour permettre le partage d’idées, de discussions, de données, d’outils, d’aperçus, et plus encore.”

  • ● Nœud basé sur le noyau Bitcoin Core annoncé : Le backbone Bitcoin a été annoncé comme une démonstration de l’utilisation de la bibliothèque Bitcoin Core Kernel comme fondation d’un nœud Bitcoin.

  • ● SimplicityHL publié : SimplicityHL est un langage de programmation semblable à Rust qui compile vers le langage Simplicity de niveau inférieur récemment activé sur Liquid. Pour plus de lecture, voir le fil de discussion lié.

  • ● Plugin LSP pour BTCPay Server : Le plugin LSP implémente les fonctionnalités côté client de BLIP51, la spécification pour les canaux entrants, dans BTCPay Server.

  • ● Matériel et logiciel de minage Proto annoncés : Proto a annoncé un nouveau matériel de minage Bitcoin et un logiciel de minage open source, construit avec les retours de la communauté précédents.

  • ● Démonstration de résolution d’oracle utilisant CSFS : Abdelhamid Bakhta a publié une démonstration d’un oracle utilisant CSFS, nostr, et MutinyNet pour signer une attestation du résultat d’un événement.

  • ● Relai ajoute le support de taproot : Relai a ajouté le support pour l’envoi vers des adresses taproot.

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.

  • ● LND v0.19.3-beta est une version de maintenance pour cette implémentation populaire de nœud LN contenant des “corrections de bugs importantes”. Plus notablement, “une migration optionnelle […] réduit significativement les besoins en disque et en mémoire pour les nœuds.”

  • ● Bitcoin Core 29.1rc1 est un candidat à la sortie pour une version de maintenance du logiciel de nœud complet prédominant.

  • ● Core Lightning v25.09rc2 est un candidat à la sortie pour une nouvelle version majeure de cette implémentation populaire de nœud LN.

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, BTCPay Server, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

  • ● Bitcoin Core #32896 introduit le support pour la création et la dépense de transactions Topologically Restricted Until Confirmation (TRUC) non confirmées en ajoutant un paramètre version aux RPCs suivants : createrawtransaction, createpsbt, send, sendall, et walletcreatefundedpsbt. Le portefeuille applique les restrictions de transaction TRUC pour la limite de poids, le conflit entre frères, et l’incompatibilité entre les transactions TRUC non confirmées et non-TRUC.

  • ● Bitcoin Core #33106 abaisse le blockmintxfee par défaut à 1 sat/kvB (le minimum possible), et le minrelaytxfee par défaut et incrementalrelayfee à 100 sat/kvB (0.1 sat/vB). Bien que ces valeurs puissent être configurées, il est conseillé aux utilisateurs d’ajuster les valeurs minrelaytxfee et incrementalrelayfee ensemble. Les autres feerates minimum restent inchangées, mais les feerates minimum par défaut du portefeuille sont attendues pour être abaissées dans une version future. Les motivations pour ce changement vont de la croissance considérable du nombre de blocs minés avec des transactions sous 1 sat/vB et du nombre de pools minant ces transactions à une augmentation du taux de change du Bitcoin.

  • ● Core Lightning #8467 étend xpay (voir le Bulletin #330) en ajoutant le support pour le paiement de noms lisibles par l’homme BIP353 (HRN) (par exemple, satoshi@bitcoin.com) et en lui permettant de payer directement les offres BOLT12, éliminant le besoin d’exécuter la commande fetchinvoice d’abord. Sous le capot, xpay récupère les instructions de paiement en utilisant la commande RPC fetchbip353 du plugin cln-bip353 introduit dans Core Lightning #8362.

  • ● Core Lightning #8354 commence à publier des notifications d’événements pay_part_start et pay_part_end pour le statut de parties de paiement spécifiques envoyées avec MPP. La notification pay_part_end indique la durée du paiement et si celui-ci a été réussi ou échoué. Si le paiement échoue, un message d’erreur est fourni et, si l’oignon d’erreur n’est pas corrompu, des informations supplémentaires sur l’échec sont données, telles que la source de l’erreur et le code d’échec.

  • ● Eclair #3103 introduit le support pour simple taproot channels, exploitant le MuSig2 de multisignature sans script pour réduire la consommation de poids de transaction de 15% et améliorer la confidentialité des transactions. Les transactions de financement et les fermetures coopératives sont indiscernables des autres transactions P2TR. Cette PR inclut également le support pour le dual funding et le splicing dans les canaux taproot simples, et active les mises à niveau d’engagement de canal au nouveau format taproot lors d’une transaction de splice.

  • ● Eclair #3134 remplace le multiplicateur de poids de pénalité pour les HTLCs bloqués par le CLTV expiry delta lors de l’évaluation de la réputation des pairs pour l’endorsement HTLC (voir le Bulletin #363), pour mieux refléter combien de temps un HTLC bloqué immobilisera la liquidité. Pour atténuer la pénalité disproportionnée des HTLCs bloqués avec un delta d’expiration CLTV maximum, cette PR ajuste le paramètre de dégradation de la réputation (half-life) de 15 à 30 jours et le seuil de paiement bloqué (max-relay-duration) de 12 secondes à 5 minutes.

  • ● LDK #3897 étend son implémentation de stockage de pairs en détectant la perte de l’état du canal lors de la récupération de sauvegarde, en désérialisant la copie du pair et en la comparant à l’état local.