Le bulletin de cette semaine résume une vulnérabilité affectant les anciennes versions d’Eclair et résume les recherches sur les paramètres de taux de frais des nœuds complets. 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

• ● Vulnérabilité Eclair : Matt Morehouse a posté sur Delving Bitcoin pour annoncer la divulgation responsable d’une vulnérabilité affectant les anciennes versions d’Eclair. Il est recommandé à tous les utilisateurs d’Eclair de mettre à niveau vers la version 0.12 ou supérieure. La vulnérabilité permettait à un attaquant de diffuser une ancienne transaction d’engagement pour voler tous les fonds actuels d’un canal. En plus de corriger la vulnérabilité, les développeurs d’Eclair ont ajouté une suite de tests complète conçue pour détecter des problèmes similaires.

• ● Recherche sur les paramètres de taux de frais : Daniela Brozzoni a posté sur Delving Bitcoin les résultats d’un scan de près de 30 000 nœuds complets acceptant des connexions entrantes. Chaque nœud a été interrogé sur son filtre de frais BIP133, qui indique le taux de frais minimum auquel il acceptera actuellement de relayer des transactions non confirmées. Lorsque les mémoires tampons des nœuds ne sont pas pleines, il s’agit du taux de frais minimum de relais de transaction par défaut du nœud. Ses résultats indiquent que la plupart des nœuds utilisent le défaut de 1 sat/vbyte (s/v), qui est depuis longtemps le défaut dans Bitcoin Core. Environ 4 % des nœuds utilisaient 0.1 s/v, le défaut pour la version 30.0 à venir de Bitcoin Core, et environ 8 % des nœuds n’ont pas répondu à la requête, indiquant qu’ils pourraient être des nœuds espions.

  Un petit pourcentage des nœuds utilisait une valeur de feefilter de 9 170 997 (10 000 s/v), valeur que le développeur 0xB10C a noté être celle que Bitcoin Core définit, par arrondissement, lorsque le nœud est à plus de 100 blocs derrière la pointe de la chaîne et se concentre sur la réception de données de bloc plutôt que sur des transactions qui pourraient être confirmées dans des blocs ultérieurs.

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.

• ● Implications des changements OP_RETURN dans la prochaine version 30.0 de Bitcoin Core ? Pieter Wuille décrit ses perspectives sur l’efficacité et les inconvénients de l’utilisation de la politique de mempool et de relais pour affecter le contenu des blocs minés.

• ● Si les limites de relais OP_RETURN sont inefficaces, pourquoi supprimer la protection au lieu de la conserver comme découragement par défaut ? Antoine Poinsot explique le mauvais incitatif créé par la valeur limite par défaut actuelle d’OP_RETURN dans Bitcoin Core et la raison de sa suppression.

• ● Quels sont les pires scénarios de stress pour les OP_RETURN non plafonnés dans Bitcoin Core v30 ? Vojtěch Strnad et Pieter Wuille répondent à une liste de scénarios extrêmes qui pourraient se produire avec le changement de politique de limite par défaut d’OP_RETURN.

• ● Si OP_RETURN avait besoin de plus d’espace, pourquoi le plafond de 80 octets a-t-il été supprimé au lieu d’être augmenté à 160 ? Ava Chow et Antoine Poinsot exposent les considérations contre une valeur par défaut d’OP_RETURN de 160 octets, incluant une aversion à fixer continuellement le plafond, les grands mineurs existants contournant déjà le plafond, et les risques de ne pas anticiper l’activité future sur la chaîne.

• ● Si les données arbitraires sont inévitables, est-ce que supprimer les limites d’OP_RETURN déplace la demande vers des méthodes de stockage plus nuisibles (comme les adresses gonflant l’UTXO) ? Ava Chow souligne que la suppression de la limite d’OP_RETURN offre des incitations à utiliser une alternative moins nuisible pour le stockage des données de sortie dans certaines situations.

• ● Si le déplafonnement d’OP_RETURN n’augmente pas l’ensemble UTXO, comment contribue-t-il encore au gonflement de la blockchain et à la pression de centralisation ? Ava Chow explique comment l’utilisation accrue des sorties OP_RETURN affecte l’utilisation des ressources des nœuds Bitcoin.

• ● Comment le déplafonnement d’OP_RETURN impacte-t-il la qualité du marché des frais à long terme et le budget de sécurité ? Ava Chow répond à une série de questions sur l’utilisation hypothétique d’OP_RETURN et son impact sur les revenus futurs de minage de Bitcoin.

• ● Assurance que la blockchain ne souffrira pas de contenu illégal avec OP_RETURN de 100KB ? L’utilisateur jb55 fournit plusieurs exemples de schémas d’encodage possibles pour les données, concluant “Donc non, en général, vous ne pouvez pas vraiment arrêter ce genre de choses dans un réseau décentralisé résistant à la censure.”

• ● Quelle analyse montre que le déplafonnement d’OP_RETURN ne nuira pas à la propagation des blocs ou au risque d’orphelins ? Ava Chow souligne que bien qu’il n’existe pas de jeu de données isolant spécifiquement les grands OP_RETURN, les analyses précédentes des blocs compacts et des blocs obsolètes indiquent qu’il n’y a pas de raison de s’attendre à ce qu’ils se comportent différemment.

• ● Où Bitcoin Core conserve-t-il les clés d’obfuscation XOR pour les fichiers de données de blocs et les index de bases de données LevelDB ? Vojtěch Strnad note que la clé chainstate est stockée dans LevelDB sous la clé “\000obfuscate_key” et la clé de données de blocs et d’annulation est stockée dans le fichier blocks/xor.dat.

• ● Quelle est la robustesse de la transmission de transaction 1p1c dans bitcoin core 28.0 ? Glozow clarifie que le manque de robustesse mentionné dans la PR originale de relai opportuniste one parent one child (1P1C) signifie “pas garanti de fonctionner, particulièrement en présence d’adversaires ou lorsque le volume est vraiment élevé donc nous manquons des choses.”

• ● Comment puis-je permettre à getblocktemplate d’inclure des transactions sous 1 sat/vbyte ? L’utilisateur inersha découvre les paramètres requis non seulement pour relayer des transactions sous 1 sat/vbyte mais aussi pour les inclure dans un modèle de bloc candidat.

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.0rc1 est un candidat à la version pour la prochaine version majeure de ce logiciel de nœud de vérification complète. Veuillez consulter le guide de test du candidat à la version 30.

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 #33333 émet un message d’avertissement au démarrage si le paramètre dbcache d’un nœud dépasse un plafond dérivé de la RAM système du nœud, pour prévenir les erreurs de manque de mémoire ou un swapping intensif. Pour les systèmes avec moins de 2GB de RAM, le seuil d’avertissement dbcache est de 450MB ; autrement, le seuil est de 75% de la RAM totale. La limite de 16GB pour dbcache a été supprimée en septembre 2024 (voir le Bulletin #321).

• ● Bitcoin Core #28592 augmente le taux de relais de transactions par pair de 7 à 14 pour les pairs entrants en raison d’une présence accrue de transactions plus petites sur le réseau. Le taux pour les pairs sortants est 2,5 fois plus élevé, passant à 35 transactions par seconde. Le taux de relais de transactions limite le nombre de transactions qu’un nœud envoie à ses pairs.

• ● Eclair #3171 supprime PaymentWeightRatios, une méthode de recherche de chemin qui supposait une uniformité dans les soldes des canaux, et la remplace par une approche probabiliste nouvellement introduite basée sur l’historique des tentatives de paiement passées (voir le Bulletin #371).

• ● Eclair #3175 commence à rejeter les offres BOLT12 impayables où les champs offer_chains, offer_paths, invoice_paths, et invoice_blindedpay sont présents mais vides.

• ● LDK #4064 met à jour sa logique de vérification de signature pour s’assurer que si le champ n (clé publique du bénéficiaire) est présent, la signature est vérifiée contre celui-ci. Sinon, la clé publique du bénéficiaire est extraite de la facture BOLT11 avec une signature high-S ou low-S. Cette PR aligne les vérifications de signature avec les propositions BOLTs #1284 et avec d’autres implémentations telles qu’Eclair (Voir le Bulletin #371).

• ● LDK #4067 ajoute le support pour dépenser les sorties d’ancres éphémères P2A des transactions d’engagement sans frais, assurant les pairs de canal peuvent récupérer leurs fonds onchain. Voir le Bulletin #371 pour l’implémentation par LDK des canaux d’engagement sans frais.

• ● LDK #4046 permet à un expéditeur souvent hors ligne d’envoyer des paiements asynchrones à un destinataire souvent hors ligne. L’expéditeur définit un drapeau dans le message update_add_htlc pour indiquer que le HTLC doit être retenu par le LSP jusqu’à ce que le destinataire revienne en ligne et envoie un release_held_htlc message onion pour réclamer le paiement.

• ● LDK #4083 déprécie le point de terminaison pay_for_offer_from_human_readable_name pour supprimer les API de paiement HRN BIP353 en double. Les portefeuilles sont encouragés à utiliser le crate bitcoin-payment-instructions pour analyser et résoudre les instructions de paiement avant d’appeler pay_for_offer_from_hrn pour payer une offre à partir d’un HRN BIP353 (par exemple, satoshi@nakamoto.com).

• ● LND #10189 met à jour son système sweeper (voir le Bulletin #346) pour reconnaître correctement le code d’erreur ErrMinRelayFeeNotMet et réessayer les transactions échouées par augmentation des frais jusqu’à ce que la diffusion soit réussie. Auparavant, l’erreur serait mal appariée, et la transaction ne serait pas réessayée. Cette PR améliore également l’estimation du poids en tenant compte d’une sortie de changement supplémentaire possible, ce qui est pertinent dans les canaux d’overlay taproot utilisés pour améliorer les Taproot Assets de LND.

• ● BIPs #1963 met à jour le statut des BIPs qui spécifient les filtres de blocs compacts, BIP157 et BIP158, de Draft à Final car ils ont été déployés dans Bitcoin Core et d’autres logiciels depuis 2020.