Bitcoin : un brouillon propose des clés internes Taproot reproductibles depuis les règles du portefeuille

Un dépôt ouvert, sans adoption annoncée

Une demande de contribution ouverte le 1er novembre 2026 dans le dépôt des propositions d’amélioration de Bitcoin présente une convention pour les clés internes Taproot des portefeuilles. Numérotée 2340 dans GitHub, elle est encore ouverte et non fusionnée lors de la vérification. Ce nombre désigne la demande, pas un numéro de BIP attribué. Le document porte le statut Draft et cherche à rendre une construction reproductible par plusieurs logiciels à partir des mêmes règles de portefeuille.

Le marqueur proposé est le caractère souligné, utilisé à la place d’une clé interne dont aucune clé de signature n’est connue. Cela concerne une voie particulière de dépense Taproot, et non une interdiction de dépenser tous les bitcoins du portefeuille. Les autres conditions prévues dans les scripts restent déterminantes. Le brouillon précise d’ailleurs que construire cette clé ne dispense pas les logiciels de vérifier séparément la validité et les exigences de la politique qui l’entoure.

Retrouver la construction sans secret aléatoire supplémentaire

Le problème décrit est celui des portefeuilles qui veulent rendre cette voie interne inutilisable tout en évitant une clé fixe facilement reconnaissable lorsqu’une dépense révèle les données correspondantes. Certaines méthodes utilisent une valeur aléatoire qu’il faut ensuite conserver. Le texte propose plutôt de dériver les paramètres publics depuis une forme normalisée de la politique. Deux implémentations pourraient alors retrouver la clé interne avec cette politique et le chemin de dérivation, sans sauvegarder ce secret supplémentaire.

La construction s’appuie sur des mécanismes existants, notamment les clés étendues de BIP 32 et un point décrit par BIP 341 dont le logarithme discret n’est pas connu. Son engagement cryptographique couvre les clés et la structure des règles : seuils, délais, rôles ou organisation de l’arbre. L’objectif est de distinguer des politiques utilisant les mêmes clés sous des conditions différentes. Il ne s’agit pas de prétendre que toutes les règles produisant des résultats équivalents seraient automatiquement reconnues comme identiques.

La politique reste nécessaire à la sauvegarde

Cette reproductibilité a des limites. Le document indique qu’une sauvegarde de la phrase de récupération seule ne reconstruit pas la politique du portefeuille. Il explique aussi qu’un observateur connaissant ou devinant la politique complète pourrait reconstruire les paramètres publics et énumérer certaines clés internes. La proposition ne garantit donc pas une confidentialité absolue. Sa sécurité repose notamment sur l’hypothèse cryptographique concernant le point de départ et sur le respect exact des règles de dérivation.

Une adoption de cette convention changerait les adresses d’une politique existante. Le brouillon exige ainsi de traiter le résultat comme un descripteur distinct et de conserver l’ancien pour surveiller et dépenser les fonds reçus auparavant. Une implémentation Python et des vecteurs de test accompagnent la demande, mais leur rôle annoncé est la démonstration et l’interopérabilité, pas l’usage en production. Le dépôt d’aujourd’hui ouvre une revue technique ; il ne prouve ni validation collective, ni compatibilité universelle, ni déploiement dans les portefeuilles.