Friday, November 22, 2024

Decoding a Block past the Coinbase transaction

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

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

Nonetheless some transactions are segwit transactions, so that they have just a few further fields that aren’t described within the above documentation. These fields are described right here: https://github.com/bitcoin/bips/blob/grasp/bip-0144.mediawiki


Your decoding is a bit mistaken:

00000020 – Transaction Model

That is the block model, not transaction model.

01000000 – Transaction Model

01 – Coinbase has 1 transaction

You’ve got truly missed two fields right here. The primary 7 bytes of the transaction are 01000000000101. These are as follows:

01000000 - Transaction model
00 - Segwit marker byte
01 - Segwit flag byte
01 - Variety of inputs

Observe that the segwit marker and flag bytes are solely present in segwit transactions and point out {that a} given transaction is a segwit transaction.

===== Coinbase Start =====

The transaction model and the rely after all of it belong as a part of the coinbase transaction. The rely just isn’t of the variety of transactions however relatively the variety of inputs. A transaction consists of inputs and outputs, not different transactions.

-> BE6D6DCAEEFE495F6BCA08E10FF6D24555166C2456D8129213354E32FD73EB1B141AB00100000000000000036507000F312D7B080100275C012F736C7573682F
– txin

No, that is nonetheless a part of the scriptSig. It itself just isn’t a transaction enter. That is simply arbitrary knowledge within the scriptSig of the coinbase transaction that miners put there.

00000000 – Lock Time

===== Coinbase Finish =====

000000002C6A4C2952534B424C4F434B3AA5BA6C5D1EFFA2034E994BEEE65C619DE2D2A1
– outpoint ?

B91892F193C170CAB74F152EAE0000000000000000266A24AA21A9ED85F7D06CCF8014D990E0242ACC0433EAF134732094E9A083A45AC3799259C9170000000001000000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33
– ?

No, there are three outputs however you may have solely decoded one among them.

The correct decoding is as follows:

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

There’s truly a subsequent a part of the transaction that you do not have in your breakdowt. It’s the witness knowledge and the locktime.

01 – One witness stack merchandise
20 – Stack merchandise is 32 bytes in size
0000000000000000000000000000000000000000000000000000000000000000 – Stack merchandise
00000000 – locktime

Then the following transaction begins with 01000000014FFBE86D2805AF78459BBF5FA3432A5E9C84D408F7921BF2095488B9DDC39D33... and is decoded just like the coinbase transaction above.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles