PSBT v2 est le format BIP 370 d’échange d’une transaction Bitcoin inachevée et des informations nécessaires à sa signature. Le numéro désigne la version de l’enveloppe PSBT, pas automatiquement celle de la transaction ni une nouvelle validation réseau.
PSBT v0, défini par BIP 174, contient une transaction globale non signée. BIP 370 déplace ses données de construction dans des champs distincts. Les participants peuvent ainsi ajouter des entrées et des sorties après création de l’enveloppe, en respectant les règles. Cela ne permet ni de modifier arbitrairement les parties signées ni de considérer le fichier comme un paiement. [BIP 370 — PSBT Version 2] [BIP 174 — Partially Signed Bitcoin Transaction Format]
PSBT_GLOBAL_VERSION doit valoir 2 et PSBT_GLOBAL_UNSIGNED_TX doit être absent. Le champ obligatoire PSBT_GLOBAL_TX_VERSION précise séparément la version de la transaction ; la table globale contient aussi les nombres d’entrées et de sorties. Changer uniquement le numéro de version d’un ancien fichier ne produit pas un PSBT v2 valide. [BIP 370 — PSBT Version 2]
Une entrée doit identifier le TXID précédent et l’index de la sortie dépensée. Une sortie doit contenir son montant en satoshi et son scriptPubKey ; tout ajout met aussi à jour le compteur global correspondant. Une sequence d’entrée absente signifie 0xffffffff. Ces données ne remplacent pas la vérification des UTXO ni des autres informations nécessaires au dispositif de signature. [BIP 370 — PSBT Version 2]
Dans PSBT_GLOBAL_TX_MODIFIABLE, le bit 0 permet de modifier les entrées et le bit 1 les sorties. Le bit 2 signale une signature SIGHASH_SINGLE : son entrée et sa sortie doivent rester associées à l’index correspondant. Le constructeur doit examiner les signatures réelles ; un indicateur activé ne sécurise pas une modification autrement invalide. [BIP 370 — PSBT Version 2]
Pour nLockTime, on choisit un type d’exigence compatible avec toutes les entrées, puis sa valeur maximale. Si les deux types conviennent, la hauteur de bloc prime ; une entrée incompatible ne peut être ajoutée. Sans exigence des entrées, on utilise la valeur globale de repli, sinon zéro. Une nouvelle entrée ne doit pas changer nLockTime si des signatures existent déjà. [BIP 370 — PSBT Version 2]
Le signataire actualise les indicateurs selon SIGHASH. Sans SIGHASH_ANYONECANPAY, il interdit les modifications d’entrées ; sans SIGHASH_NONE, celles des sorties, et avec SIGHASH_SINGLE il marque l’association requise. Après finalisation, l’extracteur construit la transaction réseau à partir des champs. Diffusion et acceptation par le réseau sont des étapes supplémentaires, pas des propriétés de l’enveloppe transmise. [BIP 370 — PSBT Version 2] [BIP 174 — Partially Signed Bitcoin Transaction Format] [Bitcoin Core — PSBT workflow]
PSBT v0 et v2 ne sont pas directement interchangeables. Convertir vers v0 exige de construire la transaction non signée et de respecter les règles de champs de cette version. BIP 371 définit séparément les données Taproot pour les deux versions. Gérer PSBT ou Taproot ne prouve donc pas qu’un portefeuille sait importer, signer et exporter PSBT v2. [BIP 370 — PSBT Version 2] [BIP 371 — Taproot Fields for PSBT]
Sur un appareil fiable, compare les destinataires, montants, sortie de monnaie rendue et frais à ton intention initiale. Vérifie les données UTXO, les scripts et le SIGHASH utilisé ; les métadonnées de dérivation des clés ne prouvent pas à elles seules la propriété d’une sortie. Un essai avec le coordinateur et l’appareil concernés vérifie la compatibilité, pas la sécurité de toutes les transactions futures. [BIP 174 — Partially Signed Bitcoin Transaction Format] [Bitcoin Core — PSBT workflow]
Pour une vision complète, lisez aussi PSBT, Hardware Wallet, Multisig, Taproot.