La newsletter de cette semaine décrit brièvement une nouvelle bibliothèque permettant de compresser les descripteurs de script de sortie pour une utilisation dans les codes QR. Sont également incluses nos sections régulières résumant une réunion du Bitcoin Core PR Review Club, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Descripteurs compressés : Josh Doman a publié sur Delving Bitcoin pour annoncer une bibliothèque qu’il a écrite qui encode les descripteurs de script de sortie dans un format binaire qui réduit leur taille d’environ 40%. Cela peut être particulièrement utile lorsque les descripteurs sont sauvegardés à l’aide de codes QR. Son post entre dans les détails de l’encodage et mentionne qu’il prévoit d’incorporer la compression dans sa bibliothèque de sauvegarde de descripteurs chiffrés (voir le Bulletin #358).

Bitcoin Core PR Review Club

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

Améliorer les limites de déni de service de TxOrphanage est un PR par glozow qui change la logique d’éviction de TxOrphanage pour garantir à chaque pair les ressources pour au moins 1 paquet de taille maximale pour la résolution d’orphelins. Ces nouvelles garanties améliorent significativement le relai de paquets opportunistes 1-parent-1-enfant 1p1c relay, surtout (mais pas seulement) dans des conditions adverses.

Le PR modifie les limites globales existantes de l’orphelinat et introduit de nouvelles limites par pair. Ensemble, elles protègent contre une utilisation excessive de la mémoire et l’épuisement computationnel. Le PR remplace également l’approche d’éviction aléatoire par une algorithmique, calculant un score de DoS par pair.

Note : le PR a subi quelques changements significatifs depuis le Review Club, le plus important étant l’utilisation d’une limite de score de latence au lieu d’une limite d’annonce.

  • Pourquoi la limite actuelle de taille maximale globale de TxOrphanage de 100 transactions avec éviction aléatoire est-elle problématique ?

    Elle permet à un pair malveillant de submerger un nœud avec des transactions orphelines, finissant par causer l’éviction de toutes les transactions légitimes d’autres pairs. Cela peut être utilisé pour empêcher la réussite du relais de transactions opportunistes 1-parent-1-enfant, puisque l’enfant ne pourrait pas rester longtemps dans l’orphelinat. ➚

  • Comment fonctionne le nouvel algorithme d’éviction à un haut niveau ?

    L’éviction n’est plus aléatoire. L’algorithme identifie le pair se comportant le « pire » basé sur un « score de DoS » et évince l’annonce de transaction la plus ancienne de ce pair. Cela protège les pairs se comportant bien de voir les enfants de leurs transactions évictés par un pair se comportant mal. ➚

  • Pourquoi est-il souhaitable de permettre aux pairs de dépasser leurs limites individuelles ?

    Les pairs peuvent utiliser plus de ressources simplement parce qu’ils sont un pair utile, qui diffuse des transactions utiles telles que les CPFPs. ➚

  • Le nouvel algorithme évince les annonces au lieu des transactions. Quelle est la différence et pourquoi est-ce important ?

    Une annonce est une paire composée d’une transaction et du pair qui l’a envoyée. En évinçant les annonces, un pair malveillant ne peut pas évincer une transaction qui a également été envoyée par un pair honnête. ➚

  • Qu’est-ce que le “DoS Score” d’un pair et comment est-il calculé ?

    Le DoS score d’un pair est le maximum entre son “score de mémoire” (mémoire utilisée / mémoire réservée) et son “score CPU” (annonces faites / limite d’annonces). Utiliser un score combiné unique simplifie la logique d’éviction en une seule boucle qui cible le pair dépassant le plus agressivement l’une ou l’autre de ses limites. ➚

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.

Changements notables dans le code et la documentation

Changements 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.

  • ● Core Lightning #8377 renforce les exigences de parsing des factures BOLT11 en mandatant que les expéditeurs ne paient pas une facture si un secret de paiement est manquant ou si un champ obligatoire tel que p (hash de paiement), h (hash de description), ou s (secret), a une longueur incorrecte. Ces changements sont faits pour s’aligner sur les mises à jour récentes de la spécification (voir les Bulletins #350 et #358).

  • ● BDK #1957 introduit le regroupement RPC pour l’historique des transactions, les preuves de Merkle, et les demandes d’en-tête de bloc pour optimiser la performance de scan complet et de synchronisation avec un backend Electrum. Ce PR ajoute également la mise en cache des ancres pour sauter la revalidation de la Vérification Simple de Paiement (SPV) (voir le Bulletin #312) pendant une synchronisation. En utilisant des données d’exemple, l’auteur a observé des améliorations de performance de 8,14 secondes à 2,59 secondes avec le regroupement d’appels RPC sur un scan complet et de 1,37 secondes à 0,85 secondes avec la mise en cache pendant une synchronisation.

  • ● BIPs #1888 retire H comme marqueur de chemin renforcé de BIP380, ne laissant que le h canonique et l’alternative '. Le récent Bulletin #360 avait noté que la grammaire avait été clarifiée pour permettre les trois marqueurs, mais puisque peu (voire aucun) des implémentations de descripteur ne le supportent réellement (ni Bitcoin Core ni rust-miniscript ne le font), la spécification est resserrée pour l’interdire.