[ad_1]

The format for blocks is described here: https://bitcoin.org/en/developer-reference#serialized-blocks

The format for transactions is mostly described here: https://bitcoin.org/en/developer-reference#raw-transaction-format

However some transactions are segwit transactions, so they have a few additional fields that are not described in the above documentation. Those fields are described here: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki


Your decoding is a bit wrong:

00000020 – Transaction Version

That’s the block version, not transaction version.

01000000 – Transaction Version

01 – Coinbase has 1 transaction

You’ve actually missed two fields here. The first 7 bytes of the transaction are 01000000000101. These are as follows:

01000000 - Transaction version
00 - Segwit marker byte
01 - Segwit flag byte
01 - Number of inputs

Note that the segwit marker and flag bytes are only found in segwit transactions and indicate that a given transaction is a segwit transaction.

===== Coinbase Begin =====

The transaction version and the count after it all belong as part of the coinbase transaction. The count is not of the number of transactions but rather the number of inputs. A transaction is composed of inputs and outputs, not other transactions.

-> BE6D6DCAEEFE495F6BCA08E10FF6D24555166C2456D8129213354E32FD73EB1B141AB00100000000000000036507000F312D7B080100275C012F736C7573682F
– txin

No, that’s still part of the scriptSig. It itself is not a transaction input. This is just arbitrary data in the scriptSig of the coinbase transaction that miners put there.

00000000 – Lock Time

===== Coinbase End =====

000000002C6A4C2952534B424C4F434B3AA5BA6C5D1EFFA2034E994BEEE65C619DE2D2A1
– outpoint ?

B91892F193C170CAB74F152EAE0000000000000000266A24AA21A9ED85F7D06CCF8014D990E0242ACC0433EAF134732094E9A083A45AC3799259C9170000000001000000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33
– ?

No, there are three outputs but you have only decoded one of them.

The proper decoding is as follows:

0000000000000000 - Amount in satoshis
2c - scriptPubKey is 44 bytes
6a - OP_RETURN
4c - OP_PUSHDATA1
29 - Push 41 bytes to stack
52534b424c4f434b3aa5ba6c5d1effa2034e994beee65c619de2d2a1b91892f193c170cab74f152eae - 41 bytes of data
0000000000000000 - Amount in satoshis
26 - scriptPubKey is 38 bytes
6a - OP_RETURN
24 - Push 36 bytes to stack
aa21a9ed85f7d06ccf8014d990e0242acc0433eaf134732094e9a083a45ac3799259c917 - 36 bytes of data. This data is the witness commitment as described in [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure)

There is actually a next part of the transaction that you don’t have in your breakdowt. It is the witness data and the locktime.

01 – One witness stack item
20 – Stack item is 32 bytes in length
0000000000000000000000000000000000000000000000000000000000000000 – Stack item
00000000 – locktime

Then the next transaction starts with 01000000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33... and is decoded like the coinbase transaction above.

[ad_2]

Source link

By admin

Leave a Reply

Your email address will not be published. Required fields are marked *