Le bulletin de cette semaine relaie une demande de commentaires sur une proposition visant à supprimer la prise en charge du message du protocole P2P BIP35 mempool dans Bitcoin Core et comprend nos sections habituelles avec des résumés des principales questions et réponses du Bitcoin Stack Exchange, des annonces de nouvelles mises à jour et de versions candidates, ainsi que des résumés des principaux changements apportés aux logiciels d’infrastructure Bitcoin les plus répandus.

Nouvelles

  • ● Proposition de suppression du message P2P mempool du BIP35 : Will Clark s’est exprimé sur la liste de diffusion Bitcoin-Dev à propos d’un PR qu’il a ouvert pour supprimer le support du message P2P mempool spécifié à l’origine dans BIP35. Dans son implémentation originale, un nœud recevant un message mempool répondait au pair demandeur avec un message inv contenant les txids de toutes les transactions dans son mempool. Son homologue pouvait alors envoyer un message normal getdata contenant les txids de toutes les transactions qu’il souhaitait recevoir. Le BIP décrit trois motivations pour ce message : les diagnostics de réseau, permettre aux clients légers d’interroger les transactions non confirmées, et permettre aux mineurs qui ont récemment redémarré de connaître les transactions non confirmées (à l’époque, Bitcoin Core ne sauvegardait pas son mempool dans un stockage persistant lors de l’arrêt).

    Cependant, diverses techniques de réduction de la confidentialité ont été développées par la suite pour faciliter la détermination du nœud qui a diffusé la première transaction en abusant du message mempool ou de la possibilité d’utiliser getdata pour demander n’importe quelle transaction du mempool. Pour améliorer la confidentialité de l’origine de la transaction, Bitcoin Core a ensuite supprimé la possibilité de demander des transactions non annoncées à d’autres nœuds et a limité le message mempool à une utilisation avec des filtres de bloom de transaction (comme spécifié dans BIP37) pour les clients légers. Plus tard encore, Bitcoin Core a désactivé par défaut le support du filtre bloom (voir Bulletin #56), ne l’autorisant qu’à être utilisé avec des pairs configurés avec l’option -whitelist (voir Bulletin #60); cela désactive également par défaut le mempool de BIP35.

    Le PR de Clark sur Bitcoin Core a reçu le soutien du projet, bien que certains partisans pensent que les filtres Bloom de BIP37 devraient être supprimés en premier. Sur la liste de diffusion, la seule réponse à ce jour note que les clients légers qui se connectent à leur propre nœud de confiance peuvent actuellement utiliser BIP35 et BIP37 pour se renseigner sur les transactions non confirmées d’une manière beaucoup plus efficace en termes de bande passante que toute autre méthode actuellement facilement disponible dans Bitcoin Core. Le répondant a suggéré que Bitcoin Core fournisse un mécanisme alternatif avant de supprimer l’interface actuelle.

    Toute personne utilisant le message BIP35 mempool à quelque fin que ce soit est priée de nous faire part de ses commentaires. Vous pouvez répondre soit au message de la liste de diffusion, soit au PR dont le lien figure ci-dessus.

Selection de Q&R du Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les collaborateurs d’Optech cherchent des réponses à leurs questions—ou, lorsqu’ils ont quelques moments libres, aident les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en avant certaines des questions et réponses les plus populaires depuis notre dernière mise à jour.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● LDK 0.0.115 est une version de cette bibliothèque permettant de créer des portefeuilles et des applications compatibles avec le LN. Elle inclut plusieurs nouvelles fonctionnalités et corrections de bugs, notamment une meilleure prise en charge du protocole expérimental offers et une amélioration de la sécurité et de la confidentialité.

  • ● LND v0.16.1-beta est une version mineure de cette implémentation de LN qui inclut plusieurs corrections de bogues et d’autres améliorations. Les notes de version indiquent que le delta de CLTV par défaut a été augmenté de 40 blocs à 80 blocs (voir Bulletin #40 où nous avons couvert un changement précédent dans le delta de la CLTV par défaut du LND).

  • ● Core Lightning 23.05rc1 est une version candidate pour la prochaine version de l’implémentation du LN.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

  • ● LND #7564 permet maintenant aux utilisateurs d’un backend qui fournit un accès au mempool de surveiller les transactions non confirmées contenant des pré-images pour les HTLC dans les canaux du nœud. Cela permet au nœud de résoudre les HTLC plus rapidement qu’en attendant que ces transactions soient confirmées.

  • ● LND #6903 met à jour le RPC openchannel avec une nouvelle option fundmax qui allouera tous les fonds du canal vers un nouveau canal, à l’exception de tout montant qui doit être conservé dans la chaîne pour ajouter des frais aux canaux utilisant anchor outputs.

  • ● LDK #2198 augmente le temps d’attente de LDK avant d’envoyer un message au gossip annonçant qu’un canal est hors service (par exemple, parce que le pair distant n’est pas disponible). Auparavant, LDK annonçait qu’un canal était hors service au bout d’une minute environ. D’autres nœuds LN attendent plus longtemps et une proposition pour la mise à jour du protocole du gossip LN suggère de remplacer les champs d’horodatage par des hauteurs de blocs au lieu de Unix epoch time, ce qui ne permettrait de mettre à jour un message du gossip qu’une fois par bloc (approximativement toutes les 10 minutes en moyenne). Bien que le PR note que l’envoi de mises à jour plus lentes implique des compromis, il met à jour LDK pour qu’il attende environ 10 minutes avant de diffuser un message de désactivation de canal.

  • ● Bitcoin Inquisition #23 ajoute une partie du support pour les ancrages éphémères. Elle ne prend pas en charge le relais de transaction v3, dont dépendent les ancrages éphémères pour mettre fin aux attaques par épinglage de transaction.