很多情况下,我们都需要对交易中的某一些rawtx进行解析,以便更加清楚的理解,其在交易过程中的一些详细信息,现在,详细罗列一下rawtx中每一个字节码究竟代表什么,建议一定要耐心阅读,可能有点恶心。
先来一段交易过程中的原始rawtx:
0100000001697f98c004bbb7d184119a31b2b8c96683fa8c7ca0d7755c6196888fb6ba046e010000006a473044022077de54191ae91b502d03a83bd1d580a8b4467fc3d205c7bce169f13e6abc1c91022064f759845c960b04ddf9dd5a635da5f8b990fc934fced06747d52f2658603735012103c426034f05b3b66700f151991e6e45f2d63545a73b36c0a8e8c4200c53f7fd2cfeffffff02a0f53813000000001976a914e85324d4402d9758122c5498de80d1cfcc6330cb88aca09f6636000000001976a914093f4c533deb449f6bd0a427bddb0f02c297101388ac5dad0700
这个是截取的块高度为
503134
,交易为27f5f35b447e219d0b3a3ac55f9dc6aacf2d4145fbd930207ef5b7710c47d883
的rawtx。
在了解如何解析之前,首先我们需要了解 tx 中都包含哪些字段,究竟有哪些格式:
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 | 一般为 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 | 一般为 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
比特币交易(P2PKH:对公钥哈希的付款)的解锁和锁定脚本的示例,显示了在脚本验证之前从解锁和锁定脚本的并置产生的组合脚本
PUB_KEY 格式:
- pubkey分为压缩和未压缩两种方式
- 公钥是在椭圆曲线上的一个点,由一对坐标(x,y)组成。
04 //代表未压缩公钥(02、03 代表压缩公钥)
025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8 //x
cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a //y
ok,对上述格式有一个简单的了解之后,我们来解析上述rawtx,看看它究竟为何方神圣。
======================================================
===================飙车 分割线==========================
======================================================
tx describes a bitcoin transaction, in reply to getdata
01000000 //[4字节] 的版本号(16进制,两位一个字节)
//[0或2字节] no flag( If present, always 0001, and indicates the presence of witness data)
01 //[1字节] tx_in count(01代表一个输入,可能有多个)
// tx_in array:
2ac424bf26875f2fa550b6df61a49564d510c6e8b535fd6f8870a0dc4b3711a301000000 //[36字节]的previous_output
8a //[1字节]的script length(16进制,8a=138 )
47304402205a2041854aba3d33ec92fae4894eb38c99aab1e6cfca619c08545f5eb757925902205f5593e104860a300df6c0d463744fed610a6bc914ee9959be467dae9b306623014104025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a
// [138字节]的signature script
ffffffff //[4字节]的sequence
02 //[1字节]的tx_out count,02代表有两个输出。
//tx_out array:
//第一个输出:
40420f0000000000 //[8字节]的Transaction Value(这里是小端,从后往前看(0f4240的十六进制转化为十进制,之后除以1亿,就是交易比特币的值。))
19 //[1字节]的pk_script length(代表pk_script长度是16进制的19(25字节))
76a914ae3b0aaf5e2ab94e0c8297fe055df443c69b4bdc88ac //pk_script(25字节)
//第二个输出:
fe130e9400000000 //[8字节]的 Transaction Value(2位在一起看(94 0e 13 fe))
19 //[1字节]的pk_script length
76a914bae025140c454518b8cba0c25d45a6dc87f4b9ce88ac //pk_script(25字节)
00000000 //[4字节]的lock_time
继续拆分signature script(一个签名,一个pubKey)
// [138字节]的signature script
47 //数据的长度。//47代表*******所包含的范围,是一个签名
******************
30 //表示DER序列的开始
44 //序列的长度(16进制,68字节)//44代表的是>>>>>所包含的范围
>>>>>>>>>>>>
02 //一个整数值
20 //整数的长度(32字节)
5a2041854aba3d33ec92fae4894eb38c99aab1e6cfca619c08545f5eb7579259 //R
02 //一个整数值
20 //整数的长度(32字节)
5f5593e104860a300df6c0d463744fed610a6bc914ee9959be467dae9b306623 //S
>>>>>>>>>>>>>
01 //签名hash类型(sighash)
*******************
41 //(16进制的65,有65个字节) 这个是pubKey的长度
04025a1cffe502a80dfa1f543ae14c082aff24d5ecadab160ca904d288eed8e3d8cacef0985f690868df4f416c3890909b4c0c843da153d41382ac20c80170240a
//65字节 未压缩公钥(pubKey)
继续拆分pk_script
//pk_script(25字节)
76 //OP_DUP
a9 //OP_HASH160
14 //(20字节的push数据)
ae3b0aaf5e2ab94e0c8297fe055df443c69b4bdc //20字节 data to push
88 //OP_EQUALVERIFY
ac //OP_CHECKSIG
P2SH MULTISIG (2 of 3)拆分
00 //00是当时候设计的一个bug,目前已经成为一种共识,只有当多重签名的时候,才会使用 00
//两个签名脚本
47 //OP_DATA_71
304402206a46d2803f9bc7bb59fd66a7e2eb19625bc7c897e0ab84d841179fdfdfb2ebbb02202949e64609827687fd9b2c7cbb3b706a34e67cdd3f6536c630dcac78a8eb6cf001
47
304402207946b95930ce13d96592a35b278df16ff6544083ab18dd3a7fb35a2cc118a88102203bcb33f08b3230cc0c42ac77050bcbdc4e3a5643b4c29986d844c6314e71614c01
4c //操作码--> OP_PUSHDATA1
69 //105字节 代表>>>所包含的内容
>>>>>
52
21028bb6ee1127a620219c4f6fb22067536649d439929e177ebfe76386dff52a7084
2102f9cd8728b12b6c8a17a15cb4a19de000641f78a449c1b619dc271b84643ce0e9
2103d33aef1ae9ecfcfa0935a8e34bb4a285cfaad1be800fc38f9fc869043c1cbee2
53 //代表有3个公钥
ae //代表脚本OP_XXX(OP_CHECKMULTISIG 校验多重签名是否正确)
>>>>>>
本文由
Copernicus 团队 冉小龙
总结,转载无需授权。