Quote from: Peter R on July 08, 2015, 08:50:15 PM

Quote from: iCEBREAKER on July 08, 2015, 07:49:57 PM

Mempool is full of tx waiting to be (slowly, thanks to completely unoptimized Createnewblock) processed into new blocks.

Does CreateNewBlock currently take longer to execute if there are more TXs in a miner's mempool to pick from? If so, this would add credence to Cypherdoc's hunch that miner's are producing more empty blocks when mempool swells.

I think gmax already (indirectly?) answered your question here:

Quote from: gmaxwell on July 07, 2015, 12:09:19 AM

I expect correlation between empty blocks and mempool size-- though not for the reason you were expecting here: Createnewblock takes a long time, easily as much as 100ms, as it sorts the mempool multiple times-- and no one has bothered optimizing this at all becuase the standard mining software will mine empty blocks while it waits for the new transaction list. So work generated in the first hundred milliseconds or so after a new block will usually be empty. (Of course miners stay on the initial work they got for a much loonger time than 100ms).

This is, however, unrelated to SPV mining-- in that case everything is still verified. As many people have pointed out (even in this thread) the interesting thing here isn't empty blocks, its the mining on an invalid chain.

but I'll attempt to unpack and contextualize his response... Tongue

CNB execution time depends on CPU/RAM/SSD speed and mempool size, both of which are adjustable user defined values.

The theoretical "more empty blocks when mempool swells" effect only dominates when the previous block validates faster than the "100ms" maximum CNB takes to make the next one; according to gmax avg. validation times are "16-37sec" (for f2p/ant).

IOW, CNB while 'slow' in the relative sense it is unoptimized, is much (>1600-3700 times) faster than avg. blocks' verification times.

So, (if I've not failed spectacularly in my amateur hour gmax impersonation) Frap.doc's hunch only applies after empty or nearly empty, very small, tiny little blocks.

As block become larger (non-tiny/empty), verification time increases quadratically. Absent any threshold effects, I'd expect CNB performance to be ~linear with mempool size (which, again, is adjustable, unlike previous blocksize).

Larger blocks are thus self-defeating (IE encounter negative marginal return) because their quadratically-scaling verification time greatly exceeds CNB's (perhaps linearly-scaling but in any case much faster) execution time, ensuring more empty blocks are produced exactly when network throughput/load needs non-empty blocks the most.