PSBT

Anna veut envoyer 60 000 sat à Pavel, soit soixante mille des plus petites unités du bitcoin. Son portefeuille utilise une sortie reçue auparavant et encore non dépensée de 100 000 sat. Une sortie indique un montant et les conditions à remplir pour le dépenser. Dans cet exemple, le portefeuille prévoit 60 000 sat pour Pavel, 39 000 sat rendus à Anna et 1 000 sat de frais. Pour l’instant, ce ne sont que des instructions. L’application les place dans un PSBT et le transmet au portefeuille matériel, par câble, QR code ou carte mémoire selon l’appareil. Anna vérifie le paiement sur son écran et autorise la signature. C’est la signature qui revient, pas la clé secrète. Préparer le paiement ne nécessite donc pas d’utiliser l’appareil qui est habilité à l’autoriser. [1] [4]

Un fichier terminé par .psbt n’est pas automatiquement un paiement sûr. L’ordinateur qui l’a créé peut être compromis ou simplement mal configuré. Anna compare le destinataire à l’adresse reçue de Pavel, puis vérifie le montant, les frais totaux et le retour du reste dans son propre portefeuille. Avec un portefeuille matériel, elle s’appuie sur l’écran fiable de l’appareil et la procédure du fabricant. Le logiciel de signature vérifie aussi les données et la portée de la signature. Le terme technique sighash indique quelles parties de la transaction sont protégées contre les modifications par cette signature. Un débutant ne devrait pas accepter un mode inhabituel sans le comprendre. Si l’adresse ne correspond pas ou si les frais ne sont pas vérifiables, il faut revoir la proposition, pas contourner le contrôle. [1]

Dans un portefeuille Multisig exigeant deux signatures sur trois clés, Anna peut ajouter la première et Pavel la seconde, chacun avec son appareil. Ils n’ont besoin ni d’échanger leurs mots de récupération ni d’être connectés en même temps. Un coordinateur, l’application qui organise le processus, rassemble les éléments du même paiement et réunit les signatures. Chaque signataire doit néanmoins vérifier que le paiement correspond à son intention : le coordinateur ne décide pas pour lui. BIP 174 distingue le creator, qui commence la proposition, l’updater, qui ajoute les données, le signer, qui signe, et le combiner, qui fusionne les versions correspondantes. Le finalizer assemble les données finales satisfaisant les conditions des entrées ; l’extractor produit la transaction réseau ordinaire. Un programme cumule souvent plusieurs rôles. Ces noms désignent des tâches, pas six participants obligatoires. [1] [4]

Un PSBT peut révéler les fonds que tu comptes utiliser, ton destinataire, la monnaie qui te revient et les liens entre les adresses. Il peut aussi contenir un xpub, des données publiques permettant de dériver d’autres clés publiques et, avec les règles du portefeuille, des adresses, ou des chemins de dérivation, qui situent les clés dans la structure du portefeuille. Ne l’envoie donc pas à un service web quelconque juste pour lire son contenu. Un PSBT signé peut aussi permettre à une autre personne de terminer et diffuser précisément la transaction autorisée, si tous les éléments nécessaires sont disponibles. Effacer ta copie ne révoque pas la signature. Le fichier ne remplace ni Seed Phrase (les mots de sauvegarde servant à retrouver les clés) ni sauvegarde complète de configuration Multisig : il sert à un paiement précis, pas à la restauration générale du portefeuille. [1] [4]

Ajouter une signature ne signifie pas que le réseau connaît le paiement. Une fois la transaction finale assemblée, quelqu’un doit la diffuser. Un nœud est un ordinateur équipé d’un logiciel qui vérifie les transactions et les blocs Bitcoin. Un nœud l’évalue alors selon les règles du réseau et sa politique d’acceptation ; un mineur peut l’inclure dans un bloc. Une signature manquante, une entrée déjà dépensée et des frais insuffisants sont des problèmes distincts qu’un bouton ‘terminer’ ne résout pas à lui seul. Teste ta combinaison précise d’application, d’appareil et de type de portefeuille avant de t’y fier. Dans Bitcoin Core 29, analyzepsbt peut signaler des données ou signatures manquantes. finalizepsbt peut produire la transaction achevée ; l’envoi reste une autre étape. Même une finalisation réussie n’est pas une confirmation dans un bloc. [4] [5] [6]

BIP 174 définit PSBT comme un format binaire composé de paires clé–valeur. Ici, ‘clé’ désigne l’identifiant d’un champ, pas nécessairement une clé privée Bitcoin. Une table globale décrit toute la transaction, les tables d’entrées décrivent les anciennes sorties dépensées et les tables de sorties les nouvelles sorties créées. En plus de la proposition, elles peuvent contenir des scripts, c’est-à-dire les conditions de dépense, l’origine des clés et des signatures partielles. Les données peuvent être enregistrées en fichier .psbt ou représentées en Base64, un encodage de données binaires sous forme de texte. Base64 n’est pas du chiffrement. PSBT n’ajoute pas un type de transaction aux règles de Bitcoin : le réseau reçoit la transaction résultante, pas tout le fichier de travail. [1]

Un appareil hors réseau doit savoir ce qu’on lui demande de signer. Un UTXO est une ancienne sortie encore non dépensée, à laquelle une nouvelle entrée fait référence. Non-Witness UTXO peut contenir toute la transaction précédente ; Witness UTXO contient la sortie précise, avec son montant et ses conditions. Les éléments nécessaires dépendent du type d’entrée et des règles du logiciel de signature. Les contrôles portent notamment sur l’identifiant de la transaction précédente et la sortie correspondante, les liens entre scripts et un sighash acceptable. Un montant absent ne doit pas être interprété comme des frais nuls, ni des justificatifs absents comme une vérification réussie. Il faut fournir les données par une procédure fiable, pas les deviner. [1]

La version PSBT décrit l’organisation du format, pas le nombre de signatures ni la version de la transaction Bitcoin elle-même. PSBT v0 conserve la transaction non signée dans un champ global ; l’absence de version PSBT signifie v0. PSBT v2, défini par BIP 370, exclut ce champ et répartit les données de construction entre des champs distincts. Il permet ainsi d’ajouter des entrées et sorties en respectant les modifications autorisées et les signatures déjà présentes. Cela n’autorise pas à réécrire librement un paiement signé. Les deux parties doivent comprendre la version utilisée ; ‘compatible PSBT’ n’est pas une description assez précise. [2]

BIP 371 ajoute les informations nécessaires à Taproot, notamment ses signatures, scripts et origines de clés. Ces champs fonctionnent avec PSBT v0 comme avec PSBT v2. Un portefeuille peut donc gérer Taproot dans le premier format sans accepter le second. De même, la prise en charge de v2 ne prouve pas qu’un appareil maîtrise tous les cas Taproot. La signature par la voie de clé et la dépense par une branche de script sont deux façons différentes de satisfaire les conditions d’une sortie Taproot. Pour l’utilisateur, la question est simple : ma configuration précise peut-elle traiter le paiement que je veux signer ? La documentation et une procédure éprouvée y répondent, pas un sigle dans une liste de fonctions. [3]