PSBT v2

Anna et Jan souhaitent payer une facture ensemble. Chacun apporte une partie des fonds et ajoute sa signature sur son propre appareil. Ils doivent échanger une proposition commune, pas leurs clés privées. Une clé privée est un nombre secret utilisé par le portefeuille pour créer une signature numérique autorisant une dépense. PSBT sert d’enveloppe de travail contenant la transaction et les informations qui l’accompagnent. Les entrées désignent des montants antérieurs à dépenser ; les sorties définissent de nouveaux montants et leurs conditions de dépense ultérieure. Le format initial PSBT v0 conserve cette structure dans une transaction globale non signée et figée. Avec v2, les entrées et les sorties peuvent être ajoutées progressivement selon les règles applicables. L’intérêt est de construire ensemble, pas de pouvoir réécrire librement ce qui a déjà été signé. [1] [2]

Anna n’a pas à lire chaque champ technique. Elle doit toutefois vérifier sur un appareil de signature fiable le destinataire réel, le montant, les frais et l’éventuel reliquat rendu à son portefeuille. Ce dernier point passe facilement inaperçu : une sortie appartenant à autrui ne doit pas être prise pour son propre rendu de monnaie. L’appareil doit vérifier les données des UTXO, les sorties encore non dépensées, et la cohérence de leurs conditions avec ce qu’il signe. Un chemin de dérivation décrit les étapes permettant au portefeuille de calculer une clé précise à partir de sa clé maîtresse. La présence de ce chemin dans le fichier ne prouve pas à elle seule la propriété. L’appareil doit aussi interpréter SIGHASH, le réglage qui détermine les parties de la transaction protégées par la signature. Signer ne nécessite pas d’ajouter au fichier échangé une clé privée ni la Seed Phrase, les mots de sauvegarde du portefeuille. [2] [4]

La mention « compatible PSBT » sur un appareil ou dans une application ne garantit pas la prise en charge de v2. Il faut vérifier tout le parcours : création, importation, signature et retour du résultat entre les logiciels et les appareils précis qui seront utilisés. PSBT v0 et v2 ne sont pas directement interchangeables. Passer à v0 exige de construire une transaction non signée et d’adapter les champs aux règles de cette version ; modifier un numéro ne suffit pas. Taproot, une façon plus récente de définir les conditions de dépense des sorties Bitcoin, est également distinct de v2. BIP 371 décrit les données de signature correspondantes pour les deux versions de PSBT. Un petit essai du parcours complet vérifie la compatibilité de cette configuration, pas la validité de tous les paiements futurs. [1] [3]

La version du format de fichier et celle de la transaction Bitcoin ont des significations différentes. Dans v2, PSBT_GLOBAL_VERSION doit contenir 2, tandis que l’ancien champ PSBT_GLOBAL_UNSIGNED_TX doit être absent. Un autre champ obligatoire, PSBT_GLOBAL_TX_VERSION, indique la version de la transaction elle-même. Les nombres d’entrées et de sorties sont eux aussi obligatoires. Cette séparation regroupe les informations auprès de chaque élément, sans obliger le programme à les rechercher aussi dans une structure commune. Si le créateur confie la suite de la construction à d’autres participants, BIP 370 impose les indicateurs de modification appropriés et une version de transaction au moins égale à 2. Il s’agit toujours d’un format de travail, pas de nouvelles règles de consensus du réseau. [1]

Chaque entrée doit préciser un TXID, l’identifiant de la transaction précédente, et l’index de la sortie qui y est dépensée. Le TXID seul ne suffit pas : une transaction peut avoir plusieurs sorties. Chaque nouvelle sortie comporte un montant en satoshi, les plus petites unités de Bitcoin, et un scriptPubKey, le script définissant ses conditions de dépense. L’ajout d’un élément doit s’accompagner d’une mise à jour du nombre total d’entrées ou de sorties, selon le cas. Le champ facultatif sequence contient une autre valeur de contrôle de l’entrée ; s’il est absent, la valeur retenue est 0xffffffff. Ces données expliquent comment assembler la transaction. Elles ne remplacent pas les informations sur la valeur et les conditions de dépense des UTXO, nécessaires à l’appareil pour évaluer correctement la signature et les frais. [1]

Supposons que Jan doive ajouter une entrée. Le programme ne peut pas présumer qu’il en a le droit simplement parce qu’il possède le fichier. Dans PSBT_GLOBAL_TX_MODIFIABLE, le bit 0 indique si les entrées peuvent changer et le bit 1 si les sorties peuvent changer. Le bit 2 signale une signature SIGHASH_SINGLE, qui associe une entrée à la sortie occupant la position correspondante. Cette association doit subsister lors de l’insertion d’autres éléments. Le constructeur examine donc les signatures présentes et leurs restrictions. Les indicateurs renseignent les programmes qui coopèrent ; ils ne contournent pas une signature cryptographique et ne rendent pas valide une modification qui ne l’est pas. [1]

Certaines entrées exigent d’attendre une hauteur de bloc ou une limite temporelle avant que la transaction puisse être utilisée. Un bloc regroupe des transactions inscrites dans l’historique commun du réseau ; sa hauteur indique sa position dans la chaîne. Le champ commun nLockTime doit correspondre à un type d’exigence compatible avec toutes les entrées. On retient la valeur requise la plus élevée de ce type ; lorsque les deux types sont possibles, la hauteur de bloc a priorité. On ne compare donc pas une hauteur et un temps comme deux nombres ordinaires. Si aucune entrée n’impose d’exigence, on utilise la valeur globale de repli, ou 0 en son absence. Une entrée aux exigences incompatibles ne doit pas être ajoutée. Si des signatures existent déjà, une nouvelle entrée ne doit pas non plus modifier le nLockTime calculé. Ces champs ne garantissent pas à eux seuls le respect de toutes les règles de verrouillage temporel. [1]

Chaque signature restreint les modifications suivantes. BIP 370 impose au signataire de désactiver les changements d’entrées sans SIGHASH_ANYONECANPAY et ceux des sorties sans SIGHASH_NONE ; avec SIGHASH_SINGLE, il signale l’association à préserver. Ces noms désignent différents périmètres de protection par la signature, pas des options à essayer au hasard quand on débute. Quand toutes les entrées sont prêtes, la finalisation assemble les données de signature nécessaires et un extracteur construit la transaction au format du réseau. Ce n’est qu’après diffusion que les nœuds peuvent l’évaluer et qu’un mineur peut l’inclure dans un bloc. Anna et Jan distinguent donc proposition, résultat signé et paiement confirmé : transmettre un PSBT ne constitue en soi ni une signature ni une confirmation. [1] [2] [4]