Topics in digital currency development (algorithms and protocols used in development)

Blockchain Enthusiast (qq:53016353)

The blockchain technology used in digital currencies is already well known in China, but technical research has not been carried out effectively, and most people are aware and aware of the extent to which many people in the Bitcoin circle can do so much in the digital currency. One important reason is that most of the core data of digital money is in English, and few people can read such a complicated English material.        The research direction of my doctoral dissertation is digital currency, while studying its English technology, it intends to translate some important information, so that more people in the circle have more understanding of the digital currency. This paper deals with the digital currency protocol, including hash, Merkle tree generation, signature, transaction verification, address and other general standards, including general data structure, including message, variable length integer, variable length string, network address, inventory vector, block size and so on. The data structure and usage scenarios of more than 20 digital currency messages are also described in detail, which is a good reference for digital currency protocol.
Body
1 General standards
1.1 Hashs (hash)
Typically, the bitcoin is calculated 2 times when the hash is computed. In most cases, using the SHA-256 hash, RIPEMD-160 is used to generate a shorter hash (for example, when generating a digital currency address).
Example of a two--sha-256 hash of the string "Hello":
Hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (First round sha-256)
9595C9DF90075148EB06860365DF33584B75BFF782A510C6CD4883A419833D50 (Second round sha-256)
When you generate a digital currency address (RIPEMD-160), you get:
Hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (First round using sha-256)
B6A9C8C230722B7C748331A8B450F05566DC7D0F (second round using ripemd-160)
1.2 Merkle Trees (Merkle tree)
The Merkle tree is a hash of a two-fork tree. In bitcoin use two times SHA-256 algorithm to generate Merkle tree, if the number of leaves is odd, then the last leaf to be repeated two times SHA-256 embodied, in order to achieve the requirements of even leaf nodes:
The calculation process: first, according to the HASH256 value of the transaction in the chunk, and then according to the size of the hash value, generate the lowest level, the second layer of each element is a continuous two hash value of two hash value; Repeat this process until there is only one hash value in a layer, this is Merkle root. For example: Imagine there are 3 trades, a,b,c, and the resulting process is as follows:
D1 = Dhash (a)
D2 = Dhash (b)
D3 = Dhash (c)
D4 = Dhash (c) # There are only 3 elements, which are odd, so the last element is re-calculated once

(The translator presses, according to the above instructions, to here should have the sort, may omit, waits to confirm)

d5 = Dhash (D1 concat D2)
d6 = Dhash (D3 concat D4)

D7 = Dhash (d5 concat d6)
Here Dhash (a) = SHA256 (sha256 (a))
D7 is the root of the above three trades Merkle.
Note: The hash value of the Merkle tree displayed in the Chunk browser is the small bit sequence (the translator presses: that is, a number is represented in the computer after the high position). For some implementations and calculations, the hash should be reversed before hashing, and then reversed once after the hash calculation.
1.3 Signatures (signature)
The bitcoin uses an Elliptic Curve Digital Signature Algorithm (ECDSA) to sign trades.
ECDSA
Use the SECP256K1 curve in Http://www.secg.org/collateral/sec2_final.pdf.
Public key (in script) with 04
In the form given, where x and Y are 32 bytes of a large head-ordinal integer representing the point coordinates of the above curve, or in the form of compression, if Y is an even number is 0x02, if Y is odd is 0x03.
The signature uses DER encoding to write R and s into a byte stream (because this is the default output of OpenSSL).
1.4 Transaction Verification (transaction certification)
A transaction is a cryptographic signature used to record the ownership of a digital currency from one address to another. The transaction has input (i.e. the cost of the previously traded output funds) and the output (used to define the new owner of the digital currency, which can be referred to as input for future transactions).
Each input must have a cryptographic digital signature to unlock the funds from the previous transaction. Only the person with the right private key can create a legitimate signature, which guarantees that the money can only be spent by the owner.
Each output defines which address (or other criteria, see the "Digital currency script" article) is the recipient of the funds.
In a transaction, the sum of all the inputs must be equal to or greater than the sum of all the outputs, and if the input exceeds the output, the excess is the transfer fee, and whoever digs into the block containing the transaction will be the cost. A relatively special trade, called the Coinbase transaction, is created by miners without any input. Each chunk comes with a newly created digital currency return (for example: in the first 210,000 chunks, each block contains 50 digital currencies). The first trade in each chunk is a Coinbase transaction with few exceptions. Coinbase Trading allows these digital currencies to be owned by their recipients (miners) and is also used to indicate the recipient of the transaction fees for other transactions in this block, Coinbase transactions can be specified as a digital currency address or, as with other transactions, to be received by multiple addresses. The amount of output included in the Coinbase transaction is equal to the mining return per chunk plus all transaction costs in this block.
The NO. 0 block of Coinbase transactions can not be spent, which may be a coincidence of the client implementation (translator by: or Nakamoto deliberately, see the translation of the "digital currency block chain and mining principle," translated), if some nodes accept the transaction, and some nodes do not accept, it is possible to produce bifurcation.
Most digital currency outputs require a ECDSA private key to redeem the transmitted digital currency, and the actual storage input and output records are not private keys, but scripts. The digital currency uses an explanatory scripting system to define whether the output standard is satisfied, and with this scripting system, it can create more complex operations. For example, you need two ECDSA signed output, or 2-of-3 multi-signature scenario. The output of a digital currency address is a typical output, which actually contains the information that requires a single ECDSA signature (see OP_CHECKSIG) in script form. In order to unlock funds in the future, an output script must be provided, which must meet the requirements of the original output script when the transaction is to be spent in the input of another transaction.

1.5 Addresses (address)
The digital currency address is the hash of the ECDSA public key, which is calculated as follows:
Version = 1 bytes (0); On the test network, this value is 1 bytes (111)
Key hash = Version with RIPEMD-160 (SHA-256 (public key))
Checksum = First 4 bytes of SHA-256 (SHA-256 (Key hash))
Digital currency address = Base58encode (Key hash and Checksum phase)
BASE58 encoding is written specifically, and there are some differences (as with generic versions). In particular, all bytes leading to 0 are converted to a single 0.
2 General structure
Most integers use the small-endian encoding, and only the IP address or port number is encoded using the large-head bit sequence.
2.1 Message (Messages)
Field Dimensions
Describe
Data type
' Description
4
Magic
uint32_t
The source network used to identify the message, which is also used to look for the next message when it is in a stream state position
12
Command
CHAR[12]
An ASCII string that identifies the contents of the package, fills with a null character, and is rejected (using a non-null character population)
4
Length
uint32_t
Number of bytes in payload
4
Checksum
uint32_t
SHA256 (sha256 (payload))
The first 4 bytes (not included in version or
In Verack)
?
Payload
Uchar[]
Actual data
Version and Verack messages do not contain a starting position of Checksum,payload 4 bytes in advance
Defined Magic values:
Internet
Magic value
Send Form
Main
0xd9b4bef9
F9 be B4 D9
Testnet
0xdab5bffa
FA BF B5 DA
Testnet3
0x0709110b
0B 11 09 07
Namecoin
0xfeb4bef9
F9 be B4 FE
2.2 Variable length Integer (variable-length integers)
Integers can be encoded according to the value of the expression to save space. Variable-length integers are always preceded by an array/vector of variable-size data types. Longer numbers are encoded in the small bit sequence.
Value
Storage length
Format
<
0xfd
1
uint8_t
<=
0xFFFF
3
0xfd +
uint16_t
<=
0xFFFFFFFF
5
0xFE +
uint32_t
-
9
0xFF +
uint64_t
In the Nakamoto digital currency client code (BITCOIN-QT) refers to "compactsize", modern BITCOIN-QT also has cvarint class, more compressed than compactsize (but not compatible with compactsize), The Cvarint class is not part of the agreement.
2.3 Variable length string (variable length strings)
Variable-length strings consist of a variable-length integer and a string.
Field Dimensions
Describe
Data type
Description
?
Length
Var_int
String length
?
String
Char[]
The string itself (can be empty)
2.4 Network Address
This structure is used when a network address is required. This protocol and data structure supports IPV6, but it is important to note that the current official client only supports the IPV4 network, and the network address in the version message does not start with a timestamp.
Field Dimensions
Describe
Data type
Description
4
Time
UInt32
Time (version
>= 31402)
8
Services
uint64_t
The same data type as the version message
16
Ipv6/4
CHAR[16]
The IPV6 address of the network byte order, the original client only supports IPV4, only reads the maximum 4 bytes, obtains the IPV4 address. But the IPV4 address is a 16-byte long ipv4-map in this message.
IPV6 Address
(00 bytes
The next 4 bytes of the IPV4 address are followed by the FF ff of the xx xx.
2
Port
uint16_t
Port Address
A hexadecimal example of a network address structure


0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ......
0010 to FF FF 0A (8D ......)

Network Address:
00-1 (node_network: See the list of services for version command)
XX, XX, and the FF FF 0A 01-ipv6::: ffff:10.0.0.1 or ipv4:10.0.0.1
8D-Port 8333
2.5 Inventory Vectors (list vector)
The manifest vector is used to inform other nodes of the objects owned by the node or the requested data, which are composed of the following data formats
Field Dimensions
Describe
Data type
Description
4
Type
uint32_t
Object Type identification
32
Hash
CHAR[32]
Object Hash Value
The current object type ID has the following 3 values defined


Value
Name
Description
0
ERROR
Data can be ignored
1
Msg_tx
The hash is about the transaction.
2
Msg_block
The hash is about the data block
Other data type values are reserved for future implementations
2.6 Block Headers (block head)
In response to the getheaders message, the chunk header is placed in a packet and sent.
Field Dimensions
Describe
Data type
Description
4
Version
uint32_t
Block version information, based on the software version that created the block
32