Le bulletin de cette semaine décrit une vulnérabilité affectant les anciennes versions de Bitcoin Core et inclut nos sections habituelles avec le résumé d’une réunion du Bitcoin Core PR Review Club, il annonce les mises à jour et les versions candidates, et présente les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

• ● Divulgation d’une vulnérabilité affectant les versions de Bitcoin Core antérieures à 25.1 : Antoine Poinsot a annoncé à la liste de diffusion Bitcoin-Dev la divulgation finale de vulnérabilité précédant la nouvelle politique de divulgation de Bitcoin Core (voir le Bulletin #306). Le rapport de vulnérabilité détaillé note que les versions de Bitcoin Core 25.0 et antérieures étaient susceptibles à une réponse inappropriée du protocole P2P qui retarderait une demande de bloc jusqu’à 10 minutes. La solution a été de permettre que les blocs “puissent être demandés simultanément jusqu’à 3 pairs de blocs compacts à large bande passante , dont l’un doit être une connexion sortante.” Les versions 25.1 et ultérieures incluent le correctif.

Bitcoin Core PR Review Club

Dans cette section mensuelle, nous résumons une récente réunion du Bitcoin Core PR Review Club, en soulignant certaines des questions et réponses importantes. Cliquez sur une question ci-dessous pour voir un résumé de la réponse de la réunion.

Ephemeral Dust est une PR par instagibbs qui fait des transactions avec de la poussière éphémère standard, améliorant la facilité d’utilisation des ancres avec ou sans clé (P2A). Cela est pertinent pour plusieurs schémas de contrat hors chaîne, y compris ceux utilisés par le Lightning Network, Ark, les Arbres de Timeout, et d’autres constructions avec de grands arbres pré-signés ou d’autres contrats intelligents de large-N partie.

Avec les changements de politique de poussière éphémère, les transactions sans frais avec une sortie poussière sont autorisées dans la mempool si une transaction enfant payant les frais qui dépense immédiatement la sortie poussière est connue du nœud.

• La poussière est-elle restreinte par le consensus ? La politique ? Les deux ?

  Les sorties dust sont uniquement restreintes par les règles de politique, elles ne sont pas affectées par le consensus. ➚

• Comment la poussière peut-elle être problématique ?

  Les sorties poussières (ou non économiques) valent moins que les frais nécessaires pour les dépenser. Puisqu’elles peuvent être dépensées, elles ne peuvent pas être élaguées (*) de l’ensemble UTXO. Comme leur dépense est non économique, elles restent souvent non dépensées, augmentant la taille de l’ensemble UTXO. Un ensemble UTXO plus grand augmente les exigences en ressources pour les nœuds. Cependant, les UTXOs peuvent toujours être dépensées en raison d’incitations externes au-delà de leur valeur en satoshis, comme dans le cas des sorties d’ancre. ➚

• Pourquoi le terme éphémère est-il significatif ? Quelles sont les règles proposées spécifique à la poussière éphémère ?

  Le terme ‘éphémère’ indique que la production de poussière est destinée à être dépensée rapidement. Les règles concernant la poussière éphémère exigent que la transaction parente soit sans frais et qu’elle ait exactement une transaction enfant qui dépense la sortie de poussière. ➚

• Pourquoi est-il important d’imposer une restriction de frais ?

  Un objectif clé est d’empêcher que les sorties de poussière restent non dépensées lorsqu’elles sont confirmées. En exigeant que la transaction parente soit sans frais, les mineurs n’ont pas d’incitation à miner le parent sans l’enfant. Puisque la poussière éphémère est une règle de politique, et non une règle de consensus, les incitations économiques jouent un rôle crucial. ➚

• En quoi les relais 1P1C et les transactions TRUC sont-ils pertinents pour la poussière éphémère ?

  Comme une transaction de poussière éphémère doit être sans frais, elle ne peut pas être relayée seule, rendant des mécanismes comme 1-parent-1-enfant (1P1C) essentiels. Les transactions TRUC (v3) sont limitées à un seul parent non confirmé, ce qui est conforme à l’exigence de la poussière éphémère. TRUC est actuellement le seul moyen de permettre des transactions avec un taux de frais inférieur au minrelaytxfee. ➚

Mises à jour et versions candidates

Nouvelles versions et candidats à la version pour les projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à jour vers les nouvelles versions ou d’aider à tester les versions candidates .

• ● Bitcoin Core 27.2 est une mise à jour de maintenance pour la série de versions précédente contenant des corrections de bugs. Tout utilisateur qui ne passera pas bientôt à la dernière version, 28.0, devrait envisager de se mettre à jour au moins vers cette nouvelle version de maintenance.

• ● Libsecp256k1 0.6.0 est une version de cette bibliothèque d’opérations cryptographiques liées à Bitcoin. “Cette version ajoute un module MuSig2, introduit une méthode significativement plus robuste pour effacer les secrets de la pile, et supprime les fonctions secp256k1_scratch_space inutilisées.”

Changements notables dans le code et la documentation

Changes récents notables 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.

• ● LDK #3360 ajoute la retransmission des messages channel_announcement tous les six blocs pendant une semaine après la confirmation du canal public. Cela élimine la dépendance vis-à-vis des pairs pour la retransmission et assure que les canaux sont toujours visibles pour le réseau.

• ● LDK #3207 introduit le support pour inclure des demandes de facture dans les messages oignon des paiements asynchrones lors du paiement de factures statiques BOLT12 en tant qu’expéditeur toujours en ligne. Ce point ne figurait pas dans la PR couverte par le bulletin #321. L’inclusion des demandes de facture dans les oignons de paiement s’étend également aux nouvelles tentatives. Voir le Bulletin #321.