en | ja | es | cs | hi | zh | de | fr | pt

Bulletin Hebdomadaire Bitcoin Optech #417

Aug 7, 2026

Le bulletin de cette semaine décrit une ébauche de BIP pour relayer les pointes de blocs périmées entre pairs. Sont également incluses nos sections régulières résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin, annonçant de nouvelles versions et versions candidates, et décrivant des changements notables dans des logiciels d’infrastructure Bitcoin populaires.

Nouvelles

● Ébauche de BIP pour le relais des pointes périmées : Ram et w0xlt ont publié sur la liste de diffusion Bitcoin-Dev à propos de la proposition d’un message P2P optionnel pour relayer les pointes périmées entre pairs. Actuellement, le taux de blocs périmés est une métrique difficile à surveiller, puisque les blocs périmés cessent de se propager dès que la chaîne gagnante est relayée. Cependant, c’est un signal utile pour vérifier l’état de santé du réseau. Des changements dans le taux de blocs périmés peuvent révéler des goulots d’étranglement de validation ou de relais, des partitions réseau, ou un comportement de minage égoïste.

Le BIP proposé définit un nouveau message, appelé staletip, pour annoncer aux pairs les pointes récentes de chaînes périmées. Le message lui-même contient la hauteur de bloc à laquelle une branche périmée diverge (le point de bifurcation), un vecteur contenant les en-têtes de blocs appartenant à la branche périmée, et un drapeau signalant la volonté de servir les données de ces blocs. Un nœud ne devrait envoyer ce message qu’après la négociation BIP434 avec ses pairs (voir le Bulletin #386).

Les auteurs attendent les retours d’autres développeurs. En attendant, une preuve de concept pour la proposition est déjà disponible.

Modification du consensus

Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin.

● CISA pour les dépenses keypath taproot (BIP460) : Fabian Jahr a publié sur la liste de diffusion Bitcoin-Dev une ébauche de BIP460 (BIPs #2212) pour l’agrégation de signatures inter-entrées (CISA) à l’échelle de la transaction pour les dépenses keypath de style taproot. La proposition introduit une nouvelle version de témoin (v2) dont les dépenses keypath reproduisent BIP341 sauf que le témoin de chaque entrée commence par un octet marqueur sélectionnant une demi-agrégation (BIP458/BIPs #2205), une agrégation complète (BIP459/BIPs #2210), ou un refus explicite transportant une signature schnorr standard BIP340. La demi-agrégation compresse de manière non interactive de nombreuses signatures de 64 octets à 32 octets chacune plus une unique partie agrégée de 32 octets (voir le Bulletin #208) ; l’agrégation complète les réduit à une seule signature agrégée de 64 octets avec une signature interactive (voir le Bulletin #415). Les dépenses scriptpath suivent BIP341/BIP342 sans changement et ne sont pas agrégées, préservant le chemin de mise à niveau OP_SUCCESS. Les signatures dans le schéma proposé s’engagent sur le mode d’agrégation, de sorte que l’agrégation est optionnelle : des tiers ne peuvent pas intégrer une signature ayant refusé dans un groupe de demi-agrégation. Jahr note que la version de témoin entre en conflit avec BIP360 (P2MR) ; des examinateurs (y compris Mark Erhardt) s’attendent à ce que la proposition qui s’active en premier prenne la prochaine version libre.

Conduition a demandé comment CISA s’articule avec la migration post-quantique : l’agrégation nécessite des clés publiques EC nues pour la vérification, donc associer CISA avec P2TRv2 maximise les économies de frais (aussi peu que 1 octet de témoin par entrée entièrement agrégée) mais hérite du problème de calendrier de désactivation de l’EC de P2TRv2, tandis que hacher la clé (P2MR ou P2TRH) coûte approximativement 32 à 65 unités de poids par entrée et réduit les économies. Jahr a répondu que le cadre marqueur/groupe au niveau de la transaction devrait se généraliser à de futurs schémas agrégeables et qu’une variante de CISA avec hachage masquant la clé pourrait être spécifiée comme un type de sortie séparé partageant l’essentiel de la logique. Adam Gibson (waxwing) a remis en question la limite d’un seul groupe par schéma lorsque plusieurs utilisateurs souhaitent chacun une agrégation complète de seulement leurs propres entrées au sein d’une transaction partagée. Jahr a répondu que plusieurs groupes restent envisageables si les examinateurs voient des cas d’usage concrets.
● Engagement segwit vers des données de témoin post-quantiques : Pieter Wuille a publié sur Delving Bitcoin une conception permettant d’attacher des données de témoin post-quantiques sans répéter tous les coûts de déploiement de segwit. Une seconde zone de témoin naïve nécessiterait un nouvel identifiant de transaction (pqwtxid), un engagement coinbase vers ces identifiants, des changements de la pile de minage, et une logique P2P suivant trois identifiants. L’alternative de Wuille engage les données de témoin étendues de chaque entrée depuis le témoin actuel de l’entrée, de sorte que le wtxid couvre les données supplémentaires. Une version détaillée introduit des « styles » de témoin par entrée (0 = segwit, 1 = pqdata, 2+ pour de futures extensions), chacun avec sa propre extension P2P et sa propre fonction de poids. Les styles non pris en charge peuvent être représentés par un engagement valide de style 0 pour la compatibilité avec les nœuds non mis à niveau. Anthony Towns a comparé les styles à des formules distinctes de poids d’autorisation, a suggéré des engagements fondés sur l’annexe afin que des assertions de type locktime restent disponibles sans les données supplémentaires, et a soutenu que la capacité réservée aux signatures post-quantiques devrait rester inutilisable pour des données ordinaires afin que les blocs d’avant le Q-day ne gonflent pas vers une cible plus grande. Wuille a convenu qu’introduire un style reste encore une mise à niveau combinée de soft fork, de stockage et de P2P, mais sans nouvel identifiant de transaction.
● Discussion sur les types de sortie PQC : Pieter Wuille a ouvert un fil Delving Bitcoin pour centraliser la discussion sur les types de sortie post-quantiques. Il a dressé un tableau des candidats, dont BIP360 (P2MR), P2TRv2, P2TRH (semblable à taproot avec une clé de sortie hachée et récupération de clé publique, voir le Bulletin #412), et P2QR (P2MR avec les opcodes EC désactivés dès le départ), ainsi que des variations de ceux-ci. Sa préférence actuelle est de déployer à la fois P2TRv2 (avec tripwire/verrouillage des mineurs et un opcode PQC fondé sur le hachage) pour une migration facile avant le Q-day qui conserve le profil de frais actuel, et un type à plus long terme fondé sur P2MR avec un nouveau style de témoin afin que les coûts EC et PQC puissent être tarifés indépendamment après la migration. Des mesures sur regtest par jeanpablojp ont montré que les dépenses BIP360 nécessitent ~96 lignes de delta de consensus par rapport à la machinerie taproot existante, avec une feuille schnorr de profondeur 1 environ 32 octets plus légère que le scriptpath P2TR équivalent. Conduition a noté que la proposition CISA de Jahr (ci-dessus) rend P2TRv2+CISA extrêmement attractif pour une migration volontaire, mais augmente les enjeux d’un soft fork ultérieur désactivant l’EC, et a indiqué que l’agrégation PQ-SNARK à l’échelle du bloc de signatures fondées sur le hachage constitue une piste de recherche qui pourrait rendre les dépenses post-quantiques compétitives en frais.
● Expiration de transaction déclenchée par entrée : Josh Doman a publié sur Delving Bitcoin une construction pour faire expirer les HTLC sans relais gratuit, puis l’a généralisée dans un suivi sur l’expiration de transaction déclenchée par entrée. Les propositions d’expiration absolue telles que OP_EXPIRE de Peter Todd rendent invalide plus tard une transaction valide, permettant un spam de relais bon marché à moins que la politique n’exige des frais proches du prochain bloc. L’approche de Doman fait au contraire expirer une dépense lorsque la transaction créant l’UTXO qu’elle dépense a été confirmée trop tard : si le nSequence de BIP68 impose un verrou temporel relatif fondé sur la hauteur R et que le bit 21 est positionné, l’entrée échoue à la validation à moins que nLockTime ne soit fondé sur la hauteur et au moins égal à la hauteur minimale d’inclusion BIP68. Comme un parent miné ne peut pas devenir invalide sans réorganisation profonde, un enfant valide une fois ne peut pas expirer dans des conditions normales de progression, ce qui élimine le relais gratuit. Les cas d’usage comprennent le transfert HTLC sans mempool (surveillance du préimage via le chainstate plutôt que le mempool local, utile pour les nœuds à faible bande passante ou de type Utreexo) et des timelocks relatifs pseudo contractuels pour LN-Symmetry. Des modifications complémentaires facultatives imposent le bit 21 dans OP_CSV et ajoutent un opcode d’introspection tapscript OP_LOCKTIME afin que les scripts puissent exiger un locktime maximal. Anthony Towns a comparé l’idée à l’introspection de hauteur de pièce via OP_TX et a mis en doute la nécessité du délai minimal de 100 blocs (choisi pour correspondre à la maturité des coinbase et à la proposition de Todd) ; Doman a ensuite convenu qu’un délai bien plus faible pourrait suffire et a reformulé la primitive comme une manière pour les utilisateurs d’affirmer « maintenant » (confirmations d’entrée par nLockTime) qui peut également accroître le coût des réorganisations profondes après la subvention.
● Récupération quantique en couches des adresses hachées : Shinobi a publié sur la liste de diffusion Bitcoin-Dev et a cross-posté sur Delving Bitcoin un plan de récupération en couches pour les pièces sécurisées par des types d’adresses hachées (P2PKH, P2SH, P2WPKH, P2WSH, et constructions analogues) si les dépenses secp256k1 étaient plus tard restreintes en raison de l’existence d’un ordinateur quantique cryptographiquement pertinent. Aucun mécanisme de récupération unique ne couvre toutes les méthodes de génération de clés : les preuves hiérarchiques BIP32 (récemment démontrées par Osuntokun) manquent les clés non hiérarchiques ; les attestations horodatées avec état avant l’échéance ne couvrent pas les utilisateurs inactifs ; et la migration commit-reveal échoue lorsque les clés publiques sont déjà exposées. Permettre à n’importe quelle méthode de récupération d’autoriser une dépense après la désactivation de secp256k1 couvrirait, sous l’hypothèse que les clés publiques et les scriptpaths internes restent secrets, essentiellement tous les détenteurs d’adresses hachées qui contrôlent encore leurs clés. Pour faciliter cela à l’avenir, Shinobi suggère que les portefeuilles utilisent de nouveaux chemins de dérivation et des requêtes de solde par adresse de style Electrum afin d’éviter de divulguer des xpub aux fournisseurs de services. Conduition a reformulé la récupération comme l’authentification d’asymétries de connaissance existantes dont un attaquant quantique ne dispose pas : les scripts hachés et les seeds BIP32 sont de telles asymétries. Il a souligné que certains UTXOs (notamment de nombreuses premières pièces P2PK) n’ont pas une telle asymétrie, de sorte qu’une action avant l’échéance pour en créer une est le seul moyen de distinguer leurs propriétaires d’un attaquant. Il a également noté que les clés internes taproot peuvent servir d’asymétrie de connaissance pour la récupération keypath P2TR, séparément de la superposition des adresses hachées.
● Ébauche de BIP Segregated Data (SegData) : MrHash a publié sur Delving Bitcoin des ébauches de BIP complémentaires pour Segregated Data, un soft fork qui ajouterait une région de bloc élagable et isolée des scripts pour transporter des données arbitraires. Les entrées seraient engagées via une racine de merkle coinbase (de style BIP141) , comptées avec la remise witness, et liées aux transactions par des sorties de référence witness v2 non dépensables de valeur zéro exclues de l’ensemble UTXO. Aucun opcode ne peut lire le contenu des entrées, ce qui les maintient élagables et incapables de conditionner des dépenses, et au-delà d’une fenêtre de rétention les nœuds pourraient valider à partir de la seule sérialisation de base. L’objectif est de donner aux données que les scripts n’ont pas besoin d’évaluer (blobs d’application, attestations) un foyer structurel afin qu’elles quittent OP_RETURN et le bourrage de witness, sans modifier ces vecteurs existants. Antoine Poinsot et Pieter Wuille ont soutenu que si les nœuds complets n’ont pas besoin de conserver la charge utile pour accepter un bloc, alors les données ne font pas partie du consensus de Bitcoin dans un sens significatif et reviennent à payer des frais pour gonfler le poids. Mark Erhardt a demandé pourquoi les intégrateurs préféreraient une disponibilité réduite au même coût que des données witness. Après qu’Anthony Towns a décrit les risques de réorganisation issus de règles de présence dépendantes de la profondeur, MrHash s’est réorienté vers une vérification de consensus du seul poids/longueur engagé, avec validation de la charge utile en tant que politique. L’ébauche reste ouverte ; l’allocation de version witness entre aussi en conflit avec les discussions BIP360 et BIP460 ci-dessus.

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.

● Libsecp256k1 0.8.0 est une version de cette bibliothèque pour les opérations cryptographiques liées à Bitcoin. Elle ajoute le module silent payments BIP352 décrit dans le Bulletin #415, permet aux applications de fournir des implémentations de compression SHA256 optimisées matériellement comme décrit dans le Bulletin #396, et améliore l’arithmétique de champ 64 bits, produisant des accélérations de vérification de signatures allant jusqu’à environ 11 % dans certaines compilations GCC et MSVC. Elle retire également les symboles obsolètes secp256k1_schnorrsig_sign et secp256k1_context_no_precomp.

Changements notables dans le code et la documentation

Changements récents notables 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 #35501 met à jour le portefeuille afin de stocker plusieurs variantes witness de la même transaction. Auparavant, une fois que le portefeuille connaissait une transaction avec un txid donné, il ignorait généralement une autre transaction avec le même txid mais un wtxid différent. Désormais, le portefeuille stocke chaque variante dans un enregistrement de base de données wtxvariant distinct et en sélectionne une comme canonique. La préférence est donnée à une variante confirmée, sinon à une variante contenant des données witness puis à une variante avec le poids le plus faible. La variante canonique reste dans l’enregistrement tx existant. Les RPC gettransaction, listtransactions, et listsinceblock signalent désormais les variantes non canoniques dans un nouveau champ alternate_wtxids. Voir les Bulletins #193 et #304 pour des références précédentes aux transactions ayant le même txid mais des wtxid différents.
● Core Lightning #9298 fait progresser la migration vers bwatch, un plugin expérimental de surveillance de blockchain destiné à déplacer l’interrogation des blocs et le filtrage des transactions hors de lightningd. Cette PR déplace le suivi des transactions du portefeuille et des UTXO vers ce système en ajoutant les tables our_outputs et our_txs, en les remplissant à partir des tables existantes du portefeuille, et en basculant les lectures du portefeuille vers les nouvelles tables. Avec --experimental-bwatch activé, les surveillances de scriptPubKey détectent quand des fonds sont reçus et les surveillances d’outpoint détectent quand des sorties du portefeuille sont dépensées, y compris la gestion des réorganisations. Les écritures sont temporairement dupliquées dans les tables historiques outputs et transactions pour permettre aux utilisateurs de rétrograder sans avoir besoin de rescanner.
● Core Lightning #9353 fait en sorte que sendpay renvoie une erreur RPC lorsque la charge utile combinée par saut pour une route fournie ne peut pas tenir dans le champ hop_payloads de 1 300 octets d’un paquet onion défini par BOLT4. Auparavant, la construction de l’onion renvoyait un résultat nul que sendpay transmettait sans vérification au code d’envoi, provoquant un plantage de lightningd. Ce problème a été observé avec une route de 25 sauts générée par un plugin de rééquilibrage. Cependant, la limite réelle de route dépend de la taille des charges utiles encodées pour chaque saut plutôt que du seul nombre de sauts.
● Eclair #3336 empêche que des messages de règlement HTLC en double reçus d’un pair soient ajoutés plusieurs fois aux changements de commitment distant proposés. Auparavant, un pair ou une file locale de messages pouvait livrer plus d’une fois le même message update_fulfill_htlc, update_fail_htlc, ou update_fail_malformed_htlc, amenant Eclair à stocker des changements de commitment en double et potentiellement à forcer la fermeture du canal lorsque les pairs échangeaient ensuite des messages commit_sig.
● LND #10942 ajoute la prise en charge du transfert d’un HTLC sur un chemin de paiement aveuglé lorsque les données chiffrées du destinataire identifient le saut suivant en utilisant next_node_id plutôt que short_channel_id (SCID). Ce problème a été observé dans un paiement BOLT12 de Core Lightning, où LND était le nœud d’introduction dans le chemin aveuglé du destinataire. CLN utilisait la forme next_node_id permise par BOLT4, mais le code de transfert HTLC de LND exigeait un SCID, ce qui faisait échouer le paiement. LND résout désormais l’identifiant de nœud vers l’un de ses canaux utilisables avec ce pair en utilisant sa logique existante de transfert non strict, qui prend également en charge les canaux privés et alias.
● LND #10992 borne la mémoire utilisée lors de la synchronisation des annonces de canaux en limitant le nombre de short channel IDs (SCIDs) acceptés dans la réponse reply_channel_range de BOLT7 à une requête query_channel_range. Auparavant, des réponses compressées pouvaient amener LND à décoder et mettre en mémoire tampon un nombre imprévisible de SCIDs à travers un ou plusieurs messages reply_channel_range. Désormais, LND accepte un maximum de 100 000 SCIDs par message et 100 000 SCIDs au total pour une seule requête.
● Rust Bitcoin #6364 ajoute la prise en charge de l’encodage et du décodage P2P pour les messages feature de BIP434 (voir les Bulletins #386 et #390), à la suite de l’implémentation antérieure de Bitcoin Core (voir le Bulletin #410). Il ajoute la version de protocole 70017, la variante feature de NetworkMessage, tout en appliquant les limites de taille de BIP434 sur les identifiants de fonctionnalité et les données. Cette mise à jour fournit l’infrastructure de messages, mais n’implémente pas la logique de négociation des fonctionnalités entre pairs.
● Rust Bitcoin #6642 applique une limite de taille de 4 Mo à chaque élément witness de transaction. Cette limite est dérivée de la limite de bloc de quatre millions d’unités de poids de BIP141, puisqu’un élément witness plus grand que cette taille ne tiendrait pas dans un bloc valide. Auparavant, lors du décodage d’une transaction, Rust Bitcoin n’appliquait cette limite qu’au premier élément witness, réinitialisant ensuite à une limite par défaut plus grande de 32 Mio pour les éléments suivants. Cela pouvait permettre qu’un élément surdimensionné soit accepté lors du décodage, laissant le witness dans un état incohérent susceptible de provoquer une panic lorsqu’il était plus tard interprété comme une dépense taproot. Cela suit le durcissement antérieur de l’allocation mémoire du décodage witness décrit dans le Bulletin #410.
● BTCPay Server #7491 corrige un contournement de l’authentification à deux facteurs (2FA) dans le gestionnaire d’authentification de l’API Greenfield. Bien que le gestionnaire d’authentification vérifiait la 2FA FIDO2 (voir le Bulletin #146), il ne vérifiait pas la 2FA par mot de passe à usage unique basé sur le temps (TOTP). Cela permettait à des comptes protégés par TOTP d’accéder à l’API sans fournir leur 2FA. Le gestionnaire rejette désormais cette forme d’authentification dès qu’un second facteur est activé.
● BTCPay Server #7488 améliore la compatibilité de signature PSBT en ajoutant witness_utxo aux entrées segwit lorsque le PSBT contient déjà la transaction précédente correspondante dans non_witness_utxo. Cela résout un problème avec des dispositifs de signature tels que le Blockstream Jade lorsqu’ils sont utilisés avec des versions plus récentes de HWI, tout en conservant le non_witness_utxo existant. La PR corrige également un problème avec des transactions multisig en attente dont le statut de signature stocké était devenu obsolète. BTCPay Server recalcule désormais leur progression de signature lorsqu’elles sont chargées et les marque comme Signed lorsqu’un nombre suffisant de signatures est présent et que le PSBT peut être finalisé avec succès.