3

Recently I updated to version 0.10, but that wasn't an easy process. It took too long to go over my old blockchain and make it compatible with the new client, so I aborted that (iirc there was no progress report, and the whole thing was indistinguishable from frozen). Then I tried re-downloading the blockchain from scratch. That was taking days too, and progressively slowing down, so I aborted that too. Eventually I just got a brand new node running in a faster computer and transplanted its blockchain into mine, so now I have the updated version running fine.

I was told that the reason it was taking so long for my computer to verify the blockchain was that it had a spinning disc which had to be queried continuously to verify all the ring signatures on the blockchain. That agrees with my experience of syncing the new node in just a few hours, as opposed to days in my old machine.

In any case, my question is: wouldn't it be possible and/or desirable to at least partially do away with that verification process? I mean, isn't that the whole point of using a hashed linked list as our blockchain in the first place, to produce an immutable record of what was already verified in the past? Couldn't we make it so that new nodes only verify (at least at a first moment) that the blocks and hashes that they receive match what the network has told them is the chain with the greatest work invested into it, and perhaps they only have to verify, say, the last month's worth of ring signatures?

Improve this question
3
  • 3
    "which had to be queried continuously to verify all the ring signatures on the blockchain" is wrong. You do not re-verify all the previous signatures for every block.
    – user36303
    Commented Sep 30, 2016 at 19:56
  • 3
    Sorta but not really...you do have to query the blockchain to get the public keys for incoming transactions to verify their ring signatures.
    – Luigi
    Commented Sep 30, 2016 at 22:23
  • Interesting, thanks. But then, what is the client verifying while syncing?
    – user141
    Commented Oct 1, 2016 at 0:55

1 Answer 1

Reset to default
2

Unless you had --fast-block-sync 0 as a command-line flag, it should've already been skipping both POW checks and ring signature checks. With the transaction rates we've had in much of the coin's history, checking POW actually takes longer than signatures.

You might also try bumping --db-sync-mode arg (=fast:async:1000) to something higher (10000?), and possibly switching to "fastest". --db-sync-mode fastest:async:10000 Note that there have been some corruptions on fastest (can happen if sync is interrupted).

Improve this answer
4
  • That is good to know that it already doesn't do the ring signatures verification every time, but not even the PoW? How does my client know that I have the right lmdb then? // Also, I was running first in fastest mode, but then after a hard shut down the database got corrupted and I was advised to use fast mode instead, like you suggested, so that is what I was doing. // Now that you mentioned that what I though was making my client slower wasn't the case, I am truly at a loss as to the cause, since my memory and cpu usage were low at the time, and the only thing really active was the HD.
    – user141
    Commented Oct 1, 2016 at 0:51
  • It checks block hashes against a precomputed list included in the binary. CPU usage being low would indicate it was indeed skipping ring sigs and POW. The HDD usage is going to be high during sync regardless, since the data is being indexed. What size/speed HDD do you have?
    – Luigi
    Commented Oct 3, 2016 at 17:14
  • The partition size is almost 800 GB, and using hdparm I am getting 8500 MB/sec for cache, and 97 MB/sec for buffered.// So, from what you are saying my full node is not verifying anything?! Can that be right? Anything precomputed and included in the binaries is bound to become obsolete pretty much from the onset. Shouldn't my node be verifying at least the hashes (PoW) of the new blocks?
    – user141
    Commented Oct 3, 2016 at 17:34
  • 1
    Of course it verifies new blocks. The data is not "obsolete pretty much from the onset". We have >2 years of chain history. The precomputed stuff is solely for bootstrapping. Those numbers seem ok. I wouldn't expect more than 12 hours or so to sync (I have only heard stuff, I've never synced to HDD). If you are able, you might want to poke your head in #monero-dev on freenode and ask for help from hyc or moneromooo..
    – Luigi
    Commented Oct 3, 2016 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.