Witness Data désigne les données jointes aux entrées d’une transaction pour vérifier les conditions de dépense de SegWit. Une entrée fait référence à des pièces reçues auparavant et dépensées maintenant. Witness peut contenir des signatures, des clés publiques ou un script. Il fait partie de la transaction ; ce n’est pas un autre endroit où se trouve votre argent.
Anna a reçu du Bitcoin et veut maintenant payer Pierre. Le paiement précédent a créé une sortie : un enregistrement du montant et des conditions de sa dépense future. La nouvelle transaction la désigne par une entrée. Affirmer que les pièces appartiennent à Anna ne suffit pas. Pour un paiement ordinaire, le portefeuille crée une signature vérifiable sans révéler la clé privée. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. La clé privée est une valeur numérique secrète qui permet de créer cette signature. Avec SegWit, ces éléments sont fournis dans le witness de l’entrée. La présence d’une signature ne prouve pas encore sa validité. [1] [4] [5]
Imaginez la différence entre « présenter un justificatif valide » et le justificatif effectivement présenté. Bitcoin n’a pas d’arbitre humain : des règles vérifient leur correspondance. Le witness program fait partie de la condition inscrite dans l’ancienne sortie ; sa version détermine son évaluation. La nouvelle transaction qui dépense cette sortie fournit le witness. Techniquement, c’est une liste ordonnée d’éléments de données par entrée. Ce n’est pas automatiquement un programme exécutable ni une copie de toutes les pièces non dépensées. [1] [7]
Witness peut révéler une signature, une clé publique ou le script utilisé, le programme décrivant les conditions de dépense. La clé publique sert à vérifier les signatures et n’a pas besoin de rester secrète. Ce n’est pas une boîte chiffrée. Votre clé privée reste avec vous : elle sert à signer, pas à être envoyée sur le réseau à la place de la signature. Ni witness ni une signature publiée ne remplacent la Seed Phrase, les mots permettant de restaurer le portefeuille. Si vous perdez les clés et la sauvegarde, le seul historique public ne vous rend pas la capacité de signer d’autres paiements. [1] [3] [4]
Un explorateur de blocs est une application permettant de consulter les transactions et les blocs d’un réseau donné. Un explorateur peut afficher wtxid à côté de txid. Ce sont des hashes, de courtes empreintes d’une représentation exacte des données, calculées en appliquant SHA-256 deux fois. txid utilise le format sans witness ; wtxid le format complet avec witness. Ce ne sont ni des adresses de destination ni deux paiements distincts. Sans witness, le format initial est utilisé et les deux identifiants sont égaux. Dans Bitcoin Core v29.0, decoderawtransaction donne l’identifiant complet dans hash et les données witness d’une entrée dans txinwitness. [1] [7] [8]
Une autre transaction peut se référer à la précédente avant sa confirmation. Si quelqu’un pouvait changer son identifiant en modifiant seulement les données de signature, la référence ne correspondrait plus. Modifier witness seul ne change pas txid. Cela aide des protocoles utilisant des transactions dépendantes, comme Lightning Network. Toute la transaction n’est pas pour autant immuable. D’autres champs ou d’anciennes entrées sans SegWit peuvent encore modifier txid, et un witness changé doit toujours respecter les règles de vérification applicables. [1] [6]
Witness accompagne la représentation complète de la transaction et fait partie des données du bloc après inclusion. Ce n’est pas un stockage gratuit hors chaîne. Un octet ajouté par la sérialisation witness compte pour 1 WU, contre 4 WU pour un octet de base ; WU signifie unité de poids. Un Full Node vérifie lui-même les règles et a besoin des données concernées pour valider la dépense. Un poids réduit ne permet pas de sauter les contrôles nécessaires et ne signifie pas que les données n’occupent aucun espace. [1] [7]
Dans l’ancien format, les preuves de dépense figuraient dans scriptSig. SegWit natif de version 0 impose que ce champ soit vide : les preuves sont dans witness. Il existe aussi une forme encapsulée dans P2SH, l’ancienne méthode de paiement vers une condition identifiée par le hash d’un script. Ici, scriptSig doit contenir exactement l’insertion du witness program correspondant, sans instructions supplémentaires arbitraires. Les preuves restent dans witness. Un même objectif peut donc avoir des représentations différentes ; le nom du champ ne suffit pas à les interpréter. [1] [5]
P2WPKH fournit une signature et une clé publique. Le nœud vérifie que le hash de la clé correspond à la condition initiale et que la signature est valide. P2WSH permet une condition identifiée par le hash d’un script entier. Le dernier élément witness est witnessScript, dont le hash doit correspondre au programme de la sortie. Les éléments précédents fournissent les données initiales d’exécution, telles que les signatures. BIP 143 définit la construction du message signé pour cette version, en incluant la valeur de la sortie dépensée. Savoir lire les données ne prouve pas le respect des conditions. [1] [2] [5]
Taproot utilise witness natif de version 1 et permet une dépense par clé ou par script. Avant de choisir le chemin, un éventuel annex, champ supplémentaire particulier, est mis à part ; ses données comptent toujours dans le poids et sont couvertes par la signature. S’il reste un élément, il est interprété comme la signature du chemin par clé. Le chemin par script révèle le script utilisé et un control block : des données prouvant son lien avec l’ancienne sortie, pas un nouveau bloc de la chaîne. Les éléments antérieurs éventuels alimentent le script. Les règles de version 0 ne se transposent pas directement. [3] [5]
Un engagement cryptographique (commitment) est une empreinte qui lie des données à leur contenu précis. Lorsque cet engagement envers les données witness est requis, BIP 141 les relie au reste du bloc par la Coinbase Transaction, la première transaction destinée à la récompense du mineur. Un arbre de hashes wtxid produit une racine résumant les données. La transaction de récompense y utilise un wtxid nul. La racine est combinée à une valeur réservée de 32 octets puis hachée deux fois pour produire l’engagement inscrit dans sa sortie. Si aucune transaction n’a de witness, cet engagement est facultatif. Il relie des preuves publiques ; il ne sauvegarde pas les clés et ne remplace pas la vérification. [1]
Pour une vision complète, lisez aussi SegWit, Block Weight, Bitcoin Script, Taproot, Bitcoin, Seed Phrase. Cette entrée est également citée par Block Weight, Miniscript, Compact Block Filters.