PSBT version 2

La version 0 fige l'ensemble des entrées et des sorties à la création ; la version 2 place chaque détail dans des tables propres à chaque entrée et à chaque sortie. Le BIP-370 a été attribué le 14 janvier 2021 et saute le numéro 1, puisque le format du BIP-174 est la version 0 et était appelé familièrement version 1. Pour un détenteur, la version 2 ne compte que dans une session de signature où un autre participant ajoute des bitcoins à une transaction que vous avez déjà lancée.

Comment cela fonctionne

PSBT version 2 conserve le conteneur externe du BIP-174 et réorganise ce qu'il contient. Deux règles définissent le changement : PSBT_GLOBAL_UNSIGNED_TX doit être absent, et PSBT_GLOBAL_VERSION doit être présent et défini à 2.

Ce que la transaction supprimée portait autrefois est réparti sur douze nouveaux champs. Cinq sont globaux : la version de transaction (0x02), le locktime de repli (0x03), le nombre d'entrées (0x04), le nombre de sorties (0x05) et un octet d'indicateurs modifiables (0x06). Cinq se trouvent sur chaque entrée : le txid précédent de 32 octets (0x0e), l'index de sortie dépensée (0x0f), le numéro de séquence (0x10), et deux locktimes obligatoires, l'un fondé sur un horodatage égal ou supérieur à 500000000 (0x11), l'autre fondé sur une hauteur inférieure à cette valeur et supérieure à zéro (0x12). Les sorties en gagnent deux, le montant en satoshis sous forme d'entier signé de 64 bits en petit-boutiste (0x03) et le script (0x04).

L'octet d'indicateurs modifiables fait le vrai travail. Le bit 0 indique que des entrées peuvent encore être ajoutées ou supprimées, le bit 1 dit la même chose pour les sorties, et le bit 2 consigne qu'une signature s'est déjà engagée avec SIGHASH_SINGLE, de sorte que son appariement entrée-sortie doit être préservé. Un signataire doit resserrer ces bits au fur et à mesure : une signature qui n'utilise pas SIGHASH_ANYONECANPAY efface le bit 0, et une signature qui n'utilise pas SIGHASH_NONE efface le bit 1. L'autorisation de continuer à modifier expire d'elle-même à mesure que les signatures arrivent, plutôt que de reposer sur la bonne volonté du prochain détenteur.

Le BIP-370 tranche les deux questions que la transaction manquante laissait ouvertes. Le locktime devient la plus grande valeur sur laquelle les entrées s'accordent, avec repli sur le champ global, ou sur 0 lorsque celui-ci est absent, et une exigence fondée sur une hauteur l'emporte en cas d'égalité. L'identité devient le txid obtenu en assemblant les champs avec chaque numéro de séquence forcé à 0, puisque la séquence peut encore être modifiée par la suite.

Où le rencontre-t-on

PSBT version 2 introduit un rôle sans équivalent dans le BIP-174, le Constructor. Un Creator ouvre le fichier avec 0 entrées et 0 sorties et le transmet ; le Constructor les ajoute, après avoir vérifié les indicateurs modifiables. Un Creator qui attend des contributions doit aussi définir la version de transaction à au moins 2, afin que les fonctions qui en dépendent, comme OP_CHECKSEQUENCEVERIFY, restent disponibles.

La version 2 réutilise la sérialisation du BIP-174, si bien qu'un fichier semble identique de l'extérieur, et cette séparation est délibérée : sur les 24 vecteurs de test invalides du BIP, 13 sont des fichiers ordinaires de version 0 rejetés pour un champ ou un numéro de version mal placé. La conversion se fait dans un seul sens, puisqu'un fichier de version 2 peut être reconstruit comme un fichier de version 0 à partir de ses propres champs. L'implémentation de référence est la demande de fusion 21283 de Bitcoin Core, et l'en-tête du BIP indique le statut Deployed.

Sur les 41 avis de portefeuilles de ce site, deux mentionnent les PSBT, Sparrow (noté 4,7) et BlueWallet (4,2), et aucun ne nomme de version. Supposez la version 0 sauf indication contraire du logiciel, et testez un outil que vous ne connaissez pas avec un petit montant avant de lui confier le reste.

PSBT version 2 vs le numéro de version de transaction

PSBT version 2 numérote le format de fichier, tandis que le numéro de version de transaction numérote la transaction assemblée à l'intérieur. Les deux résident dans la même table globale, et le BIP-370 dit clairement qu'il ne s'agit pas du même champ. PSBT_GLOBAL_VERSION vaut 2 dans tout fichier de version 2 ; PSBT_GLOBAL_TX_VERSION est un entier signé de 32 bits pour la transaction en cours d'assemblage, et le BIP-370 exige qu'il soit au moins égal à 2 lorsque le Creator attend des contributions, ce qui explique la confusion entre les deux. Modifiez le premier et les analyseurs plus anciens refusent le fichier. Modifiez le second et vous changez les règles de consensus selon lesquelles la dépense est jugée.