Investigating and analyzing bitcoin blockchain protocol using wireshark

Published Online July 2018 in MECS

• I.    Introduction

  In recent years, there has been an immense growth of e-commerce across the world. Most of the internet transaction mediating systems like PayPal rely on the trusted third-Party mediators - banking institutions. These trusted third-party mediators are responsible for verification and authentication of e-transactions and thus provide a sense of assured security to its users. Unfortunately, all of these trusted third-party mediators have one severe disadvantage of having "Central Point of Failure". To overcome shortcomings of trusted third-party mediators, a concept of Bitcoin: A Peer to Peer ecash was proposed by Satoshi Nakamoto in 2008 [1].

Bitcoin has revolutionized the whole financial transaction system, by introducing the very first fully decentralized digital currency, that is both secure and stable. Bitcoin can be defined in various ways; it’s a protocol, a digital currency, and a platform. It is a combination of peer-to-peer network, protocols, and software that facilitates the process of creation and control of the digital currency.

The bitcoin network is a P2P network [2] where nodes exchange transactions and blocks. Wireshark can be used to visualize these transactions and blocks and thus can serve as an invaluable tool to get deep insight of the Bitcoin protocol. In this paper we capture the Bitcoin packets to deeply investigate and analyze them. We investigate how bitcoin transactions and block messages work, and what values and parameters are considered during this whole process.

The rest of the paper is organized as follows: In section II, the Bitcoin blockchain protocol is explained. In section III, basic setup methodology for experimentation is presented. In section IV, the bitcoin packets are investigated using Wireshark. Finally, the conclusion is given in section V.

• II.    Bitcoin Blockchain Protocol

There are many possible ways to define the Bitcoin, one way is to think of Bitcoin as a protocol governing the overall communication on the Bitcoin network, the other possible way is to think of it as a digital currency which is purely P2P electronic cash, allowing payments to be sent directly, bypassing any intermediary financial institutions. In more general sense Bitcoin represents a platform comprising of P2P network, protocols and a software that eases the creation and usage of digital currency named bitcoin.

Bitcoin uses Elliptic Curve Cryptography(ECC) [3,4]based on SECP256K1 standard. Private keys are a random 256 bit numbers, mostly encoded using Wallet Import Format(WIF). Public keys are basically x and y coordinates on a elliptic curve. Public keys can be presented in compressed or uncompressed form with 33 and 65 bytes of length respectively. A bitcoin address is actually the hash of a public key, computed as under [5].

Algorithm 1 : bitcoin address generation

Input: Public Key,Version

Output: bitcoin address: 26-35 alphanumeric characters.

• 1    Calculate the SHA256 hash of Public key ;

• 2    Calculate RIPEMD-160 hash of output of the step1;

• 3    Key hash = Concatenation of the Version and output of step 2;

• 4    Calculate SHA256 two times of Key hash of step3;

• 5    Checksum = 1st 4 bytes of the output of step 4;

• 6    Concatenate Key hash with Cheksum;

• 7    Encoding the output of step 6 with Base58 encoding scheme;

• 8    Return output of step 7;

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 1

The heart and soul of Bitcoin is Blockchain: Technology that makes bitcoin a fully decentralized digital currency, which is both stable and secure. Blockchain can be defined as a immutable decentralized public ledger, which is both timestamped and ordered. Each block on the chain is identified by a hash and is linked to its previous block by referencing the previous block’s hash.

• A. Bitcoin Blockchain core Components

• a.    Block and Block Header

Block is one of the important and driving component of Bitcoin Blockchain. Table 1 and Table 2 presents the structure of a block and block header with size and brief description of each entry in the the block and block header respectively.

Table 1. Structure of a Block

Bytes	Name	Description
80	Block header	This includes fields from the block header.
variable	Transaction counter	The field contains the total number of transactions in the block, including the Coinbase transaction.
variable	Transactions	All transactions in the block.

Table 2. Structure of a Block Header

Bytes	Name	Description
4	Version	The block version number that dictates the block validation rules to follow.
32	previous block header hash	This is a double SHA256 hash of the previous block’s header.
32	Merkle root hash	This is a double SHA256 hash of the Merkle tree of all transactions included in the block.
4	Timestamp	This field contains the approximate creation time of the block in the Unix epoch time format. More precisely, this is the time when the miner has started hashing the header (the time from the miner’s point of view).
4	Difficulty Target	This is the difficulty target of the block.
4	Nonce	This is an arbitrary number that miners change repeatedly in order to produce a hash that fulfills the difficulty target threshold.

• b.    Bitcoin as a State Transition System

Bitcoin platform can be thought of as a state transition system, comprising of state and a statet ransaction function . State consists of ownership status of all bitcoins and transition function takes state and transaction as input and outputs a new state [6].

Fig.1. Bitcoin as a State Transition System.

The state in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is generated as shown in algorithm 1). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key of the owner, and one or more outputs, with each output containing a new UTXO to be included in the state [7].

Transition function can be formally written as:

APPLY ( S,TX ) → S ^’ or Error defined as follows:

• 1.    For each input in TX:

• •    If the referenced UTXO is not in S, return an error.

• •    If the provided signature does not match the owner of the UTXO, return an error.

• 2.    If the sum of the denominations of all input UTXO is less than the sum of the denominations of all outputUTXO, return an error.

• 3.    Return S’ with all input UTXO removed and all output UTXO added.

• c.    Bitcoin Mining

Mining in Bitcoin is a process through which transactions within a block are validated and blocks are added to the blockchain. Mining function is performed by special nodes called as miners . Mining is resource intensive process in a way as enough CPU and battery power is spent for mining a block. Roughly one new block is created (mined) every 10 minute. Miners are rewarded with new coins if and when they create new blocks and are paid transaction fees in return of including transactions in their blocks. New blocks are created at an approximate fixed rate. Also, the rate of creation of new bitcoins decreases by 50%, every 210,000 blocks, roughly every 4 years.

The major advantage of mining is that it secures the bitcoin system by guarding against frauds and double spending. Algorithm 2 presents the steps required for successfully mining a block.

Algorithm 2: The Mining Algorithm

• 1.    The hash of the previous block is retrieved from the bitcoin network;

• 2.    Collect the set of potential transactions broadcast on the network into a block ;

• 3.    Compute the double hash of the block header with a nonce and the hash from step 1 using SHA256 algorithm;

• 4.    If the result of step 3 is lower than the current difficulty target then stop the process;

• 5.    Result of step 3 is greater than the current difficulty target then repeat the process by incrementing the nonce;

• d.    Proof of Work

As name suggests it is the proof that enough computational resources have been spent to build the valid block. Proof of Work(PoW) involves searching for a value that when hashed, such as with SHA256 , the resulting hash begins with number of zero bits or is less than a specific target. The following equation sums up the Proof of Work requirement in bitcoin:

Where N is a nonce, P_hash is a hash of the previous block, Tx represents transactions in the block, and Target is the target network difficulty value. This means that the resulting hash should be less than the target hash value. The only way to find this nonce is the brute force method.

• III.    methodology

The bitcoin network is a P2P network where nodes exchange transactions and blocks. Analyzing contents of transactions, blocks and messages exchanged by peers requires capturing them, while nodes communicate with each other. For experimentation purposes, we installed Bitcoin Core(Testnet) client running on Testnet3 network [8]. The reason for using Testnet is that it allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain. There are few notable differences between bitcoin mainnet and testnet which are summarized in table 3.

Table 3. Bitcoin Mainnet and Testnet

Mainnet	Testnet
The real Bitcoin network, with the block chain that everyone uses.	test network that runs in parallel with mainnet, except that the value of these coins is negligible.
Costs real money not only to buy bitcoins but also as transaction fees	Essentially free to acquire testnet bitcoins.
Bitcoin protocol works on TCP port 8333 for the main network	Works on TCP port 18333 for testnet.

For capturing Bitcoin packets, we used network protocol analyzer called Wireshark[9,10].Wireshark allowed us to visualize messages exchanged between peers and thus served as an invaluable tool to deeply investigate about the Bitcoin protocol contents. We used [11] website to recieve some free coins and then transfer some coins back to it and record the whole process for investigation with Wireshark.

• IV.    Investigating Bitcoin Protocol using Wireshark

Typically a full bitcoin node can perform four functions: wallet, miner, blockchain and network routing node. The first thing that a bitcoin core node does when it starts up is initiation of discovery of all peers. This is achieved by querying DNS seeds that are usually hardcoded into the bitcoin core client and are maintained by bitcoin community members. This lookup returns a number of DNS A records. The process of node discovery, block or header exchanges and other network functionality are summarized below:

• 1.    Client sends a protocol message Version containing various fields such as version, services, timestamp, network address, nonce and some other fields.

• 2.    Remote node responds with it’s own version.

• 3.    After exchanging version messages both nodes then exchange verack messages, indicating that connection has been established.

• 4.    After connection establishment Getaddr and addr messages are exchanged to find about unknown peers. Nodes can test liveliness of connection by sending ping messages. Active nodes respond with pong messages.

• 5.    Now node can start downloading blocks to sync with network using GetBlock and GetData messages. If the node already has all blocks fully synchronized then it listens for new blocks using the Inv protocol message.

Fig.2. Bitcoin Node Discovery until version 0.9.3.

Until bitcoin core client version 0.9.3, a method called blocks-first was used for synchronization by nodes. The blocks-first method is very slow and some time takes days to complete synchronization. Consequently it was discontinued from bitcoin core client version 0.10.0. New initial block download(IBD) method named headers-first was introduced from client version 0.10.0. The headers-first method drastically reduces synchronization time to few hours. In headers-first method, when the client starts up, it checks whether the blockchain is fully synchronized already if the header chain is already synchronized; if not, which is the case the first time the client starts up, it requests headers from other peers using the getHeaders message. If the block chain is fully synchronized, it listens for new blocks via Inv messages, and if it already has a fully synchronized header chain, then it requests blocks using Getdata protocol messages. The IBD node also checks whether there is trade-off between headers and blocks: if headers are more in header chain; then it requests blocks by issuing the Getdata protocol message.

Fig.3. Header and Block Synchronization in Bitcoin Core Client>= 0.10.0.

Time	10.10.10.173
	89.31.		104.14
29 172562		version
29.446826	50049 ^---	version	; 18333
29.446827		v^ack
29.447017	50049 i	v erack
29.4Ы344		getaddr
29.581228	50049 '	"unknown command]
29.581470	50049 г	’unknown command]
29.581628		"unknown command]
29.589432		ping
29.725346		{unknown command]
29.725349	50049 *___	"unknown command]
29.725350		"unknown command]
29.725352	50044 ^	otng
29.725353	50049	3CC'
29.725833
29.725840		'unknown command]
29.811151	50049 '	addr
29 811443		getheaders
29.812228		'unknown command]
29.812573	50049 '_____	рОПС
29.851891	50049 ।		18333

Fig.4. Flow graph between two Peers on Bitcoin Network.

A. Analyzing Bitcoin Protocol Messages in Wireshark

Bitcoin dissector[12] plays an important role in analyzing the traffic and identification of Bitcoin protocol commands. Bitcoin dissector in Wireshark also provides valuable information such as the packet type, command name, and results of the protocol messages. Figure 4 provides protocol graph showing the flow of data between the two peers, providing clear picture on what messages are exchanged when a nodes starts up.

At present there are 27 types of protocol messages in total, but most likely they will increase over time as the protocol grows [4]. Table 4 lists the main ingredients of Bitcoin protocol messages with short description of each.

Table 4. Structure of a Bitcoin Protocol Message

Field Name	Bytes	Description
magic	4	Value indicating message origin network
command	12	String identifying messagecontent.
length	4	Length of payload in number of bytes
checksum	4	First 4 bytes of sha 256( sha 256( payload )).
payload	variable	The actual data.

Fig.5. Bitcoin Protocol Message in Wireshark.

a. Version

This is the first message that a node sends out to the network, advertising its version and block count. The remote node then replies with the same information and the connection is then established.

Fig.6. Version message in Wireshark.

Table 5. Payload contents of Version Message

Field Name	Bytes	Description
version	4	Identifies protocol version being used by the node.
services	8	bitfield of features to be enabled for this connection.
timestamp	8	standard  UNIX  timestamp  in seconds.
addr_recv	26	network address  of the node receiving this message.
addr_from	26	network address  of the node emitting this message.
nonce	8	Randomly generated every time a version packet is sent and is to detect connections to self.
user_agent	variable	User Agent (0x00 if string is 0 bytes long).
start_height	4	The last block received by the emitting node.
relay	1	Whether the remote peer should announce relayed transactions or not

If version packet is accepted, verack packet will be sent.

• b.    Verack

This message is sent in reply to version. It typically consists of only a message header with the command string "verack".

Fig.7. Verack Message in Wireshark.

• c.    Addr

This message is used by bitcoin nodes to provide information on known nodes of the network. If nodes don’t advertise for 3-hours they are automatically forgotten. Table 6 summarizes the contents of payload of addr message.

Table 6. Payload Contents of addr Message

Field Name	Bytes	Description
count	More than 1	Number of address entries (max: 1000).
address list	Multiple of 30	Address of other nodes on the network.

Fig.8. Addr Message in Wireshark.

• d.    Inv

This message is used by nodes to advertise their knowledge of one or more objects. It can be received unsolicited or in reply to getblock message. Payload of this message can have upto 50,000 entries corresponding to approximately 1.8 megabytes. Table 7 summarizes the contents of payload of inv message.

Table 7. Payload Contents of inv Message

Field Name	Bytes	Description
count	variable	Number of inventory entries.
inventory	Multiple of 36	Inventory vectors.

Fig.9. Inv message in Wireshark e. Getdata

This message is used in response to inv for retrieving the contents of specific object. Usually getdata is sent after receiving inv packet, after filtering known objects. Payload of this message can have upto 50,000 entries corresponding to approximately 1.8 megabytes. Table 8 summarizes the contents of payload of getdata message.

Table 8. Payload Contents of Getdata Message

Field Name	Bytes	Description
count	variable	Number of inventory entries.
inventory	Multiple of 36	Inventory vectors.

Fig.10. Getdata Message in Wireshark.

Fig.12. Getblocks Message in Wireshark.

h. Getheaders

f. Notfound

This message is used in response to getdata when contents of specific object can’t relayed. Table 9 summarizes the contents of payload of notfound message.

Table 9. Payload Contents of Notfound Message

Field Name	Bytes	Description
count	variable	Number of inventory entries.
inventory	Multiple of 36	Inventory vectors.

Fig.11. Notfound Message in Wireshark.

g. Getblocks

This message is sent by a node requesting other node to return inv packet containing list of blocks starting from the last known hash in the block locator object to stop_hash or 500 blocks whichever is earlier. Table 10 summarizes the contents of payload of getblocks message.

Table 10. Payload Contents of Getblocks Message

Field Name	Bytes	Description
version	4	The protocol version.
hash count	1 or more	Number of block locator hash entries.
Block locator hashes	32 or more	Block locator objects from newest block to genesis block.
hash _stop	32	Hash of the last desired block. Set 0 to get as many blocks possible (500).

This command is used by thin clients to quickly download the block chain to sync with the network. The response to getheaders message is a header packet containing the headers of the block starting right after the last known hash in the block locator object, hash stop or 2000 blocks, whichever comes first. Table 11 summarizes the contents of payload of getheaders message.

Table 11. Payload Contents of Getheaders Message

Field Name	Bytes	Description
version	4	The protocol version.
hash count	1 or more	Number of block locator hash entries.
Block locator hashes	32 or more	Block locator objects from newest block to genesis block.
hash _stop	32	Hash of the last desired block. Set 0 to get as many blocks possible (2000).

■* Getheaders message

Starting hash: 32fe63e49c!9488fa!25e0d9bcb473264c7b7e94a39de58f. Starting hash: 262d326a4ce0d7bd311f38612bdel760ela3c9cde0de652a, Starting hash: 873b4fc90d34da01c0cc769b78c2553a!6f101bf9076a6ae. Starting hash: 2e6281e22571-fe3479a94a2e41155ab966ae2150b2fef0cd. Starting hash: a317dblf29d7cfe24S3851ecb390df31cB05B2f10bd23ef8, Starting hash : 82f33e58bf96fd466al27cl4b747c49d07ec4caa5a676df3. Starting hash: 12f919162aacfdb46de8174717348cfa438ebc43e520780b. Starting hash: bafa60ea3d583a3623c7b5460a7a©a973595ba43e33bd826. Starting hash: d78ca4ad8fec0bd-f56a6cl56972f478b30b38dl86c59dbb6, Starting hash: 30e9b71fb27c204b7ad576b0e57d4701bddbc3f68d9de8S4, Starting hash: 39febce43104a269650017elb64483a46e79ed7d96ea2ece. Starting hash: 65h042c3bf9f50b294986980eae2e95c8b468415e596145d. Starting hash: ba4a5b684798c24b3fa7dld3ea980a21ab094e8c68debd52. Starting hash : Те4886+е+саЬ15624868945сес6а4с02а4с723Ь8ас9Ь0ее8. Starting hash: 429cl8ba-f86977e278c0blc37412ca294ab98400830cbc8f. Starting hash: 016644edclbf809a0e67c8de504f25e28270b3ad3fecd8d7. Starting hash: d5a!84cb396a2f25347ff5900d93I5f9fbbcdc795cc98cbe, Starting hash: 2952d787e977a87alcaf704b2b6cd9985888d69234d702f8, Starting hash: 12d7f7b59ecd72ad062f3ad032157fl3a5321a3193c656ec. Starting hash: 4c3c39402845951abb30c26b3e2b85b4d5d6e6012fc40d35. Starting hash : d93ddc60259eade9704e9e4f221eafadfЬа012е4е803Ь975. Starting hash: 6c343a34ce967648a-f604b292cd0c2080cc32955fe906742, Starting hash: 30a7c7cce7976156389e0a89235al963f121a60531ib6a31. Starting hash: bff14f830ff5efl6e86dc2327ell354c4960026edf2814e9. Starting hash : e5591dd9360c39dbe6468ed2f68a0728be953c5b5115246e, Starting hash: 35576471350c8a75ea01a4cf50db2dcal64471b3ebd5469f. Starting hash: e4496aebab793ddb9cb554beb3e39a7a668c3133a9fc0175. Starting hash: f04S4fe9f088492332a6e5ca6dbiea0e584daab06f3ecl01, Starting hash: f44b7e5f048c255835bd68a234f52ae86b06edl48ebda4e9. Starting hash: 253c819b314aa2ef67d82dd37e61bbcc9a8c3333c0485a64. Starting hash: d9e767720db97f7516cfd5d98760b5fe2d!29cc37459cad0. Starting hash : 43497fd7-F826957208f4a30td9cec3aeba79972084e90ead. Stopping hash: 000000000000000000000000000000000000000000000000,

Fig.13. Getheaders Message in Wireshark.

i. Block

This message is send in response to getdata message requesting transaction information from a block hash. Table 12 summarizes the contents of payload of block message.

Table 12. Payload Contents of Block Message

Field Name	Bytes	Description
version	4	Signed Block version information.
prev_block	32	The hash value of the previous block this particular block references.
merkle_root	32	The reference to a Merkle tree collection which is a hash of all transactions related to this block.
timestamp	4	A Unix timestamp recording when this block was created.
bits	4	The calculated difficulty target being used for this block .
nonce	4	The nonce used to generate this block.
txn_count	variable	Number of transaction entries.
txns	variable	Block transactions, in format of "tx" command.

• * Bitcoin protocol

  Packet magic: 0X0M10907

Command name: headers

Payload Length: 82

Payload checksum: 0xcb4c2409

• 4 Headers message Count: 1

4 Header Block version: 536870912

Previous block: f01244881f22adb87fablcl29al440a917b8e90fe5flbe91...

Merkle root: 291dcd7b06a7673c79ffe2874c05cc2bb2dac51ff3a7e496...

Block timestamp: Sep 14, 2017 22:25:42.000000000 India Standard Time Bits: 6xld00ffff

Honce: 0x0e6b0el8

Count: 0

96 le 08 b0 18 66

10 7h 40 ЙЙ ЯЙ 06

Fig.15. Headers Message in Wireshark.

• k. Ping

This message is send by nodes for testing TCP/IP connection liveliness. Any connection error is presumed to be a closed connection and address is removed as current peer. Table 14 summarizes the contents of payload of ping message.

• 4    Bitcoin protocol

  Packet magic: 0x0bll0907

Command name: block

Payload Length: 674

Payload checksum: 0xea71606d

• 4    Block message

  Block version: 536870912

Previous block: 3a9ed9e47930973f6632ef874b7c02283451a49a9d0a9d55...

Merkle root: 5620dblace096948528facb560e74cd56abl6c99e5fl5a90...

Block timestamp: Sep 13, 2017 16:39:11.000900090 India Standard Time

Bits: 0xlb03fffc

Nonce: 0x5b4c8045

Number of transactions: 2

4 Tx message [    1 ]

Transaction version: 1

Input Count: 0

Output Count: 1

• * Transaction output

Script Length: 0

Script:

Block lock time or block ID: 0

• * Tx message [    2 J

Transaction version: 0

Input Count: 0

Output Count: 0

Block lock time or block ID: 0

Fig.14. Block Message in Wireshark.

• j. Headers

This message is send in response to getheader message returning desired block headers. Table 13 summarizes the contents of payload of headers message.

Table 13. Payload Contents of Header Message

Field Name	Bytes	Description
count	variable	Number of Block headers.
headers	More than 81 per header * No. of head-ers	Block header.
txns	variable	Block transactions, in format of "tx" command.

Table 14. Payload Contents of Header Message

Field Name	Bytes	Description
nonce	8	Random nonce.

Bitcoin protocol

Packet magic: 0Х0Ы10907

Command name: ping

Payload Length: 8

Payload checksum: 0x6b4eb2b8

• ^    Ping message

| Random nonce: 0x51-f037t900d7aedb

Fig.16. Ping Message in Wireshark.

l. Pong

This message is send in response to ping message by a node to prove its liveliness on network. Modern protocol versions, a pong response is generated by using a nonce included in the ping message. Table 15 summarizes the contents of payload of pong message.

Table 15. Payload contents of header message

Field Name	Bytes	Description
nonce	8	nonce from ping.

Packet magic : 0Х0Ы10907

Command name: pong

Payload Length: 8

Payload checksum: 0x6b4eb2b8

• ^    Pong message

Random nonce: 0x51f037f900d7aedb

Fig.17. Pong Message in Wireshark.

• V. Conclusion

In this research work, we have deeply studied and investigated what exactly happens in the back screen when new peer joins the bitcoin network and starts syncing with network by downloading the blockchain. Firstly, we introduced core components of Bitcoin and then by using computer network protocol analyzer tool i.e. Wireshark, we have captured Bitcoin packets that are exchanged when peers communicate and deeply observed and analyzed their contents to make the whole communication process easy to understand for the readers.