How many transactions can a node validate in a second?

[?QuestionMark?]

How many transactions can a node receive and validate in a second? I guess bitcoind uses multi threading and I saw there's an option to adjust the amount of cores you want to use. But are there known any numbers for a usual desktop pc?
In a reddit thread someone said that with an 20k computer you could make over 500k Sig Ops per second. Means sig ops, validation of transactions?

I reposted this here since I got no answer in the technical discussion board (posted yesterday). I'm new here, so what's the max time to except for an answer?

[odolvlobo]

I don't know the answer, but perhaps you could get a estimate by dividing the amount of time it takes to synch your node by the number of transactions in the blocks you synched. As long as your are well-connected, then most of the time spent synching is spent validating the transactions.

Keep in mind that it depends a lot on your node's hardware, of course.

[pooya87]

Interesting question and I think the only way to answer it is to run an actual benchmark with a code that is designed to measure this because generally speaking transactions can take different time to be validated.
For example a legacy transaction with a lot of inputs takes a longer time to verify compared to a SegWit transaction with the same large number of inputs due to the way sig-hashes are computed.
Obviously the number of inputs and number of signatures each input has (eg. multi-sig) also affect the time since you have to compute more hashes and verify more ECDSA.
Script type can also affect the time, some non-standard ones could take a significant amount of time more than the standard ones.

This is why we focus on "sigops" which is basically the time it takes to run an OP_CHECKSIG while OP_CHECKMULTISIG is considered more than one sigop depending on its settings.

P.S. Bitcoin core has are some benchmarks, you may want to look into them.

[ranochigo]

Sigops stands for signature operations. Bitcoin transactions can contain multiple signature operations depending on the complexity of the script, P2SH output for example could allow you to pad to a fairly high number of sigops but keep in mind that current standardness limits keeps it under 15. Current consensus limits sets it at 80,000 sigops per block.

I saw your topic a few days ago but unfortunately I couldn't come up with any concrete numbers so I didn't comment on it. That being said, here is what I've experimented with so far, do take it with a grain of salt though.

I've run two instances of Bitcoin Core (0.21.0), and the results were fairly similar, this is from my run which I downloaded from scratch. From what I've observed, the timing will vary significantly if you choose to select assumevalid.

   - Connect postprocess: 0.00ms [1.67s (111.43ms/blk)]
 - Connect block: 8429.91ms [341.49s (22766.07ms/blk)]
   - Load block from disk: 5.00ms [0.01s]
     - Sanity checks: 1.00ms [0.00s (0.13ms/blk)]
     - Fork checks: 0.00ms [0.00s (0.00ms/blk)]
       - Connect 2075 transactions: 10465.00ms (5.043ms/tx, 1.571ms/txin) [350.14s (21883.62ms/blk)]
     - Verify 6661 txins: 10465.00ms (1.571ms/txin) [350.14s (21883.75ms/blk)]
     - Index writing: 3.00ms [0.06s (3.84ms/blk)]
     - Callbacks: 0.00ms [0.00s (0.06ms/blk)]
   - Connect total: 10470.01ms [350.21s (21888.03ms/blk)]
   - Flush: 4.00ms [0.08s (5.00ms/blk)]
   - Writing chainstate: 0.00ms [0.00s (0.00ms/blk)]

I think that the IDB download would be far more accurate considering that the transactions are not relayed first to the node but it's verified with the received block. The former would probably have majority of the transactions being in the mempool first and would have been verified already. The numbers can and will be misleading. A single P2SH input can contain multiple Sigops and I can't find a way to benchmark individual transactions or transactions with a single sigops only.

The results would vary quite wildly across different systems, considering the fact that the process is not purely CPU bound but would also involve your RAM with the UTXO set being stored on it, depends on how much dbcache you have. You can try running the secp256k1 benchmark as well: https://github.com/bitcoin-core/secp256k1.

[ranochigo]

Can you share how to perform the benchmark? I'd like to try run the benchmark, but i didn't find command used to perform benchmark (i already build it without problem).

I ran Bitcoin Core with a -debug=bench flag.

I didn't try to build the benchmark from the git, doesn't seem to want to build on my server. I'll have to find a way around that.