signature : Quelle est la pré-image de hachage de transaction pour différentes valeurs de SIGHASH (et non de SIGHASH_ALL) dans P2PKH ?
J’ai quelques questions concernant la préimage de hachage de transaction lors de la signature avec différentes valeurs du drapeau SIGHASH dans le cas du P2PKH scénario.
Je sais à quoi ressemble la pré-image de hachage de transaction dans le cas de SIGHASH_ALL, mais à quoi ressemble-t-elle pour les autres valeurs de cet indicateur.
Supposons donc que notre transaction ait 3 entrées et 4 sorties et que nous puissions la noter T(I1, I2, I3; O1, O2, O3, O4), la pré-image dans le cas de SIGHASH_ALL sera la suivante.
Commençons par la saisie. Nous prenons toutes les entrées telles qu’elles sont (son contenu complet). Après cela, nous effaçons le champ scriptSig de toutes les entrées et définissons la longueur du champ scriptSig dans toutes les entrées à zéro (0x00). Ensuite, juste pour l’entrée que nous signons, nous définissons son champ scriptSig sur scriptPubKey à partir de la sortie (UTXO) vers laquelle pointe cette entrée. De plus, nous définirons la longueur du champ scriptSig dans cette entrée sur la longueur de ce script scriptPubKey nouvellement ajouté. La longueur du champ scriptSig dans les autres entrées reste nulle (0x00) et le champ scriptSig reste vide. En ce qui concerne les sorties, nous copions leur contenu complet et les ajoutons au contenu légèrement modifié des entrées décrit précédemment. Enfin, nous ajoutons en plus 0x01000000, ce qui indique qu’il s’agit d’une signature de type SIGHASH_ALL.
C’est ainsi que cela fonctionne dans le cas de SIGHASH_ALL, mais comment cela fonctionne-t-il pour les autres valeurs de ce drapeau.
Mon hypothèse est que c’est exactement le même processus, la seule question est de savoir quels intrants et extrants sont pris en compte. Par conséquent, les préimages de hachage de transaction pour les différentes valeurs du drapeau SIGHASH sont les suivantes (j’ai pris en compte les valeurs définies dans le livre Master Bitcoin) :
- pour les entrées, absolument la même histoire que celle que j’ai décrite pour SIGHASH_ALL s’applique
- les sorties ne sont pas prises en compte (elles ne font pas partie de la pré-image de hachage de transaction, de la même manière que le champ scriptSig des autres entrées n’en fait pas non plus partie)
- ajouter 0x02000000 à la fin
- pour les entrées, absolument la même histoire que celle que j’ai décrite pour SIGHASH_ALL s’applique
- seul le contenu de la sortie dont l’index correspond à l’index d’entrée est pris en compte (par exemple si on veut signer I2, on prendra les entrées I1, I2 et I3, mais seulement la sortie O2)
- ajouter 0x02000000 à la fin
- seule l’entrée que nous signons est incluse dans la pré-image de hachage de transaction, les autres entrées, c’est-à-dire leur contenu, ne font partie de la pré-image de hachage de transaction sous aucune forme (nous ignorons simplement les autres entrées, un scénario similaire que nous aurions si le la transaction n’avait qu’une seule entrée et le SIGHASH_ALL)
- pour les sorties, absolument la même histoire que celle que j’ai décrite pour SIGHASH_ALL s’applique (nous prenons l’intégralité du contenu de toutes les sorties)
- ajouter 0x81000000 à la fin
- pour les entrées, absolument la même histoire que celle que j’ai décrite pour 0x81 (ALL | ANYONECANPAY) s’applique
- les sorties ne sont pas prises en compte (elles ne font pas partie de la préimage du hachage de la transaction)
- ajouter 0x82000000 à la fin
- pour les entrées, absolument la même histoire que celle que j’ai décrite pour 0x81 (ALL | ANYONECANPAY) s’applique
- pour les sorties, absolument la même histoire que celle que j’ai décrite pour 0x03 (SIGNLE) s’applique
- ajouter 0x83000000 à la fin
Mes questions sont donc :
1. Est-ce ainsi que ça fonctionne ?
2. Existe-t-il d’autres valeurs pour le drapeau SIGHASH que je devrais couvrir ?
3. Existe-t-il des travaux/documents/normes connexes qui expliquent cela (peut-être pour d’autres scripts, comme P2WPKH, etc.) ?
