Le bulletin de cette semaine décrit une proposition pour accélérer le téléchargement initial des blocs de Bitcoin Core, avec une implémentation de preuve de concept qui montre une accélération d’environ cinq fois par rapport aux paramètres par défaut de Bitcoin Core. Sont également inclus nos sections régulières résumant une réunion du Bitcoin Core PR Review Club, annoncant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Accélération SwiftSync pour le téléchargement initial des blocs : Sebastian Falbesoner a posté sur Delving Bitcoin une démonstration d’implémentation et les résultats de performance pour SwiftSync, une idée proposée par Ruben Somsen lors d’une récente réunion de développeurs de Bitcoin Core et plus tard publiée sur la liste de diffusion. À l’heure actuelle, les résultats les plus récents publiés dans le fil montrent une accélération de 5,28x du téléchargement initial des blocs (IBD pour initial block download) par rapport aux paramètres IBD par défaut de Bitcoin Core (qui utilise assumevalid mais pas assumeUTXO), réduisant le temps de synchronisation initial d’environ 41 heures à environ 8 heures.

    Avant d’utiliser SwiftSync, une personne ayant déjà synchronisé son nœud à un bloc récent crée un fichier d’indices qui indique quels outputs de transaction seront dans l’ensemble UTXO à ce bloc (c’est-à-dire, quels outputs seront non dépensés). Cela peut être encodé de manière efficace en quelques centaines de mégaoctets pour la taille actuelle de l’ensemble UTXO. Le fichier d’indices indique également à quel bloc il a été généré, que nous appellerons le bloc terminal SwiftSync.

    L’utilisateur effectuant SwiftSync télécharge le fichier d’indices et l’utilise lors du traitement de chaque bloc précédant le bloc terminal SwiftSync pour ne stocker les outputs dans la base de données UTXO que si le fichier d’indices indique que l’output restera dans l’ensemble UTXO lorsque le bloc terminal SwiftSync sera atteint. Cela réduit massivement le nombre d’entrées qui sont ajoutées, puis plus tard retirées, de la base de données UTXO pendant l’IBD.

    Pour s’assurer que le fichier d’indices est correct, chaque output créé non stocké dans la base de données UTXO est ajouté à un accumulateur cryptographique. Chaque output dépensé est retiré de l’accumulateur. Lorsque le nœud atteint le bloc terminal SwiftSync, il s’assure que l’accumulateur est vide, signifiant que chaque output vu a été dépensé plus tard. Si cela échoue, cela signifie que le fichier d’indices était incorrect et que l’IBD doit être effectué à nouveau depuis le début sans utiliser SwiftSync. De cette manière, les utilisateurs n’ont pas besoin de faire confiance au créateur du fichier d’indices—un fichier malveillant ne peut pas entraîner un état UTXO incorrect; il peut seulement gaspiller quelques heures de ressources informatiques de l’utilisateur.

    Une propriété supplémentaire de SwiftSync qui n’a pas encore été implémentée est de permettre la validation parallèle des blocs pendant l’IBD. Cela est possible parce que assumevalid ne vérifie pas les scripts des blocs plus anciens, les entrées ne sont jamais retirées de la base de données UTXO avant le bloc terminal SwiftSync, et l’accumulateur utilisé ne suit que l’effet net des sorties ajoutées (créées) et retirées (dépensées). Cela élimine toute dépendance entre les blocs avant le bloc terminal SwiftSync. La validation parallèle pendant l’IBD est également une caractéristique de Utreexo pour certaines des mêmes raisons.

    La discussion a examiné plusieurs aspects de la proposition. L’implémentation originale de Falbesoner utilisait l’accumulateur MuHash (voir le Bulletin #123), qui a été montré résistant à l’attaque d’anniversaire généralisée. Somsen a décrit une approche alternative qui pourrait être plus rapide. Falbesoner s’est interrogé sur la sécurité cryptographique de l’approche alternative mais, puisqu’elle était simple, l’a quand même mise en œuvre et a trouvé qu’elle accélérait davantage SwiftSync.

    James O’Beirne a demandé si SwiftSync est utile étant donné que assumeUTXO offre une accélération encore plus grande. Somsen a répondu que SwiftSync accélère la validation en arrière-plan d’assumeUTXO, ce qui en fait un ajout intéressant pour les utilisateurs d’assumeUTXO. Il note en outre que quiconque télécharge les données requises d’assumeUTXO (la base de données UTXO à un bloc particulier) n’a pas besoin d’un fichier d’indices séparé s’il utilise ce même bloc comme bloc terminal SwiftSync.

    Vojtěch Strnad, 0xB10C, et Somsen ont discuté de la compression des données du fichier d’indices, avec une économie attendue d’environ 75%, réduisant le fichier d’indices de test (pour le bloc 850,900) à environ 88 Mo.

    La discussion était en cours au moment de la rédaction.

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.

Add Fee rate Forecaster Manager est un PR par ismaelsadeeq qui améliore la logique de prévision des frais de transaction (également appelée estimation). Il introduit une nouvelle classe ForecasterManager à laquelle plusieurs Forecasters peuvent être enregistrés. Le CBlockPolicyEstimator existant (qui ne considère que les transactions confirmées) est refactorisé pour devenir un de ces prévisionnistes, mais notablement un nouveau MemPoolForecaster est introduit. MemPoolForecaster considère les transactions non confirmées qui sont dans le mempool, et en tant que tel peut réagir plus rapidement aux changements de taux de frais.

  • Pourquoi le nouveau système est-il appelé un « Forecaster » et « ForecasterManager » plutôt qu’ « Estimator » et « Fee Estimation Manager » ?

    Le système prédit les résultats futurs basés sur les données actuelles et passées. Contrairement à un estimateur, qui approximise les conditions présentes avec une certaine randomisation, un prévisionniste projette des événements futurs, ce qui s’aligne avec la nature prédictive de ce système et sa sortie de niveaux d’incertitude/risque. ➚

  • Pourquoi CBlockPolicyEstimator n’est-il pas modifié pour contenir la référence mempool, comme dans le PR #12966 ? Quelle est l’approche actuelle et pourquoi est-elle meilleure que de conserver une référence à mempool ? (Hint : see PR #28368)

    CBlockPolicyEstimator hérite de CValidationInterface et implémente ses méthodes virtuelles TransactionAddedToMempool, TransactionRemovedFromMempool, et MempoolTransactionsRemovedForBlock. Cela donne à CBlockPolicyEstimator toutes les informations mempool dont il a besoin sans être inutilement couplé au mempool via une référence. ➚

  • Quels sont les compromis entre la nouvelle architecture et une modification directe de CBlockPolicyEstimator ?

    La nouvelle architecture avec une classe FeeRateForecasterManager à laquelle plusieurs Forecaster peuvent être enregistrés est une approche plus modulaire qui permet de meilleurs tests, et applique une meilleure séparation des préoccupations. Elle permet d’intégrer facilement de nouvelles stratégies de prévision par la suite. Cela se fait au prix d’un peu plus de code à maintenir, et d’une confusion potentielle pour les utilisateurs quant à la méthode d’estimation à utiliser. ➚

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.

  • ● Core Lightning 25.02.1 est une version de maintenance pour la version majeure actuelle de ce nœud LN populaire qui inclut plusieurs corrections de bugs.

  • ● Core Lightning 24.11.2 est une version de maintenance pour une version majeure antérieure de ce nœud LN. Elle inclut plusieurs corrections de bugs, certaines étant les mêmes que celles sorties dans la version 25.02.1.

  • ● BTCPay Server 2.1.0 est une version majeure de ce logiciel de traitement de paiements auto-hébergé. Elle inclut des changements importants pour les utilisateurs de certains altcoins, des améliorations pour le RBF et le CPFP pour augmenter les frais, et un meilleur flux pour le multisig lorsque tous les signataires utilisent BTCPay Server.

  • ● Bitcoin Core 29.0rc3 est un candidat à la sortie pour la prochaine version majeure du nœud complet prédominant du réseau. Veuillez consulter le guide de test de la version 29.

  • ● LND 0.19.0-beta.rc2 est un candidat à la sortie pour ce nœud LN populaire. L’une des principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de frais basé sur RBF pour les fermetures coopératives.

Changements de code et de documentation notables

Changements récents dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, BTCPay Server, BDK, [Amélioration de Bitcoin] Propositions (BIPs)]bips repo, Lightning BOLTs,Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

  • ● LDK #2256 et LDK #3709 améliorent les échecs attribuables (voir le Bulletin #224) comme spécifié dans BOLTs #1044 en ajoutant un champ attribution_data optionnel à la structure UpdateFailHTLC et en introduisant la structure AttributionData. Dans ce protocole, chaque nœud de transfert ajoute au message d’échec un drapeau hop_payload, un champ de durée qui enregistre combien de temps le nœud a détenu le HTLC, et des HMAC correspondant à différentes positions supposées dans l’itinéraire. Si un nœud corrompt le message d’échec, le décalage dans la chaîne HMAC aide à identifier la paire de nœuds entre lesquels cela s’est produit.

  • ● LND #9669 rétrograde les canaux taproot simples pour toujours utiliser le flux de fermeture coopérative classique, même si le flux de fermeture coopérative RBF (voir le Bulletin #347) est configuré. Auparavant, un nœud ayant les deux fonctionnalités configurées échouerait à démarrer.

  • ● Rust Bitcoin #4302 ajoute une nouvelle méthode push_relative_lock_time() à l’API du générateur de script, qui prend un paramètre de verrouillage temporel relatif, et rend obsolète push_sequence() qui prend un numéro de séquence brut comme paramètre. Ce changement résout une confusion potentielle où les développeurs pousseraient par erreur un numéro de séquence brut dans les scripts au lieu d’une valeur de verrouillage temporel relatif, qui est ensuite vérifiée contre le numéro de séquence d’une entrée en utilisant CHECKSEQUENCEVERIFY.

Vous en voulez plus?

Pour plus de discussions sur les sujets mentionnés dans ce bulletin, rejoignez-nous pour le récapitulatif hebdomadaire Bitcoin Optech sur Riverside.fm à 15:30 UTC le jeudi (le jour suivant la publication de la newsletter). La discussion est également enregistrée et sera disponible sur notre page de podcasts.