Le bulletin de cette semaine partage une mise à jour sur la proposition pour que les nœuds partagent leur modèle de bloc actuel et résume un article décrivant une construction de coffre-fort sans covenant. 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

  • ● Discussion continue sur le partage de modèle de bloc : La discussion a continué autour de la proposition pour que les pairs de nœuds complets s’envoient occasionnellement leur modèle actuel pour le prochain bloc en utilisant le codage compact block relay (voir les Bulletins #366 et #368). Des préoccupations ont été soulevées concernant la vie privée et l’empreinte digitale des nœuds, et l’auteur a décidé de déplacer le brouillon actuel vers le dépôt Bitcoin Inquisition Numbers and Names Authority (BINANA), pour aborder ces considérations et affiner le document. Le brouillon a reçu le code BIN-2025-0002.

  • ● B-SSL, une couche de signature Bitcoin sécurisée : Francesco Madonna a posté sur Delving Bitcoin à propos d’un concept qui est un modèle de coffre-fort sans covenant utilisant taproot, OP_CHECKSEQUENCEVERIFY, et OP_CHECKLOCKTIMEVERIFY. Dans le post, il mentionne qu’il utilise des primitives Bitcoin existantes, ce qui est important car la plupart des propositions de coffre-fort nécessitent un soft fork.

    Dans la conception, il y a trois chemins de dépense différents :

    1. Un chemin rapide pour le fonctionnement normal où un Service de Commodité (CS) optionnel peut faire respecter le délai choisi.

    2. Un retour d’un an avec le gardien B.

    3. Un chemin de gardien de trois ans en cas de disparition ou d’événements d’héritage.

    Il y a 6 clés différentes A, A₁, B, B₁, C et CS où B₁, et C sont détenues en garde et sont utilisées uniquement en même temps dans le chemin de récupération.

    Cette configuration crée un environnement où l’utilisateur peut verrouiller ses fonds et être assez sûr que les gardiens auxquels il a confié ses fonds ne voleront pas. Bien que cela ne restreigne pas où les fonds peuvent se déplacer comme le ferait un covenant, cette configuration offre un schéma plus résilient pour l’auto-garde avec des gardiens. Dans le post, Francesco appelle les lecteurs à examiner et discuter du livre blanc avant que quiconque essaie de mettre en œuvre cette idée.

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 30.0 est la dernière version du nœud complet prédominant du réseau. Ses notes de version décrivent plusieurs améliorations significatives, y compris un nouveau plafond de 2500 sigops legacy dans les transactions standard, plusieurs sorties de porteur de données (OP_RETURN) désormais standard, une datacarriersize par défaut augmentée à 100 000, un taux de frais minimum de relais par défaut et un taux de frais de relais incrémental de 0.1sat/vb, un taux de frais minimum de bloc par défaut de 0.001sat/vb, des protections améliorées contre les attaques DoS par orphelinage de transactions, un nouvel outil CLI bitcoin, une interface de communication inter-processus (IPC) expérimentale pour les intégrations de Stratum v2, une nouvelle implémentation de coinstatsindex, l’option natpmp désormais activée par défaut, le support pour les portefeuilles hérités étant retiré au profit des portefeuilles descriptor, et le support pour dépenser et créer des transactions TRUC, parmi de nombreuses autres mises à jour.

  • ● Bitcoin Core 29.2 est une version mineure contenant plusieurs corrections de bugs pour P2P, mempool, RPC, CI, documentation et d’autres problèmes. Veuillez consulter les notes de version pour plus de détails.

  • ● LDK 0.1.6 est une version de cette bibliothèque populaire pour la construction d’applications compatibles LN qui inclut des correctifs de vulnérabilités de sécurité liées aux DoS et au vol de fonds, des améliorations de performance, et 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, Inquisition Bitcoin, et BINANAs.

  • ● Eclair #3184 améliore le flux de fermeture coopérative en renvoyant un message shutdown lors de la reconnexion quand un avait déjà été envoyé avant la déconnexion, comme spécifié dans BOLT2. Pour les canaux simple taproot, Eclair génère un nouveau nonce de fermeture pour le renvoi et le stocke, permettant au nœud de produire une closing_sig valide plus tard.

  • ● Core Lightning #8597 empêche un crash qui se produisait lorsqu’un pair direct renvoyait une réponse failmsg après que CLN a envoyé un message onion malformé via sendonion ou injectpaymentonion. Désormais, CLN traite cela comme un échec de premier saut simple et retourne une erreur propre au lieu de planter. Auparavant, cela était traité comme un failonion crypté venant de plus loin en aval.

  • ● LDK #4117 introduit une dérivation déterministe et facultative de la remote_key qui utilise la static_remote_key. Cela permet aux utilisateurs de récupérer des fonds en cas de fermeture forcée en utilisant uniquement la phrase de sauvegarde. Auparavant, la remote_key dépendait de l’aléatoire spécifique à chaque canal, nécessitant l’état du canal pour récupérer les fonds. Ce nouveau schéma est facultatif pour les nouveaux canaux, mais s’applique automatiquement lors du splicing des existants.

  • ● LDK #4077 ajoute les événements SplicePending et SpliceFailed, le premier étant émis une fois qu’une transaction de financement splice est négociée, diffusée et verrouillée par les deux parties (sauf dans le cas d’un RBF). Le dernier événement est émis lorsque un splice avorte avant le verrouillage en raison d’un échec interactive-tx, d’un message tx_abort, d’une fermeture de canal, ou d’une déconnexion/rechargement pendant un état quiescent.

  • ● LDK #4154 met à jour la gestion de la surveillance on-chain de preimage pour s’assurer que les transactions de réclamation sont uniquement créées pour les HTLCs dont le hash de paiement correspond au preimage récupéré. Auparavant, LDK tentait de réclamer tout HTLC réclamable (ceux expirés et ceux avec un preimage connu), ce qui risquait de créer des transactions de réclamation invalides et une perte potentielle de fonds si la contrepartie expirait un autre HTLC en premier.