La newsletter de cette semaine examine une proposition de BIP pour inclure des informations supplémentaires avec les descripteurs de script de sortie. Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Brouillon de BIP pour les annotations de descripteur de script de sortie : Craig Raw a posté sur la liste de diffusion Bitcoin-Dev à propos d’une nouvelle idée de BIP pour répondre aux retours qui ont émergé lors de la discussion autour du BIP392 (voir le Bulletin #387). Selon Raw, les métadonnées, telles que l’anniversaire du portefeuille exprimé en hauteur de bloc, pourraient rendre le balayage des paiements silencieux plus efficace. Cependant, les métadonnées ne sont pas techniquement nécessaires pour déterminer les scripts de sortie, donc elles sont jugées inappropriées pour inclusion dans un descripteur.

    Le BIP de Raw propose de fournir des métadonnées utiles sous forme d’annotations, exprimées en paires clé/valeur, ajoutées directement à la chaîne de descripteur en utilisant des délimiteurs de requête similaires à ceux d’une URL. Un descripteur annoté ressemblerait à ceci : SCRIPT?key=value&key=value#CHECKSUM. Notamment, les caractères ?, &, et = sont déjà définis dans le BIP380, donc l’algorithme de checksum n’aurait pas besoin d’être mis à jour.

    Dans le brouillon de BIP, Raw définit également trois clés d’annotation initiales spécifiquement pour rendre le balayage des fonds pour paiements silencieux plus efficace :

    • Hauteur de Bloc bh : La hauteur de bloc à laquelle un portefeuille a reçu les premiers fonds ;

    • Limite de Gap gl : Le nombre d’adresses inutilisées à dériver avant d’arrêter ;

    • Étiquette Max ml : L’indice d’étiquette maximum à scanner pour les portefeuilles de paiements silencieux.

    Enfin, Raw a noté que les annotations ne devraient pas être utilisées dans le processus général de sauvegarde de portefeuille, mais uniquement pour rendre la récupération de fonds plus efficace sans altérer les scripts produits par le descripteur.

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou quand nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées postées depuis notre dernière mise à jour.

  • ● Le transport P2P v2 de Bitcoin BIP324 est-il distinguable du trafic aléatoire ? Pieter Wuille souligne que le protocole de transport chiffré v2 de BIP324 prend en charge la formation de modèles de trafic, bien qu’aucun logiciel connu n’implémente cette fonctionnalité, concluant que “les implémentations actuelles ne déjouent que les signatures de protocole qui impliquent des modèles dans les octets envoyés, pas dans le trafic”.

  • ● Que se passe-t-il si un mineur diffuse simplement l’en-tête et ne donne jamais le bloc ? L’utilisateur bigjosh décrit comment un mineur pourrait se comporter après avoir reçu un en-tête de bloc sur le réseau P2P mais avant de recevoir le contenu du bloc : en minant un bloc vide par-dessus. Pieter Wuille précise qu’en pratique, de nombreux mineurs voient effectivement les nouveaux en-têtes de blocs en surveillant le travail que d’autres pools de minage distribuent à leurs mineurs, une technique connue sous le nom de spy mining.

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.

  • ● Bitcoin Core 28.4rc1 est un candidat à la version pour une maintenance de la série de versions majeures précédente. Il contient principalement des corrections de migration de portefeuille et la suppression d’un DNS seed peu fiable.

  • ● Rust Bitcoin 0.33.0-beta est une version beta de cette bibliothèque pour travailler avec les structures de données Bitcoin. C’est une mise à jour importante avec plus de 300 commits qui introduit une nouvelle crate bitcoin-consensus-encoding, ajoute des traits d’encodage de messages du réseau P2P, rejette les transactions avec des entrées dupliquées ou des sommes de sortie dépassant MAX_MONEY lors du décodage, et augmente les versions majeures de toutes les sous-crates.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #34568 apporte plusieurs changements majeurs à l’interface IPC de minage (voir le Bulletin #310). Les méthodes obsolètes getCoinbaseRawTx(), getCoinbaseCommitment() et getWitnessCommitmentIndex() (voir le Bulletin #388) sont supprimées, des paramètres context sont ajoutés à createNewBlock et checkBlock pour qu’ils puissent s’exécuter sur des threads séparés sans bloquer la boucle d’événements Cap’n Proto, et les valeurs d’option par défaut sont déclarées dans le schéma. Le numéro de version de Init.makeMining est augmenté pour que les clients plus anciens reçoivent une erreur claire au lieu d’interpréter silencieusement le nouveau schéma. Le changement de threading est une condition préalable pour la fonction de cooldown couverte ensuite.

  • ● Bitcoin Core #34184 ajoute un cooldown optionnel à la méthode createNewBlock() sur l’interface IPC de minage. Lorsqu’activé, la méthode attend toujours que le Téléchargement Initial du Bloc (IBD) soit complet et que le sommet soit rattrapé avant de retourner un modèle de bloc. Cela empêche les clients Stratum v2 d’être inondés de modèles rapidement obsolètes pendant le démarrage. Une nouvelle méthode interrupt() est également ajoutée pour que les clients IPC puissent interrompre proprement un appel bloquant à createNewBlock() ou waitTipChanged().

  • ● Bitcoin Core #24539 ajoute une nouvelle option -txospenderindex qui maintient un index de quelle transaction a dépensé chaque sortie confirmée. Lorsqu’activé, le RPC gettxspendingprevout est étendu pour retourner le spendingtxid et le blockhash pour les transactions confirmées, en plus de ses recherches existantes dans le mempool. Deux nouveaux arguments optionnels sont également ajoutés au RPC : mempool_only limite les recherches au mempool même lorsque l’index est disponible, et return_spending_tx retourne la transaction de dépense complète. L’index ne nécessite pas -txindex et est incompatible avec le pruning. Ceci est particulièrement utile pour Lightning et d’autres protocoles de seconde couche qui ont besoin de suivre des chaînes de transactions de dépense.

  • ● Bitcoin Core #34329 ajoute deux nouveaux RPCs pour gérer les diffusions de transactions privées (voir le Bulletin #388): getprivatebroadcastinfo retourne des informations sur les transactions actuellement dans la file d’attente de diffusion privée, y compris les adresses des pairs choisis et le moment où chaque diffusion a été envoyée, et abortprivatebroadcast annule la diffusion d’une transaction spécifique et ses connexions en attente.

  • ● Bitcoin Core #28792 complète la série de PRs ASMap intégrée en regroupant les données ASMap directement dans le binaire de Bitcoin Core, de sorte que les utilisateurs qui activent -asmap n’ont plus besoin d’obtenir séparément un fichier de données. La suppression de l’option de build WITH_EMBEDDED_ASMAP permet d’exclure les données. ASMap améliore la résistance aux attaques par éclipse en diversifiant les connexions entre pairs à travers les systèmes autonomes (voir les Bulletins #52 et #290). La fonctionnalité reste désactivée par défaut ; l’utilisateur doit toujours spécifier -asmap pour l’activer. Un nouveau fichier de documentation décrit le processus pour obtenir les données et les inclure dans une version de Bitcoin Core.

  • ● Bitcoin Core #32138 supprime le RPC settxfee et l’option de démarrage -paytxfee, qui permettaient aux utilisateurs de définir un taux de frais statique pour toutes les transactions. Les deux ont été dépréciés dans Bitcoin Core 30.0 (voir le Bulletin #349). Les utilisateurs devraient plutôt se fier à l’estimation des frais ou définir un taux de frais par transaction.

  • ● Bitcoin Core #34512 ajoute un champ coinbase_tx à la réponse du RPC getblock au niveau de verbosité 1 et au-dessus, contenant les données version, locktime, sequence, coinbase script, et witness de la transaction coinbase. Les sorties sont intentionnellement exclues pour garder la réponse compacte. Auparavant, l’accès aux propriétés coinbase nécessitait la verbosité 2, qui décode chaque transaction dans le bloc. Ceci est utile pour surveiller les exigences de locktime coinbase de BIP54 (nettoyage du consensus) ou identifier les pools de minage à partir du script coinbase.

  • ● Core Lightning #8490 ajoute une nouvelle option de configuration payment-fronting-node qui spécifie un ou plusieurs nœuds à utiliser toujours comme points d’entrée pour les paiements entrants. Lorsqu’elle est définie, les indices de route dans les factures BOLT11 et les points d’introduction de chemin masqué dans les offres BOLT12, factures et demandes de facture sont construits pour utiliser uniquement les nœuds de façade spécifiés. Auparavant, CLN sélectionnait automatiquement parmi les pairs de canaux du nœud, exposant potentiellement différents pairs à travers les factures. L’option peut être définie globalement ou remplacée par offre.

  • ● Eclair #3250 permet à OpenChannelInterceptor de sélectionner automatiquement un channel_type lorsque le nœud local ouvre un canal sans en avoir explicitement défini un. Auparavant, la création automatique de canal (par exemple, par un LSP ouvrant des canaux vers des clients) échouait à moins qu’un type ne soit fourni. Le choix par défaut actuel préfère les canaux ancrés, avec les canaux taproot simples qui devraient être privilégiés dans les PRs suivants.

  • ● LDK #4373 ajoute le support pour l’envoi de paiements multipath où le nœud local paie seulement une portion du montant total de la facture. Un nouveau champ total_mpp_amount_msat dans RecipientOnionFields permet de déclarer un total MPP plus grand que ce que ce nœud envoie, permettant à plusieurs portefeuilles ou nœuds de payer collaborativement une seule facture en contribuant chacun une partie du paiement. Le receveur collecte les HTLCs de tous les nœuds contributeurs et réclame le paiement une fois le montant total arrivé. Le support de BOLT12 est laissé pour un suivi.

  • ● BDK #2081 ajoute les méthodes spent_txouts() et created_txouts() à SpkTxOutIndex et KeychainTxOutIndex qui, étant donné une transaction, retournent quels outputs suivis elle a dépensés et quels nouveaux outputs suivis elle a créés. Cela permet aux portefeuilles de déterminer facilement les adresses et les montants impliqués dans les transactions qui les concernent.