Le bulletin de cette semaine annonce un prochain changement sur la liste de diffusion Bitcoin-Dev et résume brièvement une proposition permettant d’agréger plusieurs HTLC (Hashed Time-Locked Contracts) ensemble. Sont également incluses nos sections habituelles avec le résumé d’une réunion du Bitcoin Core PR Review Club, des annonces de mises à jour et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Hébergement de la liste de diffusion : les administrateurs de la liste de diffusion Bitcoin-Dev ont annoncés que l’organisation hébergeant la liste prévoit de cesser d’héberger toutes les listes de diffusion à partir de la fin de l’année. Les archives des courriels précédents devraient continuer à être hébergées à leurs URL actuelles dans un avenir prévisible. Nous supposons que la fin de la transmission des courriels affecte également la liste de diffusion Lightning-Dev, qui est hébergée par la même organisation.

    Les administrateurs ont sollicité les commentaires de la communauté sur les options, notamment la migration de la liste de diffusion vers Google Groups. Si une telle migration se produit, Optech commencera à l’utiliser comme l’une de nos sources d’informations.

    Nous sommes également conscients que, dans les mois précédant l’annonce, certains développeurs bien établis avaient commencé à expérimenter des discussions sur le forum web DelvingBitcoin. Optech commencera à surveiller ce forum pour les discussions intéressantes ou importantes à partir de maintenant.

  • ● Agrégation HTLC avec des covenants : Johan Torås Halseth a posté sur la liste de diffusion Lightning-Dev une suggestion pour utiliser un covenant afin d’agréger plusieurs HTLC en une seule sortie qui pourrait être dépensée en une seule fois si une partie connaissait toutes les préimages. Si une partie ne connaissait que certaines des préimages, elle pourrait simplement les réclamer, puis le solde restant pourrait être remboursé à l’autre partie. Halseth note que cela serait plus efficace on-chain et pourrait rendre plus difficile la réalisation de certains types d’attaques de blocage de canal.

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.

Les mises à jour de l’estimateur de frais à partir de l’interface de validation/du thread CScheduler est un PR d’Abubakar Sadiq Ismail (ismaelsadeeq) qui modifie la manière dont les données de l’estimateur de frais des transactions sont mises à jour. (L’estimation des frais est utilisée lorsque le propriétaire du nœud lance une transaction.) Il déplace les mises à jour de l’estimateur de frais qui se produisent de manière synchrone lors des mises à jour de la mempool (ajout ou suppression de transactions) pour les faire se produire de manière asynchrone. Bien que cela ajoute une complexité de traitement supplémentaire, cela améliore les performances du chemin critique (comme le montre la discussion suivante).

Lorsqu’un nouveau bloc est trouvé, ses transactions présentes dans la mempool sont supprimées, ainsi que toutes les transactions en conflit avec les transactions du bloc. Étant donné que le traitement et la transmission des blocs sont critiques en termes de performances, cela est bénéfique pour réduire la quantité de travail nécessaire lors du traitement d’un nouveau bloc, tel que la mise à jour de l’estimateur de frais.

  • Pourquoi est-il bénéfique de supprimer la dépendance de CTxMempool à CBlockPolicyEstimator?

    Actuellement, lors de la réception d’un nouveau bloc, son traitement est bloqué pendant que l’estimateur de frais est mis à jour. Cela retarde l’achèvement du traitement du nouveau bloc et retarde également la transmission du bloc aux pairs. En supprimant la dépendance de CTxMempool à CBlockPolicyEstimator, les estimations de frais peuvent être mises à jour de manière asynchrone (dans un thread différent) afin que la validation et la transmission puissent être effectuées plus rapidement. Cela peut également faciliter les tests de CTxMempool. Enfin, cela permet l’utilisation future d’algorithmes d’estimation de frais plus complexes sans affecter les performances de validation et de transmission des blocs. ➚

  • Est-ce que l’estimation des frais est actuellement mise à jour de manière synchrone lorsque des transactions sont ajoutées ou supprimées de la mempool même sans l’arrivée d’un nouveau bloc?

    Oui, mais les performances ne sont pas aussi critiques à ces moments-là que lors de la validation et de la transmission des blocs. ➚

  • Y a-t-il des avantages à ce que CBlockPolicyEstimator soit un membre de CTxMempool et à ce qu’il soit mis à jour de manière synchrone (l’arrangement actuel)? Y a-t-il des inconvénients à le supprimer?

    Le code synchrone est plus simple et plus facile à comprendre. De plus, l’estimateur de frais a une meilleure visibilité sur l’ensemble de la mempool ; un inconvénient est la nécessité d’encapsuler toutes les informations nécessaires à l’estimation des frais dans une nouvelle structure NewMempoolTransactionInfo. Cependant, peu d’informations sont nécessaires pour l’estimateur de frais. ➚

  • Quels sont, selon vous, les avantages et les inconvénients de l’approche adoptée dans ce PR, par rapport à celle adoptée dans le PR 11775 qui divise CValidationInterface?

    Bien qu’il semble agréable de les diviser, ils avaient toujours un backend partagé (pour maintenir les événements bien ordonnés), donc ils n’étaient pas vraiment indépendants les uns des autres. Il ne semble pas y avoir beaucoup d’avantages pratiques à la division. Le PR actuel est plus étroit et vise uniquement à rendre les mises à jour des estimations de frais asynchrones. ➚

  • Dans une sous-classe, pourquoi implémenter une méthode CValidationInterface équivaut à s’abonner à l’événement?

    Toutes les sous-classes de CValidationInterface sont des clients. La sous-classe peut implémenter certaines ou toutes les méthodes CValidationInterface (rappels), par exemple, connecter ou déconnecter un bloc, ou une transaction ajoutée ou supprimée de la mempool. Après avoir été enregistrée (en appelant RegisterSharedValidationInterface()), toute méthode CValidationInterface implémentée sera exécutée à chaque fois que le rappel de la méthode sera déclenché en utilisant CMainSignals. Les rappels sont déclenchés chaque fois que l’événement correspondant se produit. ➚

  • BlockConnected et NewPoWValidBlock sont des rappels différents. Lequel est asynchrone et lequel est synchrone ? Comment pouvez-vous le dire ?

    BlockConnected est asynchrone ; NewPoWValidBlock est synchrone. Les rappels asynchrones mettent en file d’attente un “événement” qui sera exécuté ultérieurement dans le thread CScheduler. ➚

  • Dans l’engagement 4986edb, pourquoi ajoutons-nous un nouveau rappel, MempoolTransactionsRemovedForConnectedBlock, au lieu d’utiliser BlockConnected (qui indique également une transaction supprimée du mempool) ?

    L’estimateur de frais doit savoir quand les transactions sont supprimées du mempool pour n’importe quelle raison, pas seulement lorsqu’un bloc est connecté. De plus, l’estimateur de frais a besoin des frais de base d’une transaction, ce qui n’est pas fourni via BlockConnected (qui fournit un CBlock). Nous pourrions ajouter les frais de base aux entrées de la liste des transactions block.vtx, mais il est indésirable de modifier une structure de données aussi importante et omniprésente juste pour prendre en charge l’estimation des frais. ➚

  • Pourquoi n’utilisons-nous pas un std::vector<CTxMempoolEntry> comme paramètre du rappel MempoolTransactionsRemovedForBlock ? Cela éliminerait la nécessité d’un nouveau type de structure pour contenir les informations par transaction nécessaires à l’estimation des frais.

    L’estimateur de frais n’a pas besoin de tous les champs de CTxMempoolEntry. ➚

  • Comment les frais de base d’une CTransactionRef sont-ils calculé ?

    C’est la somme des valeurs d’entrée moins la somme des valeurs de sortie. Cependant, le rappel ne peut pas accéder aux valeurs d’entrée car elles sont stockées dans les sorties de transaction précédentes (auxquelles le rappel n’a pas accès). C’est pourquoi les frais de base sont inclus dans la structure TransactionInfo. ➚

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.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK,LND, libsecp256k1, Interface Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’Amélioration Bitcoin (BIPs), Lightning BOLTs, et Inquisition Bitcoin.

  • ● Core Lightning #6824 met à jour la mise en œuvre du protocole de financement interactif pour “stocker l’état lors de l’envoi de commitment_signed, et [ajouter] un champ next_funding_txid à channel_reestablish pour demander à notre pair de retransmettre les signatures que nous n’avons pas reçues.” Cela est basé sur une mise à jour de la proposition de financement interactif.

  • ● Core Lightning #6783 déprécie l’option de configuration large-channels, rendant les grands canaux et les montants de paiement importants toujours activés.

  • ● Core Lightning #6780 améliore la prise en charge de l’augmentation des frais des transactions onchain associées aux sorties d’ancrage.

  • ● Core Lightning #6773 permet à la RPC decode de vérifier que le contenu d’un fichier de sauvegarde est valide et contient les dernières informations nécessaires pour effectuer une récupération complète.

  • ● Core Lightning #6734 met à jour la RPC listfunds pour fournir aux utilisateurs les informations nécessaires s’ils souhaitent augmenter les frais CPFP d’une transaction de fermeture mutuelle de canal.

  • ● Eclair #2761 permet de transférer un nombre limité de HTLC à une partie même s’ils sont inférieurs à leur réserve de canal requise. Cela peut aider à résoudre un problème de fonds bloqués qui pourrait survenir après un splicing ou un financement double. Voir le Bulletin #253 pour une autre atténuation par Eclair pour un problème de fonds bloqués.