La newsletter de cette semaine inclut 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

Aucune nouvelle significative cette semaine n’a été trouvée dans aucune de nos sources.

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.

• ● Cake Wallet ajoute le support de Lightning : Cake Wallet a annoncé le support du Lightning Network en utilisant le SDK Breez et une intégration Spark, incluant les adresses Lightning.

• ● Sparrow 2.4.0 et 2.4.2 disponibles : Sparrow 2.4.0 ajoute les champs BIP375 PSBT pour le support des portefeuilles matériels silent payment et ajoute un importateur Codex32. Sparrow 2.4.2 ajoute le support des transactions v3.

• ● Blockstream Jade ajoute Lightning via Liquid : Blockstream a annoncé que le portefeuille matériel Jade (via l’application Green 5.2.0) peut maintenant interagir avec Lightning en utilisant les submarine swaps qui convertissent les paiements Lightning en Bitcoin Liquid (L-BTC), tout en gardant les clés hors ligne.

• ● Lightning Labs lance des outils pour agents : Lightning Labs a lancé une boîte à outils open-source permettant aux agents IA d’opérer sur Lightning sans intervention humaine ni clés API en utilisant le protocole L402.

• ● Tether lance MiningOS : Tether a lancé MiningOS, un système d’exploitation open-source pour gérer les opérations de minage de Bitcoin. Le logiciel sous licence Apache 2.0 est indépendant du matériel avec une architecture modulaire, P2P.

• ● Réactivation du réseau FIBRE : Localhost Research a annoncé la réactivation de FIBRE (Fast Internet Bitcoin Relay Engine), précédemment arrêté en 2017. Le redémarrage inclut une base Bitcoin Core v30 et une suite de surveillance, avec six nœuds publics déployés globalement. FIBRE complète les relais de blocs compacts pour la propagation de blocs à faible latence.

• ● TUI pour Bitcoin Core lancé : Bitcoin-tui, une interface terminal pour Bitcoin Core, se connecte via JSON-RPC pour afficher les données de la blockchain et du réseau, avec surveillance du mempool, recherche et diffusion de transactions, et gestion des pairs.

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.

• ● Bitcoin Core 31.0rc1 est un candidat à la version pour la prochaine version majeure de l’implémentation de nœud complet prédominante. Un guide de test est disponible.

• ● BTCPay Server 2.3.6 est une version mineure de cette solution de paiement auto-hébergée qui ajoute un filtrage par étiquette dans la barre de recherche de portefeuille, inclut les données de méthode de paiement dans le point de terminaison de l’API des factures, et permet aux plugins de définir des politiques de permission personnalisées. Elle comprend également plusieurs corrections de bugs.

Changements notables dans le code et la documentation

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

• ● Bitcoin Core #31560 étend le RPC dumptxoutset (voir le Bulletin #72), permettant à l’instantané du set UTXO d’être écrit dans un pipe nommé. Cela permet de diffuser la sortie directement vers un autre processus, évitant la nécessité d’écrire le dump complet sur disque. Cela se combine bien avec l’outil utxo_to_sqlite.py (voir le Bulletin #342), permettant de créer une base de données SQLite du set UTXO à la volée.

• ● Bitcoin Core #31774 commence à protéger le matériel de clé de chiffrement AES-256 utilisé pour le chiffrement du portefeuille avec secure_allocator pour l’empêcher d’être échangé sur disque par le système d’exploitation lorsqu’il manque de mémoire, et le supprime de la mémoire lorsqu’il n’est plus utilisé. Lorsqu’un utilisateur chiffre ou déverrouille son portefeuille, la phrase secrète est utilisée pour dériver une clé AES qui chiffre ou déchiffre les clés privées du portefeuille. Auparavant, ce matériel de clé était alloué en utilisant l’allocateur standard, ce qui signifie qu’il pourrait être échangé sur disque ou rester en mémoire.

• ● Core Lightning #8817 corrige plusieurs problèmes d’interopérabilité de splice avec Eclair qui ont été découverts lors de tests d’interopérabilité entre implémentations (voir les Bulletins #331 et #355 pour les travaux d’interopérabilité précédents). CLN gère maintenant les messages channel_ready qu’Eclair peut envoyer pendant le réétablissement du splice avant de reprendre la négociation, corrige la gestion des erreurs RPC qui pourrait causer un crash, et implémente la retransmission de signature d’annonce via de nouveaux TLVs channel_reestablish.

• ● Eclair #3265 et LDK #4324 commencent à rejeter les offres BOLT12 où offer_amount est fixé à zéro, pour s’aligner avec les derniers changements dans la spécification BOLT (voir le Bulletin #396).

• ● LDK #4427 ajoute le support pour le bumping de frais RBF des transactions de financement splice qui ont été négociées mais pas encore verrouillées, en réentrante dans l’état de quiescence. Lorsque les deux pairs tentent de RBF simultanément, le perdant du tie-breaker de quiescence peut contribuer en tant qu’accepteur. Les contributions antérieures sont automatiquement réutilisées lorsque la contrepartie initie un RBF, empêchant ainsi l’augmentation des frais d’éliminer silencieusement les fonds de splice d’un pair. Voir le Bulletin #396 pour le support de contribution de l’accepteur de splice de base sur lequel cela se construit.

• ● LDK #4484 augmente la limite acceptée maximale de poussière des canaux à 10 000 satoshis pour les canaux ancre avec des HTLCs sans frais, incluant les canaux zéro-conf. Cela met en œuvre la recommandation de BOLTs #1301 (voir le Bulletin #395).

• ● BIPs #1974 publie BIP446 et BIP448 en tant que brouillons de BIP. BIP446 spécifie OP_TEMPLATEHASH, un nouvel opcode tapscript qui pousse un hash de la transaction de dépense sur la pile (voir le Bulletin #365 pour la proposition initiale). BIP448 regroupe OP_TEMPLATEHASH avec OP_INTERNALKEY et OP_CHECKSIGFROMSTACK pour proposer des “Transactions (Re)liables natives de Taproot”. Ce bundle de covenant permettrait LN-Symmetry ainsi que de réduire l’interactivité et de simplifier d’autres protocoles de seconde couche.