Based upon any standard you think relevant, how quickly are current blocks being verified for rule-following such as correct balance tallies, true transactions, correct rewards & fees?

Is this an onerous process? Would a database quicken this process?

Do you have any suggestions for improving block verification speed?


The bulk of the work lies in verifying each transaction within the block. This means that the signatures need to be checked for each transaction input, which requires a lot of CPU processing. So, one way to improve the verification speed would be to have a hardware-assist for the verification process (such as a specialized ASIC chip). I don't know if a miner ASIC could be used, but it is an interesting thought.

| improve this answer | |
  • That is not correct. See my answer. – Neal Gafter Dec 31 '13 at 19:53
  • Thank you ScripterRon! What about searching for past transactions to make sure the new ones balance? Is that not a terribly disk intensive process? Thank you very much in advance! – user5107 Dec 31 '13 at 21:26
  • 2
    The bitcoin client uses the LevelDB database to store the transaction outputs. I'm using the H2 database in my own application to store both the block chain and the transaction outputs. I'm not sure there is much more to be done other than performance tuning in high-usage areas (better SQL search arguments, indexes, caches, etc). – ScripterRon Jan 1 '14 at 1:04
  • 1
    Verifying the signature is CPU-intensive since you need to first derive the public key from the address and then use the public key to verify the signature. The digital verification process uses very large numbers and complex mathematical formulas. Check en.bitcoin.it/wiki/Transactions for more information. – ScripterRon Jan 1 '14 at 17:59
  • 1
    I should add that transaction verification isn't a problem when you get a new block once every 10 minutes. It only becomes a problem when you are downloading the initial block chain (either from bootstrap.dat or a peer node). It then becomes a gating factor in how fast the new node can synchronize with the network. And you are right, matching transaction inputs with unspent outputs is disk-intensive. So it is a combination of checking signatures, matching inputs to outputs, and creating new database entries. – ScripterRon Jan 1 '14 at 18:09

The transaction verification process is not particularly CPU or memory intensive. The CPU intensive part is the network protocol needed to get a global consensus on a single total order of transactions. That is called "mining" and that is what the specialized ASICs from various companies such as kncminer are designed to help with.

| improve this answer | |
  • It depends on what part of the process you are looking at. Definitely, if you are looking at the mining end, then finding the correct block hash is the most CPU intensive. However, if you are looking at the peer nodes which receive blocks, then the transaction verification is the most CPU intensive. This is one reason it takes so long for a new peer to process the block chain. – ScripterRon Dec 31 '13 at 20:37
  • Thank you Neal Gafter! Would you mind explaining why verification isn't expensive and why the network portion is? It seems that every individual part could be fast but will become less so with higher verification frequency. Thank you so much in advance! – user5107 Jan 3 '14 at 15:55
  • I've downloaded the whole blockchain, copied it to an off-line, recently-formatted machine, and still had to wait (an hour? 2? can't remember now) before everything was ready - so clearly verifying takes a lot of time and CPU. I once read the process could be accelerated should the QT client use the GPU for verifying, just as it's used for mining, but so far I've not seen any implementation of this idea... – Joe Pineda Jan 10 '14 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy