Le bulletin de cette semaine résume un article qui évoque la possibilité pour les nœuds complets d’ignorer les transactions qui sont relayées sans avoir été demandées au préalable. Sont également incluses nos sections régulières avec les questions et réponses populaires du Bitcoin Stack Exchange, les annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

• ● Ignorer les transactions non sollicitées : Antoine Riard a posté sur Bitcoin-Dev deux BIPs provisoires qui permettraient à un nœud de signaler qu’il n’acceptera plus les messages tx qu’il n’a pas demandés au préalable avec un message inv, appelées transactions non sollicitées. Riard avait précédemment proposé l’idée générale en 2021 (voir le Bulletin #136). Le premier BIP proposé ajoute un mécanisme permettant aux nœuds de signaler leurs capacités et préférences de relais de transactions ; le deuxième BIP proposé utilise ce mécanisme de signalisation pour indiquer que le nœud ignorera les transactions non sollicitées.

  Cette proposition présente plusieurs avantages mineurs, comme discuté dans une PR Bitcoin Core, mais elle entre en conflit avec la conception de certains clients légers plus anciens et pourrait empêcher les utilisateurs de ce logiciel de pouvoir diffuser leurs transactions, donc un déploiement soigneux pourrait être nécessaire. Bien que Riard ait ouvert la PR susmentionnée, il l’a fermée ensuite après avoir indiqué qu’il prévoyait de travailler sur sa propre implémentation de nœud complet basée sur libbitcoinkernel. Il a également indiqué que la proposition pourrait aider à adresser certaines attaques qu’il a récemment divulguées (voir le Bulletin #332).

Questions et réponses sélectionnées du 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 publiées depuis notre dernière mise à jour.

• ● Quelle est la raison d’être de la configuration du RPC loadtxsoutset ? Pieter Wuille explique pourquoi la valeur de assumeUTXO pour représenter l’ensemble UTXO est codée en dur à une hauteur de bloc particulière, les moyens de distribuer les instantanés assumeUTXO à l’avenir, et les avantages de assumeUTXO par rapport à la simple copie des magasins de données internes de Bitcoin Core.

• ● Y a-t-il des classes d’attaques de pinning que la règle RBF #3 rend impossibles ? Murch souligne que la règle RBF #3 n’est pas destinée à prévenir les attaques de pinning et aborde la politique de remplacement de Bitcoin Core.

• ● Valeurs de locktime inattendues L’utilisateur polespinasa liste les différentes raisons pour lesquelles Bitcoin Core définit des valeurs de nLockTime spécifiques : à block_height pour éviter le fee sniping, une valeur aléatoire inférieure à la hauteur du bloc 10% du temps pour la confidentialité, ou 0 si la blockchain n’est pas à jour.

• ● Pourquoi est-il nécessaire de révéler un bit dans un script path spend et de vérifier qu’il correspond à la parité de la coordonnée Y de Q ? Pieter Wuille explique la rationale de BIP341 pour maintenir la vérification de la parité de la coordonnée Y pendant les dépenses de script path taproot afin de permettre l’ajout potentiel futur de la fonctionnalité de validation en lot.

• ● Pourquoi Bitcoin Core utilise-t-il des points de contrôle et non le bloc assumevalid ? Pieter Wuille détaille une histoire des points de contrôle dans Bitcoin Core et à quel but ils ont servi, et pointe vers une PR ouverte et une discussion sur la suppression des points de contrôle.

• ● Comment Bitcoin Core gère-t-il les longs reorgs ? Pieter Wuille décrit comment Bitcoin Core gère les réorganisations de la blockchain, en faisant remarquer qu’une différence dans les réorganisations plus importants est que “le retour de transactions au pool de mémoire n’est pas effectué”.

• ● Quelle est la définition de discard feerate ? Murch définit le discard feerate comme le feerate maximum pour jeter le changement et résume le code pour calculer le discard feerate comme “le feerate cible de 1000 blocs recadré à 3–10 ṩ/vB s’il sort de cette plage”.

• ● Politique au compilateur miniscript Brunoerg note que le portefeuille Liana utilise le langage de politique et pointe vers les bibliothèques sipa/miniscript et rust-miniscript comme exemples de compilateurs de politique.

Mises à jour et versions candidates

Nouvelles mises-à-jours et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles mises-à-jour ou d’aider à tester les versions candidates.

• ● Core Lightning 25.02rc3 est un candidat à la sortie pour la prochaine version majeure de ce nœud LN populaire.

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 #8116 change le traitement des négociations de fermeture de canal interrompues pour réessayer le processus même s’il n’est pas nécessaire. Cela corrige un problème où un nœud manquant le message CLOSING_SIGNED de son pair obtient une erreur lors de la reconnexion et diffuse une transaction de fermeture unilatérale. Pendant ce temps, le pair, déjà dans l’état CLOSINGD_COMPLETE, a diffusé la transaction de clôture mutuelle, ce qui pourrait entraîner une course entre les deux transactions. Cette correction permet de continuer la renégociation jusqu’à ce que la transaction de clôture mutuelle soit confirmée.

• ● Core Lightning #8095 ajoute un drapeau transient à la commande setconfig (voir le Bulletin #257), introduisant des variables de configuration dynamiques qui sont appliquées temporairement sans modifier le fichier de configuration. Ces modifications sont réinitialisés au redémarrage.

• ● Core Lightning #7772 ajoute un crochet commitment_revocation au plugin chanbackup qui met à jour le fichier emergency.recover (voir le Bulletin #324) chaque fois qu’un ouveau secret de révocation est reçu. Cela permet aux utilisateurs de diffuser une transaction de pénalité lors du balayage des fonds en utilisant emergency.recover si le pair a publié un état révoqué obsolète. Cette PR étend le format SCB static channel backup et met à jour le plugin chanbackup pour sérialiser à la fois les nouveaux formats et les formats hérités.

• ● Core Lightning #8094 introduit une variable xpay-slow-mode configurable à l’exécution pour le plugin xpay (voir le Bulletin #330), qui retarde le retour de succès ou d’échec jusqu’à ce que toutes les parties d’un paiement multipath payments (MPP) soient résolues. Sans ce paramètre, un statut d’échec pourrait être renvoyé même si certains HTLCs sont encore en attente. Si un utilisateur réessaie et paie avec succès la facture depuis un autre nœud, un surpaiement pourrait se produire si le HTLC en attente est également réglé.

• ● Eclair #2993 permet au destinataire de payer les frais associés à la partie aveuglée d’un chemin de paiement, tandis que l’expéditeur couvre les frais pour la partie non aveuglée. Auparavant, l’expéditeur payait tous les frais, ce qui pourrait lui permettre d’inférer et potentiellement de dévoiler le chemin.

• ● LND #9491 ajoute la prise en charge des fermetures de canaux coopératives lorsqu’il y a des HTLCs actifs en utilisant la commande lncli closechannel. Lorsqu’initiée, LND arrêtera le canal pour empêcher la création de nouveaux HTLCs et attendra que tous les HTLCs existants soient résolus avant de commencer le processus de négociation. Les utilisateurs doivent définir le paramètre no_wait pour activer ce comportement ; sinon, un message d’erreur les invitera à le spécifier. Cette PR assure également que le paramètre max_fee_rate est appliqué pour les deux parties lorsqu’une fermeture de canal coopérative est initiée ; auparavant, il était uniquement appliqué à la partie distante.