Quote from: icehouse on April 11, 2018, 04:01:40 PM

if blockchain explorer doesn't show all transaction info, then what exactly a transaction looks like?

Thanks

Quote from: DannyHamilton on December 04, 2017, 04:12:54 PM

Quote from: jacko27 on December 04, 2017, 07:50:55 AM

When I decode a transaction here https://blockchain.info/decode-tx

For example,

https://blockchain.info/tx/9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0?format=hex

0100000002d8c8df6a6fdd2addaf589a83d860f18b44872d13ee6ec3526b2b470d42a96d4d00000 0008b483045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc 8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba014104c54 f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da92290 2a4454841aa1754c1b6292ad7d317150308d8cce0ad7abffffffff2ab3fa4f68a512266134085d3 260b94d3b6cfd351450cff021c045a69ba120b2000000008b4830450220230110bc99ef311f1f8b da9d0d968bfe5dfa4af171adbef9ef71678d658823bf022100f956d4fcfa0995a578d84e7e913f9 bb1cf5b5be1440bcede07bce9cd5b38115d014104c6ec27cffce0823c3fecb162dbd576c88dd7cd a0b7b32b0961188a392b488c94ca174d833ee6a9b71c0996620ae71e799fc7c77901db147fa7d97 732e49c8226ffffffff02c0175302000000001976a914a3d89c53bb956f08917b44d113c6b2bcbe 0c29b788acc01c3d09000000001976a91408338e1d5e26db3fce21b011795b1c3c8a5a5d0788ac0 0000000

But when I try any hex decoder online, I get gibberish.

Isnt the raw hex transaction in hexadecimal? If so, how do you encode / decode other than the blockchain decoder?

As HCP has indicated...

It is NOT hex encoded ASCII. You can't just convert the hex values into ASCII character representations and expect to get anything useful out of it.

It is hex encoded binary data.

If you are aware that a single BYTE of data is represented with 2 hex characters, and you know how to convert from hexadecimal to decimal, then we can walk through that transaction you posted together to see exactly what is happening. Follow along...

The first 4 bytes (8 characters) are ALWAYS a transaction version number. In this case that is:

Code:

01000000

Note that bitcoin uses "little-endian" byte order, so converting those bytes to the format in which you might commonly see a hexadecimal number written we get 0x00000001. Converting that to decimal we see that this is a version 1 transaction type.

The next byte indicates the number of inputs in the transaction. In this case that is:

Code:

02

As a hexidecimal number that would be commonly be written as 0x02. Converting that to decimal we see that there are exactly 2 inputs in this transaction.

The next thing in the transaction is the inputs. Each input consists of:

Transaction ID of the output being spent
Offset of the output in that transaction
Script length
Txin-script (Also known as: scriptSig)
sequence_no

So, we should have 2 sets of that information.

A bitcoin transaction ID is a 256 bit hash, so it is 32 bytes long. Therefore the next 32 bytes should be the transaction ID from the first input...

Code:

d8c8df6a6fdd2addaf589a83d860f18b44872d13ee6ec3526b2b470d42a96d4d

Remember that bitcoin uses little-endian byte order. Typically when transaction IDs are shown to humans they are placed in big-endian byte order, so we'll need to reverse the order of these bytes to see the transaction ID in the format that most people are generally familiar with...

Code:

4d6da9420d472b6b52c36eee132d87448bf160d8839a58afdd2add6f6adfc8d8

Next is the index into that transaction of the output that is being spent as an input in this transaction. This is a 4 byte value.

Code:

00000000

Looks like the index value is 0

Following that we have the a value that indicates how long (in bytes) the script is:

Code:

8b

Converting the value 0x8b from hex to decimal we see that the script will be the next 139 bytes.

Next we have the Txin-script of the first input:

Code:

483045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba014104c54f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da922902a4454841aa1754c1b6292ad7d317150308d8cce0ad7ab

If we want to analyze that script, we can break it into its component parts...

The first byte we see is:

Code:

48

Looking at the bitcoin scripting language, we see that this is an indication to push that quantity of the following bytes onto the script processing stack. Since 0x48 is 72 in decimal, the next 72 bytes will be pushed to the processing stack. In the case of the typical P2PKH address, this will end up being the digital signature. As such, we can see that the signature is represented in the transaction as:

Code:

3045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba01

The next byte we see is:

Code:

41

Looking at the bitcoin scripting language, we see that this is an indication to push that quantity of the following bytes onto the script processing stack. Since 0x41 is 65 in decimal the next 65 bytes will be pushed to the processing stack. In the case of the typical P2PKH address, this will end up being the public key. As such, we can see that the public key is represented in the transaction as:

Code:

04c54f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da922902a4454841aa1754c1b6292ad7d317150308d8cce0ad7ab

We've now reached the end of the Txin-script details. Next comes the sequence_number which is always 4 bytes:

Code:

ffffffff

That's the end of the first input. The next byte therefore starts the next input...

Inputs start with a A bitcoin transaction ID. A transaction ID is a 256 bit hash, so it is 32 bytes long. Therefore the next 32 bytes should be the transaction ID from the second input...

Code:

2ab3fa4f68a512266134085d3 260b94d3b6cfd351450cff021c045a69ba120b2

Remember that bitcoin uses little-endian byte order. Typically when transaction IDs are shown to humans they are placed in big-endian byte order, so we'll need to reverse the order of these bytes to see the transaction ID in the format that most people are generally familiar with...

Code:

b220a19ba645c021f0cf501435fd6c3b4db960325d0834612612a5684ffab32a

Next is the index into that transaction of the output that is being spent as an input in this transaction. This is a 4 byte value.

Code:

00000000

Looks like the index value is 0

Following that we have the a value that indicates how long (in bytes) the script is:

Code:

8b

Converting the value 0x8b from hex to decimal we see that the script will be the next 139 bytes.

Next we have the Txin-script of the second input:

Code:

4830450220230110bc99ef311f1f8bda9d0d968bfe5dfa4af171adbef9ef71678d658823bf022100f956d4fcfa0995a578d84e7e913f9bb1cf5b5be1440bcede07bce9cd5b38115d014104c6ec27cffce0823c3fecb162dbd576c88dd7cda0b7b32b0961188a392b488c94ca174d833ee6a9b71c0996620ae71e799fc7c77901db147fa7d97732e49c8226

You can walk through the steps from the first Txin-script if you want to break this one apart, I'm not going to repeat that here.

Next comes the sequence_number which is always 4 bytes:

Code:

ffffffff

We've now reached the end of both inputs. The next part of the transaction is the outputs...

The next byte is an indication of the number of outputs in the transaction:

Code:

02

Converting this from hex to decimal, we see there will be 2 outputs.

Each output consists of:

A value
Script length
A Txout-script (Also known as scriptPubKey)

The value is always 8 bytes. So the next 8 bytes is the value of the first output:

Code:

c017530200000000

Converting this to big-endian byte order we get:

Code:

00000000025317c0

Converting 0x025317c0 to decimal we see that the value of the first output is 39000000 satoshi (or 0.39 BTC).

Next comes a value indicating how many bytes long the Txout-script is.

The next byte is:

Code:

19

Indicating that the script is 0x19 (which is decimal is 25) bytes long.

Code:

76a914a3d89c53bb956f08917b44d113c6b2bcbe0c29b788ac

We can break this script into its components if we like. The first byte we see in the script is:

Code:

76

Looking at the bitcoin scripting language, we see that this is the OP_DUP code.

Next we see:

Code:

a9

We can see that this is the OP_HASH160 code.

Next we see:

Code:

14

We can see in the scripting language that this is an indication to push that many bytes onto the processing stack. Converting the hex 0x14 to a decimal value we see that we need to push the next 20 bytes to the stack.

That would be these 20 bytes:

Code:

a3d89c53bb956f08917b44d113c6b2bcbe0c29b7

Notice that is the 160 bit (20 byte) RIPEMD160 hash value that the bitcoin address is built from.

The next byte is:

Code:

88

We can see that this is the OP_EQUALVERIFY code.

Finally at the end of the script we see:

Code:

ac

We can see that this is the OP_CHECKSIG code.

So, the 25 byte output script of this transaction is:

Code:

OP_DUP OP_HASH160 OP_Push20Bytes (20 byte hash) OP_EQUALVERIFY OP_CHECKSIG

That's the end of the first output. The next byte therefore starts the next output...

As we saw earlier, the first thing in an output is an 8 byte value.

Code:

c01c3d0900000000

Converting this to big-endian byte order we get:

Code:

00000000093d1cc0

Converting 0x093d1cc0 to decimal we see that the value of the first output is 155000000 satoshi (or 1.55 BTC).

Next comes a value indicating how many bytes long the Txout-script is.

The next byte is:

Code:

19

Indicating that the script is 0x19 (which is decimal is 25) bytes long.

Code:

76a91408338e1d5e26db3fce21b011795b1c3c8a5a5d0788ac

You can walk through the steps from the first Txout-script if you want to break this one apart, I'm not going to repeat that here.

Once we get past all the outputs, the only thing left in the transaction is a 4 byte lock_time. As we can see from your transaction:

Code:

00000000

The lock time is 0.

That's it. That's the entire transaction decoded. Hope this was helpful