There are different methods you can use to confirm whether your Bitcoin Satellite client is staying in sync with the Bitcoin blockchain. The below guide uses Bitcoin Satellite version 0.19.1.0.1.2 for Linux. If you are using a different operating system, you may need to adjust the steps accordingly.
Verify the Latest Block Synced Using the Debug Logs
The debug.log file provides information on the status of your Bitcoin Satellite client. You can use it to verify whether the client is operating correctly.
Locate your debug.log file at ~/.bitcoin/
Open the debug.log file. The latest block synced by your node is recorded at the bottom of the document. You can verify the status by confirming its block ID, block height, or date. One way to check the latest block height is to use the Blockstream Explorer. If the information matches the latest block mined on the Bitcoin blockchain, your node is in sync with the network.
A log entry may look similar to this:
height=644003 version=0x20000000 log2_work=92.206897 tx=559051448
You can also verify that the satellite receiver is receiving data. Bitcoin Satellite logs the incoming bit rate periodically. The logs may look like the following:
2020-10-09T19:03:41Z UDP multicast group 0: Average bit rate 0.09 Mbit/sec (blocksat-tbs-lowspeed)
2020-10-09T19:03:45Z UDP multicast group 1: Average bit rate 1.52 Mbit/sec (blocksat-tbs-highspeed)
Verify the FEC Decoding Process
You can also confirm the status of your satellite node by monitoring the forward error correction (FEC) decoding process. Bitcoin Satellite uses FEC to decode incoming data even if it is incomplete. The following commands allow you to confirm the number of blocks your node is receiving.
View General Information on Blocks Received
In your Terminal application, paste the below command:
Most likely, the command will return a result like this:
"n_blks": 322,"n_chunks": 104637
The result tells you how many blocks (n_blks) your node is receiving in parallel, as well as the corresponding number of chunks (n_chunks).
If your node already knows the lowest and highest block height among the blocks it is receiving, it will display additional information that details the blocks’ synchronization status:
"header_chunks": "22 / 22",
"body_chunks": "251 / 930",
"header_chunks": "19 / 19",
"body_chunks": "706 / 938",
Your node needs to decode the block header in order to determine its block height. While it has not decoded the headers, the command will return the former result that is limited to blocks and chunks.
View Information on Partially Received Blocks
Alternatively, you can enter the following command:
bitcoin-cli getchunkstats 0
This will return information on all FEC-encoded blocks your node has partially received so far:
"header_chunks": "9 / 14",
"body_chunks": "599 / 835",
"header_chunks": "19 / 20",
"body_chunks": "498 / 812",
"header_chunks": "0 / 0",
"body_chunks": "268 / 483",
Monitor the Txn Hit Ratio and FEC Chunk Hit Ratio
You can further monitor the speed at which your node is receiving block data.
Blockstream Satellite constantly transmits information about new transactions in the mempool to your Bitcoin Satellite client. As a result, your node may already know the majority of transactions that are included in a new block by the time it is mined.
By dividing the number of transactions your node has already received by the number of transactions included in the next block, you can calculate the txn hit ratio. Similarly, if you divide the number of FEC chunks that are prefilled with transactions your node has already received by the number of FEC chunks of the next block, you will receive the FEC chunk hit ratio.
Both ratios indicate the latency at which your node is likely to decode the next block. The higher these ratios, the faster your node will be able to decode the block.
You can monitor both ratios in your Bitcoin Satellite client.
In your Terminal application, run the following command:
Then enter this command:
bitcoin-cli logging \[\"fec\"\]
Locate your debug.log file at ~/.bitcoin/
When your node receives a new block, the txn hit ratio and FEC chunk hit ratio are displayed in the file like this:
UDP: Block [block hash] - Txns available: 1157/1165 Txn hit ratio: 0.993133
UDP: Block [block hash] - Chunk hit ratio: 0.962687
In this example, your node would already have received 1,157 of 1,165 transactions included in the next block, resulting in a txn hit ratio of 0.993133, or over 99%. This is a very good result. Depending on the speed at which your node is receiving blocks, this ratio may not always be achievable, resulting in higher latency in your node’s FEC block decoding process.