A Beginner's Guide to Bitcoin Blockchain Development (Part 3)

This article uses the Bitcoin test network (bitcoin-testnet) as a development test environment, analyzes the data structure of Bitcoin transactions (Transaction), and uses Node.js as an example to illustrate how to organize specific transaction data by yourself, sign it, and broadcast it, which will eventually be confirmed and effective by the miner node.

1. Understand the Bitcoin "Transaction" data structure

Transaction is the information carrier and the smallest unit of the Bitcoin system. Block is to pack several such basic units of "transaction" into boxes and affix seals. Then, these blocks are connected in series according to a certain mechanism and sequence to form a blockchain.

For application development based on Bitcoin blockchain, "Transaction" is the most directly used and most critical data structure. In addition to "Transaction", you also need to master the meaning of some basic terms related to Bitcoin block volume, including wallet private key, public key and address, block, blockchain, etc. There are many books and online materials that have relatively clear descriptions. Here I recommend you to read this online book "Mastering Bitcoin" (http://zhibimo.com/read/wang-miao/mastering-bitcoin/index.html).

Here we focus on an in-depth analysis and understanding of the data structure of "Transaction".

A Bitcoin transaction is a data structure containing input and output values, which contains code information for transferring funds from an initial point (input value) to a target address (output value). A Bitcoin transaction contains some fields, as shown in the following table.

Size Field Name Data Type Description
4-byte protocol version uint32_t specifies the version number of the rule protocol that this transaction refers to
1-9 bytes Input quantity var_int The number of input transactions included is indefinite Input list tx_in[] An array of one or more input transactions
1-9 bytes Output number var_int The number of output transactions included is indefinite Output list tx_out[] An array of one or more output transactions
4-byte lock time uint32_t A UNIX timestamp or block number

Note: The locktime field defines the earliest transaction time that can be added to the blockchain. In most transactions, it is set to 0 by default, which is used to indicate immediate execution. If the locktime is greater than 0 and less than 500 million, it is treated as a block height, meaning that the transaction is not included in the blockchain before this specified block height. If the locktime is greater than 500 million, it is treated as a Unix epoch timestamp (the number of seconds since January 1, 1970), and the transaction will not be included in the blockchain before this specified point in time. The use of locktime is equivalent to delaying the validity time of a paper check.

Application development based on blockchain technology is actually mainly about working on the output data structure of transactions to carry specific business logic. For example, the ODIN open source project embeds identification attribute data into Bitcoin's multiple transaction output data blocks in a certain format.

2. Example Analysis of Transaction Records

The following is an example of the raw data of a Bitcoin transaction (the raw binary data is output as hexadecimal ASCII code by byte for easy analysis):

0100000002eb2121e4e727bdb28525e79d39a90bd711b9e8413c054b29ffc4bb4775e69f82010000006b483045022100df82
cf6c95b4eb64e4e9cee3af88a94c65fa81650e824d515f089192b7e3c09c0220119c1fcfd9354755ea815cf714c181b56784
b8f98f59f33e977c8939cd6f75db0121022e9f31292873eee495ca9744fc410343ff373622cca60d3a4c926e58716114b9ff
ffffffc9f3b07ebfca68fd1a6339d0808fbb013c90c6095fc93901ea77410103489ab7010000008a47304402206b993231ad
ec55e6085e75f7dc5ca6c19e42e744cd60abaff957b1c352b3ef9a022022a22fec37dfa2c646c78d9a0753d56cb4393e8d0b
22dc580ef1aa6cccef208d0141042ff65bd6b3ef04253225405ccc3ab2dd926ff2ee48aac210819698440f35d785ec3cec92
a51330eb0c76cf49e9e474fb9159ab41653a9c1725c031449d31026affffffff031027000000000000475121022e9f312928
73eee495ca9744fc410343ff373622cca60d3a4c926e58716114b9210250504b2d42455441506565722d506565722d6e6574
776f726b207075626c696352aee07b9a3b000000001976a914391ef5239da2a3904cda1fd995fb7c4377487ea988ac000000
00000000000d6a0b436f6465206973204c617700000000

The above message can be decomposed into fields according to the protocol rules as follows:

01000000 // Version number, UINT32

02 // Number of Tx inputs, variable length INT. 0×02 = 2 inputs.

/*** Next is the first group of Input Tx ***/
eb2121e4e727bdb28525e79d39a90bd711b9e8413c054b29ffc4bb4775e69f82 // Hash value of Tx transaction, fixed at 32 bytes
01000000 // The consumed Tx is located at the 0th forward transaction output, UINT32, fixed 4 bytes
6b // Next is the length of the corresponding signature data, 0x6b = 107 bytes.
// This 107-byte signature contains two parts: private key signature + public key.
// When the value here is 00, it means the original transaction has not been signed yet
48 // The data length corresponding to the private key signature, 0×48 = 72 bytes

3045022100df82cf6c95b4eb64e4e9cee3af88a94c65fa81650e824d515f089192b7e3c09c022011
9c1fcfd9354755ea815cf714c181b56784b8f98f59f33e977c8939cd6f75db01 //Private key signature content

21 // Corresponding public key data length, 0×21 = 33 bytes
022e9f31292873eee495ca9744fc410343ff373622cca60d3a4c926e58716114b9 //Corresponding public key data
ffffffff // Serial number, UINT32, fixed 4 bytes. This field is a transaction replacement function that is currently not used, and is set to 0xFFFFFFFF by default

/*** The second group of Input Tx. Same as above, omitting the decomposition***/

c9f3b07ebfca68fd1a6339d0808fbb013c90c6095fc93901ea77410103489ab7010000008a473044
02206b993231adec55e6085e75f7dc5ca6c19e42e744cd60abaff957b1c352b3ef9a022022a22fec
37dfa2c646c78d9a0753d56cb4393e8d0b22dc580ef1aa6cccef208d0141042ff65bd6b3ef042532
25405ccc3ab2dd926ff2ee48aac210819698440f35d785ec3cec92a51330eb0c76cf49e9e474fb91
59ab41653a9c1725c031449d31026affffffff

03 // Tx output transaction quantity, variable length INT type. 0×03=3 inputs.

/*** The first group of output ***/
1027000000000000 //Amount of bitcoins output, UINT64, 8 bytes. The byte order needs to be flipped to get 0×0000000000002710 = 10000 satoshi = 0.0001 BTC
47 // Output description script byte count, 0×47 = 71 bytes, consisting of some opcodes and values
51 //Ox51 represents OP_1 (push script code 1 into the stack)
21 //The data length of the first public key pushed into the stack, 0×21 = 33 bytes
022e9f31292873eee495ca9744fc410343ff373622cca60d3a4c926e58716114b9
21 //The data length of the second public key pushed into the stack, 0×21 = 33 bytes
0250504b2d42455441506565722d506565722d6e6574776f726b207075626c6963
52 //Ox52 represents OP_2 (push script code 2 onto the stack). Together with the previous 0×51, it represents 1of2 multi-signature
ae //Oxae represents OP_CHECKMULTISIG (perform multi-signature verification)

/*** The second group of output ***/
e07b9a3b00000000 //Amount of bitcoins output, UINT64, 8 bytes. The byte order needs to be flipped.
19 // Output description script byte count, 0×19 = 25 bytes, consisting of some operation codes and values
76 //Script start operation 0×76 represents OP_DUP (copy the top element of the stack)
a9 //Address type 0xa9 represents OP_HASH160 (the top item of the stack is hashed twice, first with SHA-256 and then with RIPEMD-160)
14 //Address length 0×14 = 20 bytes
391ef5239da2a3904cda1fd995fb7c4377487ea9 // Corresponding HASH160 value, 20 bytes
88 //0×88 represents OP_EQUALVERIFY (run the script's binary arithmetic and condition, if the result is 0, then run OP_VERIFY)
ac //Oxac stands for OP_CHECKSIG (the signature used in the transaction must be a valid signature of the hash value and public key, if true, it returns 1)
/*** The third group of output ***/
0000000000000000 //Amount of bitcoins output, UINT64, 8 bytes. Because it is for adding remarks, not a normal transfer transaction, the output amount is 0
0d // Output description script byte count, 0x0d = 13 bytes, consisting of some opcodes and values
6a //0x6a represents OP_RETURN (marking the transaction invalid), indicating that the transaction is just an additional note, not a normal transfer transaction
0b //Remark content length, 0x0b = 11 bytes
436f6465206973204c6177 //Remark data content (represent the original binary data in hexadecimal ASCII code)

00000000 // Lock time, UINT32, fixed 4 bytes

Through the above analysis, after understanding and mastering the common organizational format of Bitcoin transaction records, you can make full use of the data content blocks corresponding to the blue font part to embed some customized binary data content, and then develop and implement your own specific business logic.

3. Run the sample program

The following sample program embeds a string of specific content into the remark data block of a Bitcoin transaction in a certain format, so that it can be stored on the Bitcoin blockchain.

Before running the following sample program, please make sure that the Docker runtime environment of the Bitcoin test network (bitcoin-testnet) has been installed. If it has not been installed, you can refer to the instructions in the previous article "Bitcoin Blockchain Development from Beginner to Advanced Guide 2" to install it (http://www.8btc.com/ppkpub_blockchain_develope_lesson_2).

Copy and save the following sample code to the test environment of the bitcoin test network (bitcoin-testnet) (save the file name as OpreturnTestnet.js), and enter the following command in the command line to run and see the running results:
node OpreturnTestnet.js

Note: Each time you run the test code, you need to enter "make generate BLOCKS=10" in the command line of the Docker runtime environment to simulate the generation of new block records so that the transaction records generated by the test code can be effectively confirmed.

The source code of the sample program OpreturnTestnet.js is as follows:

/********************* Starting point of sample code*************************/