BTC transaction rawtx analysis
In many cases, we need to analyze some rawtx in the transaction in order to make a clearer understanding. Some detailed information in the transaction process, now, list in detail what the byte code in RAWTX represents what represents the representation of RAWTX. It is recommended to read patiently, which may be a little disgusting.
First of the original rawtx in the transaction process:
0100000001697f98c004bbb7d184119a31b2b8c96683fa8c7ca0d7755c6196888fb6ba046e010000006a473044022077de54191ae91b502d03a83bd1d580a8b4467fc3d205c7bce169f13e6abc1c91022064f759845c960b04ddf9dd5a635da5f8b990fc934fced06747d52f2658603735012103c426034f05b3b66700f151991e6e45f2d63545a73b36c0a8e8c4200c53f7fd2cfeffffff02a0f53813000000001976a914e85324d4402d9758122c5498de80d1cfcc6330cb88aca09f6636000000001976a914093f4c533deb449f6bd0a427bddb0f02c297101388ac5dad0700
This is the intercepting block height
503134, transaction is27f5f35b447e219d0b3a3ac55f9dc6aacf2d4145fbd930207ef5b7710c47d883Rawtx.
Before understanding how to analyze, first of all, we need to understand which fields contain in TX and what formats are there:
tx
| field size | description | data type | comments |
|---|---|---|---|
| 4 | version | int32_t | Transaction data format version (note, this is signed) |
| 0 or 2 | flag | optional uint8_t[2] | If present, always 0001, and indicates the presence of witness data |
| 1+ | tx_in count | var_int | Number of Transaction inputs (never zero) |
| 41+ | tx_in | tx_in[] | A list of 1 or more transaction inputs or sources for coins |
| 9+ | tx_out count | var_int | Number of Transaction outputs |
| 41+ | tx_out | tx_out[] | A list of 1 or more transaction outputs or destinations for coins |
| 0+ | tx_witnesses | tx_witness[] | A list of witnesses, one for each input; omitted if flag is omitted above |
| 4 | lock_time | uint32_t | Generally 00000000 |
TxIn consists of the following fields:
| field size | description | data type | comments |
|---|---|---|---|
| 36 | previous_output | outpoint | The previous output transaction reference, as an OutPoint structure |
| 1+ | script length | var_int | The length of the signature script |
| ? | signature script | uchar[] | Computational Script for confirming transaction authorization |
| 4 | sequence | uint32_t | Generally FFFFFFFF |
The OutPoint structure consists of the following fields:
| field size | description | data type | comments |
|---|---|---|---|
| 32 | hash | char[32] | The hash of the referenced transaction. |
| 4 | index | uint32_t | The index of the specific output in the transaction. The first output is 0, etc. |
The TxOut structure consists of the following fields:
| field size | description | data type | comments |
|---|---|---|---|
| 8 | value | int64_t | Ttransaction value. |
| 1+ | pk_script length | var_int | Length of the pk_script |
| ? | pk_script | uchar[] | Usually contains the public key as a Bitcoin script setting up conditions to claim this output. |
Standard Transaction to Bitcoin address (pay-to-pubkey-hash)
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
76 A9 14
OP_DUP OP_HASH160 Bytes to push
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG
Bitcoin transactions (P2PKH: Payment of Public Key Hash) unlocking and locking script example shows the combined script generated by the coexistence of the coexistence of the script before the script verification
Signature+PUBKEY
PUB_KEY format:
- PUBKEY is divided into two ways: compression and unprepressed
The
- public key is a point on the oval curve, consisting of a pair of coordinates (x, y).
04 // Represents the unwavering public key (02, 03 represents the compression public key)
025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8 //x
cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a //y
OK, after a simple understanding of the above format, let’s analyze the above RAWTX to see why it is sacred.
======================================================
===========================================
======================================================
tx describes a bitcoin transaction, in reply to getdata
- tx byte interpretation link
- The meaning of each script (script wiki)
- signature script specific meaning
- Public key to split format
- BIP Coinbase New Specification (141)
01000000 // [4 bytes] version number (hexadecimal, two -bit by byte)
// [0 or 2 bytes] No Flag (if present, always 0001, and indicates the presence of Witness Data)
01 // [1 byte] tx_in count (01 represents an input, there may be multiple)
// tx_in array:
2ac424bf26875f2fa550b6df61a49564d510c6e8b535fd6f8870a0dc4b3711a301000000 // [36 bytes] of previous_output
8a // [1 byte] Script Length (hexadecimal, 8A = 138)
47304402205a2041854aba3d33ec92fae4894eb38c99aab1e6cfca619c08545f5eb757925902205f5593e104860a300df6c0d463744fed610a6bc914ee9959be467dae9b306623014104025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a
// [138 bytes] Signature script
ffffffff // [4 byte] Sequence
02 // [1 byte] TX_OUT Count, 02 represents two outputs.
//tx_out array:
// The first output:
40420f0000000000 // [8 bytes] Transaction Value (here is a small end, looking forward (0F4240's hexadecimal transformation to decimal, except for 100 million, the value of the trading Bitcoin.))
19 // [1 byte] PK_Script Length
76a914ae3b0aaf5e2ab94e0c8297fe055df443c69b4bdc88ac // pk_script (25 bytes)
// The second output:
fe130e9400000000 // [8 byte] transaction value
19 // [1 byte] pk_script length
76a914bae025140c454518b8cba0c25d45a6dc87f4b9ce88ac // pk_script (25 bytes)
00000000 // [4 byte] lock_time
Continue to split signature script (a signature, a pubkey)
// [138 bytes] Signature script
47 // The length of the data. // 47 The range contained in ******* is a signature
******************
30 // represents the beginning of the der sequence
44 // The length of the sequence (hexades, 68 bytes) // 44 represents the range
>>>>>>>>>>>>
02 // A integer value
20 // The length of the integer (32 bytes)
5a2041854aba3d33ec92fae4894eb38c99aab1e6cfca619c08545f5eb7579259 //R
02 // A integer value
20 // The length of the integer (32 bytes)
5f5593e104860a300df6c0d463744fed610a6bc914ee9959be467dae9b306623 //S
>>>>>>>>>>>>>
01 // Signature Hash Type (Sighash)
*******************
41 // (165, 65 bytes) This is the length of the PUBKEY
04025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a
// 65 bytes without compressing public key (PUBKEY)
Continue to split pk_script
// pk_script (25 bytes)
76 //OP_DUP
a9 //OP_HASH160
14 // (20 bytes of Push data)
ae3b0aaf5e2ab94e0c8297fe055df443c69b4bdc // 20 byte Data to Push
88 //OP_EQUALVERIFY
ac //OP_CHECKSIG
P2SH Multisig (2 of 3) Demolition
00 // 00 was a bug designed at that time. It has become a consensus. Only when multiple signatures are signed, 00
// Two signature scripts
47 //OP_DATA_71
304402206a46d2803f9bc7bb59fd66a7e2eb19625bc7c897e0ab84d841179fdfdfb2ebbb02202949e64609827687fd9b2c7cbb3b706a34e67cdd3f6536c630dcac78a8eb6cf001
47
304402207946b95930ce13d96592a35b278df16ff6544083ab18dd3a7fb35a2cc118a88102203bcb33f08b3230cc0c42ac77050bcbdc4e3a5643b4c29986d844c6314e71614c01
4c // Operation code-> OP_PUSHDATA1
69 // 105 byte representative >>> content contained in
>>>>>
52
21028bb6ee1127a620219c4f6fb22067536649d439929e177ebfe76386dff52a7084
2102f9cd8728b12b6c8a17a15cb4a19de000641f78a449c1b619dc271b84643ce0e9
2103d33aef1ae9ecfcfa0935a8e34bb4a285cfaad1be800fc38f9fc869043c1cbee2
53 // Represents 3 public keys
ae // Represents the script OP_XXX (OP_CHECKMULTISIG checks whether multiple signatures are correct)
>>>>>>