QUESTIONS FOR DEVELOPERS & BCN_official
1. Synchronization starts very fast, then slows down, under 150K blocks is problematic, and under 50K is a disaster. Why use single data.mdb file that now has 24.72 GB? Blockchain data.mdb file can not be larger than 5 GB. All over there is a disaster. Do something.
2. Blockchain data.mdb backup file, complete synchronization is made, synchronization again starts with 150K blocks? It would be expected to start from the last block, before the day, two, a few days ago, but not six months back. That's not normal. Why is that so?
3. Do you test the version before releasing it? If there are problems, let us know. Do we need to know something?
bytecoin-gui.log
[Walletd] Builtin state changed: RUNNING -> CRASHED
[WalletApplication] Daemon finished. Return code: WALLET_FILE_DECRYPT_ERROR (207)
[JsonRpcClient] Network error. Connection refused
[Walletd] Remote state changed: CONNECTING -> NETWORK_ERROR
[Walletd] Remote state changed: NETWORK_ERROR -> CONNECTING
etc.
4. Why does not offer a download link for blockchain data.mdb file? It should be an essential component in the download section. You do not need to do a backup every day. Do this at least once a month.
Thanks in advance. Regards
QUESTIONS FOR DEVELOPERS & BCN_official
1. Is it possible that we have sync problems because the IP addresses for the synchronization are attacked/congested? Can you check it out?
- Every service can be DDoSed if you know the IP-addresses. What makes it difficult is that Bytecoin network is decentralized, which means there are multiple nodes sharing the information between each other, so there is no central point which you can attack.
In addition, DDoS attack is an expensive thing. If you have the money to do it, there are many more interesting things that you can do with them
2. Synchronization starts very fast, then slows down, under 150K blocks is problematic, and under 50K is a disaster. Why use single data.mdb file that now has 24.72 GB? Blockchain data.mdb file can not be larger than 5 GB. All over there is a disaster. Do something.
- That is a good guess from your side. Actually, this phenomenon is related to an object called keyimage. When Bytecoin downloads blocks into the blockchain file, it also checks them for compliance to consensus rules. It involves reading a database of keyimages, which grows proportionally to the size of the blockchain. The larger the database of blocks, the more time you need to search it for the necessary value. This is why the blockchain sync slows down with its size.
The actual size of the blockchain file does not affect performance as much.
3. Blockchain data.mdb backup file, complete synchronization is made, synchronization again starts with 150K blocks? It would be expected to start from the last block, before the day, two, a few days ago, but not six months back. That's not normal. Why is that so?
- Sorry, didn’t get the question. Maybe you can describe this behavior to us in greater detail?
4. Do you test the version before releasing it? If there are problems, let us know. Do we need to know something?
- Of course, we do. There are no reasons to worry at the moment.
bytecoin-gui.log
[Walletd] Builtin state changed: RUNNING -> CRASHED
[WalletApplication] Daemon finished. Return code: WALLET_FILE_DECRYPT_ERROR (207)
[JsonRpcClient] Network error. Connection refused
[Walletd] Remote state changed: CONNECTING -> NETWORK_ERROR
[Walletd] Remote state changed: NETWORK_ERROR -> CONNECTING
etc.
- We suppose these messages were collected in succession? Then the situation is quite clear: the daemon crashed because of WALLET_FILE_DECRYPT_ERROR (207), which is likely caused by incorrect password entry. Since the daemon crashed, the connection to it was refused, and the software tried to reconnect.
These messages gain substance in context. Their presence doesn’t mean something is wrong.
5. Why does not offer a download link for blockchain data.mdb file? It should be an essential component in the download section. You do not need to do a backup every day. Do this at least once a month.
data.mdb is not a backup, but a blockchain database itself.
- First of all, this method defies the whole point of decentralization. This would mean:
You assume the place where you download blockchain from has not tampered with it;
This place is not DDoSed or taken down at this moment.
But secondly, let’s assume that we would check the compliance to the consensus in the file that you have downloaded. This method would have the following disadvantages compared to traditional P2P blockchain download:
You would have to interface with the complete blockchain file, which involves random read/write operations with HDD, which is a slow method. Our tests have shown that the hard drive is the bottleneck when syncing the blockchain, not the network. Getting a block from the network and processing it straight away is faster;
Technically, you cannot interact with files that the browser hasn’t finished downloading. So you would have to wait for it to finish downloading before processing it anyway.
We hope that was able to answer some of your questions!
