• Taproot a été activé sur le réseau principal de Bitcoin au bloc 709 632 en 2021 sous la forme d’un soft fork.

• BIP 340 définit les signatures Schnorr sur la courbe secp256k1 pour les sorties Taproot.

• BIP 341 établit les règles relatives aux sorties Taproot, aux engagements et aux dépenses ; BIP 342 définit Tapscript.

Les portefeuilles et les plateformes d’échange face à la question des bc1p

Les portefeuilles Bitcoin (BTC) qui proposent désormais une option Taproot, ainsi que les plateformes d’échange et les dispositifs matériels de signature qui doivent accepter les adresses bc1p générées, sont les acteurs qui déterminent si les avantages de la mise à niveau profiteront aux utilisateurs ordinaires. Taproot est un soft fork du protocole Bitcoin (BTC), activé sur le réseau principal de Bitcoin au bloc 709 632 en 2021. Il a introduit les sorties Pay-to-Taproot (P2TR), régies par les règles de témoin de version 1. Cette modification concerne la façon dont les bitcoins sont dépensés, et non ce que possèdent les détenteurs : les destinataires reçoivent toujours des BTC, il n’existe aucun jeton Taproot distinct, et le prix ainsi que le calendrier d’émission de Bitcoin (BTC) n’entrent pas dans son champ d’application.

La mise à niveau regroupe trois propositions coordonnées. Le BIP 340 spécifie les signatures Schnorr sur la courbe secp256k1, une structure algébrique différente de celle du schéma ECDSA sur lequel Bitcoin s’appuyait jusque-là, et qui se prête aux protocoles de signature multipartite. Le BIP 341 définit le format de sortie Taproot, sa structure d’engagement et les règles permettant de la dépenser. Le BIP 342, connu sous le nom de Tapscript, établit les règles d’exécution des scripts dans ces sorties. Ces trois propositions sont interdépendantes, mais décrivent des couches distinctes ; les traiter comme une seule fonctionnalité est une erreur courante.

Concernant les adresses, les sorties Taproot du réseau principal commencent généralement par bc1p et utilisent l’encodage Bech32m, tandis que les adresses SegWit natives de version 0 commencent par bc1q et utilisent Bech32. Elles se trouvent toutes deux sur la même chaîne : il n’existe ni second réseau Bitcoin ni conversion par modification manuelle d’un préfixe. Ce préfixe dépend du système de versionnement de Segregated Witness, qui a créé des versions de témoin numérotées, Taproot correspondant à la version 1. Les anciennes sorties restent valides après l’activation, et la migration est volontaire : transférer des bitcoins vers une sortie Taproot entraîne toujours des frais de transaction sur la chaîne. Le soft fork laisse également intacte la couche de consensus Proof of Work, raison pour laquelle les travaux de compatibilité se concentrent sur les portefeuilles plutôt que sur le protocole lui-même.

Les chemins de clé et de script remplissent des rôles différents

Une sortie Taproot peut être dépensée de deux façons, et cette distinction détermine tout ce qu’un observateur voit sur la chaîne. Le chemin de clé autorise une dépense au moyen d’une signature Schnorr vérifiée par rapport à la clé publique de la sortie. Les autres scripts éventuels ne sont pas révélés et, dans une conception coopérative, telle qu’un protocole de type MuSig, plusieurs participants peuvent produire conjointement une seule signature qui, sur la chaîne, ressemble à celle d’un propriétaire unique. L’analyse de la chaîne ne permet pas de distinguer de manière fiable une dépense individuelle d’une dépense collaborative. Le chemin de script s’applique lorsqu’une condition engagée est remplie : le dépensier révèle le script choisi, fournit les données qui satisfont ses conditions et prouve que le script fait partie de l’engagement de la sortie. Les branches inutilisées restent cachées, mais le script exécuté et ses preuves sont visibles.

Les cas d’utilisation typiques diffèrent en conséquence. Les paiements directs et les dépenses multipartites coopératives passent par le chemin de clé, tandis que les verrouillages temporels, les conditions de secours et autres éventualités relèvent du chemin de script. Deux idées reçues sont importantes pour quiconque déplace des fonds. Les signatures multisig ne se réduisent pas automatiquement à une seule signature lors de l’activation : cela nécessite un protocole de signature multipartite adapté ainsi que la prise en charge des portefeuilles, et les bitcoins détenus dans des sorties multisig héritées ne sont pas convertis. L’agrégation des signatures entre entrées n’est pas non plus une fonctionnalité fournie automatiquement par cette mise à niveau. Sur le plan de la confidentialité, Taproot réduit la divulgation des conditions de dépense et permet à différentes configurations de produire des dépenses par le chemin de clé d’apparence identique, mais les montants, la structure des sorties et les liens entre les transactions restent publics et analysables. Une adresse bc1p ne garantit donc pas l’anonymat.

Les frais ne sont pas non plus systématiquement moins élevés. Le coût dépend de la taille virtuelle de la transaction, du taux choisi en sat/vB et de la concurrence dans la mempool. De plus, le coût en données de la création d’une sortie Taproot diffère de celui de sa dépense ultérieure : ces deux étapes doivent donc être évaluées ensemble. Prenons l’exemple d’un dispositif de garde à deux parties : en fonctionnement normal, les parties signent de manière coopérative par le chemin de clé, tandis qu’un script de secours verrouillé dans le temps est engagé à l’avance et n’est révélé et exécuté que si la coopération échoue. Le concept est général, mais les clés, les scripts, les sauvegardes et les protocoles de signature doivent être correctement conçus pour que cela fonctionne.

Ce que la prise en charge par les portefeuilles détermine encore

Les travaux sur le protocole sont achevés : le BIP 341 fixe les règles relatives aux sorties, aux engagements et aux dépenses, et les opérateurs de nœuds qui appliquent les règles de consensus actuelles valident les dépenses P2TR sans configuration supplémentaire. En revanche, les outils qui l’entourent ne sont pas encore au point. Un portefeuille capable de recevoir à une adresse Taproot n’est pas nécessairement capable de signer une dépense par le chemin de clé, et les appareils matériels ou les configurations multisig personnalisées doivent être adaptés pour utiliser cette nouvelle voie en toute sécurité. L’espace élargi de conception des scripts, sur lequel s’appuient les projets désormais regroupés sous l’appellation Bitcoin DeFi, ainsi que la structure de témoin de version 1 qui a ensuite accueilli les inscriptions Bitcoin Ordinals, reposent tous deux sur ces mêmes règles. Tant que les signataires, les appareils et les plateformes de dépôt ne seront pas tous compatibles avec bc1p, l’adoption restera facultative et inégale.