Décoder un bloc au-delà de la transaction Coinbase
Le format des blocs est décrit ici : https://bitcoin.org/en/developer-reference#serialized-blocks
Le format des transactions est principalement décrit ici : https://bitcoin.org/en/developer-reference#raw-transaction-format
Cependant, certaines transactions sont des transactions segwit, elles comportent donc quelques champs supplémentaires qui ne sont pas décrits dans la documentation ci-dessus. Ces champs sont décrits ici : https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
Votre décodage est un peu faux :
00000020 – Version de transaction
C'est la version bloc, pas la version transaction.
01000000 – Version de transaction
01 – Coinbase a 1 transaction
Vous avez en fait manqué deux champs ici. Les 7 premiers octets de la transaction sont 01000000000101. Ils sont les suivants :
01000000 – Version de transaction 00 – Octet de marqueur Segwit 01 – Octet de drapeau Segwit 01 – Nombre d'entrées
Notez que le marqueur segwit et les octets d'indicateur ne se trouvent que dans les transactions segwit et indiquent qu'une transaction donnée est une transaction segwit.
===== Coinbase Début =====
La version de la transaction et le décompte après tout font partie de la transaction coinbase. Le décompte ne concerne pas le nombre de transactions mais plutôt le nombre d'entrées. Une transaction est composée d'entrées et de sorties, pas d'autres transactions.
-> BE6D6DCAEEFE495F6BCA08E10FF6D24555166C2456D8129213354E32FD73EB1B141AB001000000000000000036507000F312D7B080100275C012F736C7573682F – txin
Non, cela fait toujours partie du scriptSig. Ce n’est pas en soi une entrée de transaction. Il ne s'agit que de données arbitraires dans le scriptSig de la transaction coinbase que les mineurs y ont placées.
00000000 – Heure de verrouillage
===== Fin Coinbase =====
000000002C6A4C2952534B424C4F434B3AA5BA6C5D1EFFA2034E994BEEE65C619DE2D2A1 – point de sortie ?
B91892F193C170CAB74F152EAE0000000000000000266A24AA21A9ED85F7D06CCF8014D990E0242ACC0433EAF134732094E9A083A45AC3799259C9170000000001000 000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33 – ?
Non, il y a trois sorties mais vous n’en avez décodé qu’une.
Le décodage correct est le suivant :
0000000000000000 – Montant en satoshis 2c – scriptPubKey est de 44 octets 6a – OP_RETURN 4c – OP_PUSHDATA1 29 – Pousser 41 octets pour empiler 52534b424c4f434b3aa5ba6c5d1effa2034e994beee65c619de2d2a1b91 892f193c170cab74f152eae – 41 octets de données 0000000000000000 – Montant en satoshis 26 – scriptPubKey fait 38 octets 6a – OP_RETURN 24 – Poussez 36 octets vers pile aa21a9ed85f7d06ccf8014d990e0242acc0433eaf134732094e9a083a45ac3799259c917 – 36 octets de données. Ces données constituent l'engagement du témoin tel que décrit dans [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure)
Il y a en fait une partie suivante de la transaction que vous n'avez pas dans votre répartition. Ce sont les données des témoins et le temps de verrouillage.
01 – Un élément de pile témoin 20 – L'élément de pile a une longueur de 32 octets 00000000000000000000000000000000000000000000000000000000000 – Élément de pile 00000000 – temps de verrouillage
Ensuite, la transaction suivante commence par 01000000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33… et est décodée comme la transaction coinbase ci-dessus.