Familiar with bitcoin-CLI commands

We have seen how to safely stop Bitcoin Core using the Bitcoin-cli stop command. In this section, we introduce the bitcoin-CLI command grouping and some of the commands used to get the overview information. You’ll likely encounter more Bitcoin-CLI commands in other chapters of the book, such as how to view a specific block. As of version 0.15, all commands can be viewed in the Bitcoin-CLI command lookup table at the end of this article.

The commands listed below are executed through bitcoin-CLI.

1.1 getblockchaininfo

This command displays an overview of the Bitcoin network. The output is as follows:

{"chain": "test", "blocks": 0, "headers": 32000, "BestBlockHash ":" 000000000933Ea01AD0EE9... f408719526f8d77f4943", "difficulty": 1, "mediantime": 1296688602, "verificationprogress": 5.853850457214259 e-08, "chainwork" : "0000000000000000000... 00000000000000100010001", "pruned": false, "softforks": [ { "id": "bip34", "version": 2, "reject": { "status": False}},... , "bip9_softforks": { "csv": { "status": "defined", "startTime": 1456790400, "timeout": 1493596800, "since": 0 }, "segwit": { "status": "defined", "startTime": 1462060800, "timeout": 1493596800, "since": 0 } } }Copy the code

For good formatting, we omit some of the output. For example, the bestBlockHash field originally had 64 bits, but we omit 22 of them and use “… “instead. Instead. Now let’s briefly look at the meaning of each output field:

Chain: This field indicates the current blockchain network type. There are three in total, specified in BIP70[7]. One is Main, which is the blockchain network that most people are using and which can run ordinary transactions, and the other is RegTest. What we have here is test, which is used by developers to test. Here the output field is test, indicating that we set testnet = 1 in the configuration file (bitcoin.conf), as shown below:

Blocks: Blocks processed by the current node. The processing here includes downloading and validation. On newly installed nodes, this number will increase until it is synchronized with the entire network as the initial block download 6 is made.

Headers: Block Headers that have been processed by the current node. This value, the height of the current block, can be found at http://blockchain.info[8]. Here’s what I found:

On a Full Node, Headers should be the same as Blocks, except for newly installed nodes. Headers synchronization on newly installed nodes seemed to complete first, while full synchronization on blocks took nearly 1.5 days in my environment.

As an aside: Bitcoin blocks should be created every 10 minutes. As you can see from the chart above, several recent Bitcoin blocks have been “mined” in relatively little time.

Bestblockhash: The ID of the current most trusted block, which is the last valid block of the current longest chain. It may or may not be the latest block to be mined, depending on whether the latest block to be mined is on the right fork.

Difficulty: The Difficulty value of the current block. See 2.1Difficulty and Target Bits for a detailed explanation.

Mediantime: Mediantime for the past 11 blocks. Note that the blocks referenced here are the confirmed blocks on the longest chain. This time is Unix TIMESTAMP, meaning it dates from January 1, 1970. You can convert this to a more readable time representation on a Linux machine using the following command:

date -d @timestamp

In the above example, medianTime is 1296688602, which corresponds to the time:

Date -d @1296688602 -- Output -- Thu 07:16:42, 02 03, 2011 CST time on mainnet is 1517704544. Date -d @1517704544 -- Output -- Sunday, 04 February 2018 08:35:44 CSTCopy the code

Each block contains a Unix time timestamp. The block is recognized only if the timestamp is greater than MedianTime and less than some adjusted network time [1].

Verificationprogress: Percentage of confirmed transactions. The value ranges from 0 to 1, but may be slightly larger than 1. On a newly installed Full Node, this ratio can be considered as the completion of the block download, since the block download is completed before the confirmation process is completed, and the confirmation time is relatively fast.

Chainwork: This field, when present in a block, is the number of double hashes performed from creation to the current block; When present in the return of getBlockChainInfo, this is the number of double hashes performed by the current chain. It is a hex coded string used to compare the longest chain between forked chains. In writing time, Mainnet chainwork value is 00000000000000000000000000000000000000000106796908 bc47b48f4a67bf [2], the equivalent of 317311908621044699095525 decimal 311, which is 31.73 yotta.

Pruned: Boolean value. Indicates whether the pruned mode is used. If in pruned mode, downloaded blocks can be deleted to save disk space.

The rest of the information is about the Bitcoin fork, which we will omit to avoid introducing too much detail.

1.2 getwalletinfo

View the wallet profile.

{" walletName ": "wallet.dat", "WalletVersion ": 139900, "balance": 0.00000000, "unconfirmed_balance": 0.00000000, "immature_balance": 0.00000000, "txcount": 0, "keypoolSimple ": 1517455171," keypoolSize ": 1000, "keypoolSIZE_hd_internal ": 1000, "unlocked_until" : 0, "paytxfee": 0.00000000," hdMasterKeyID ": "57bb0019c214ab1e6accf211ec8c252157db965d" }Copy the code

The meaning of most fields is self-explanatory. Only some fields are briefly explained here.

Balance is the confirmed account Balance in BTC units.

Unconfirmed_balance, the total amount of transactions paid to the wallet, but not yet confirmed, is also BTC units.

The Immatrue Balance mining bonus can only be used after 100 confirmation. until then, it will be immature. Again, BTC units.

Txcount is the total number of transactions in the wallet.

Keypoololdest is the Unix timestamp of the oldest generated key.

Keypoolsize: indicates the number of pre-generated public and private key pairs. Use multiple replaceable public keys

The purpose of private key participation in transactions is to improve security and anti-tracing.

Keypoolsize_hd_internal, the number of wallet addresses for internal use (such as change).

Unlocked_until, the wallet itself can also be encrypted, but must be decrypted before use. This parameter specifies how long the decrypted wallet can remain decrypted. 0 indicates that the wallet is locked, other numbers should be interpreted as Unix timestamps.

Hdmasterkeyid, 160-bit Hash for HD Wallets Seed Key

1.1.3 getnetworkinfo

This command is used to check the network status of the current node. This includes the version of the network protocol used by the node, whether the current network is networkactive, how many connections there are, and which networks are used (ipv4, ipv6, and Onion).

The previous connection, called a peer connection, can be viewed using another command, getPeerinfo. If you execute the following command:

bitcoin-cli getpeerinfo |grep id |wc -l

You will get the number of nodes with which you have established connections, which should be equal to the number of connections we got from getNetworkInfo.

1.1.4 getblockhash

This is a very important order. We know that each block is identified by its ID, and each ID is a 160-bit hash. This ID is very inconvenient to communicate. We also know that each block has a height value, and for the main chain, each height value corresponds to a unique block.

We can use this command to find the ID of the Genesis Block, the first block (mined by Satoshi on a server in Helsinki), and any other block at any height, and get information about that block.

Bitcoin -cli getBlockHash 0 bitcoin-cli getBlockHash 1 bitcoin-cli getBlockHash 10000 - 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 0000000099c744455f58e6c6e98b671e1bf7f37346bfd4cf5d0274ad8ee660cbCopy the code

1.1.5 getblock

Once you have the ID of the block, you can query it further with the getblock command:

Bitcoins – cli getblock 000000000019 d668985a… a2a6c172b3f1b60a8ce26f

This gives us information about the Genesis Block:

{" hash ":" 000000000019 d6689c085ae16... e46a2a6c172b3f1b60a8ce26f", "confirmations": 507548, "strippedsize": 285, "size": 285, "weight": 1140, "height": 0, "version": 1, "versionHex": "00000001", "Merkleroot ":" 4A5e1E4BaAB89F3A32518A... Cc77ab2127b7afdeda33b ", "tx" : [" 4 a5e1e4baab89f3a32518a88c31bc... 7 ab2127b7afdeda33b] ", "time" : 1231006505, "mediantime" : 1231006505, "nonce": 2083236893, "bits": "1D00FFFF ", "difficulty": 1," Chainwork ": "0000000000000000... 0000000000000000000100010001 ", "nextblockhash" : "00000000839 ad76f4... 0947ee320161bbf18eb6048" }Copy the code

The resulting information does not contain transaction information, that is, we get the header of the block. To get all the information, you need to pass in the Verbosity parameter. When the parameter value is 2, you can get all the information:

Bitcoins - cli getblock 000000000019 d668985a... A2a6c172b3f1b60a8ce26f2 -- Output -- OmittedCopy the code

There are some fields in the output above that need to be explained.

Hash: Block ID, 256 byte Hash, hex code.

Confirmations: How many times has this block been confirmed? If the block belongs to the Best chain, this value is equal to the full chain height and is also the depth of the block.

Size: indicates the Size of the block.

Weight: for the meaning, see BIP141.

Mediantime: The meaning of this field was explained earlier, but we are interested in the meaning of its value. The decode date is January 3, 2009, a Saturday (GMT).

Merkleroot, Nonce, difficulty, and bits are the core of Bitcoin, and we’ll focus on them later.

It’s important to understand that the output we get here is not the data from the original block. Some of the data doesn’t even exist in the original block, but is computed, such as confirmations, NextBlockHash, etc., which appear to help us understand the block better. How do you know that the original block does not contain this data? The verbosity parameter of getBlock has three values. The default value is 1, and we have already seen when to use 2. The remaining value, 0, will help us dump the raw data (hex coded, of course!). . The raw data for the originator block is shown below. Instead of using the raw output from getBlock for easy reading, I use the following format:

This output deserves a good explanation.

The first four bytes, 01000000, are the version number.

Bytes 5 to 36 are the hash of the previous block, zero here.

Bytes 37 to 68 are the Merkle root hash for the current block.

Byte 69 to 72,29 AB5F49, is the time when the block was dug, which is January 3, 2009. Note that the byte order needs to be adjusted and the actual representation should be 0x495FAB29, which is 1231006505 in decimal.

Header information ends in Bits and Nonce, followed by transaction-related information. We’ll talk about it in a special section.

We now have a Full Node fully installed and are familiar with its Settings and basic commands. This gives us a great tool to detect and understand the Bitcoin network. Next we will start with bitcoin transactions and talk about block generation and validation to take the main bitcoin activity through.

Before we can understand transactions, we must understand bitcoin wallets and wallet addresses.

Yang Yong: Blockchain learning Notes (A) – client installation​zhuanlan.zhihu.com
Yang Yong: Blockchain learning Notes (II) – Bitcoin – CLI​zhuanlan.zhihu.com
Yang Yong: Blockchain learning Notes (III) – Bitcoin wallet and address​zhuanlan.zhihu.com

[1] This time is the median time stamp for all p2p nodes you are currently connected to plus 2 hours.

[2] For operations on such large numbers, python’s Decimal package is available.