Quote from: gmaxwell on May 10, 2015, 09:00:07 PM

Quote from: valiron on May 10, 2015, 08:46:05 AM

Mean blocktime validation of one transaction blocks:
[...]
Shorter validation time for one transaction blocks is expected for miners

It is unclear to me what you are talking about. What specifically are you referring to by "blocktime validation"? Are you talking about the ntime gaps? Blocks of very slow miners should have lower timestamps because they do not frequently update their midstate (e.g. they would claim older times because that was when they started); modern fast miners blow through the range quickly, and thus have plenty of opportunities to increment their time. (Much of the single tx blocks back then were believed to be a botnet that verified nothing).

If you are saying smaller blocks take less time to validate largely. This is mostly untrue at the tip of the chain. Leave your node running for 24-48 hours and then look at the block verification times. You'll see that the actual blocks, in spite of being huge, typically verify in a few milliseconds (-benchmark will enable ms resolution timing results in the logs). This is because almost all the verification is cached from the transactions being relayed earlier.

It is not what you think. I probably didn't explain myself well.

A miner can start working on the POW(=validating the block) before including any transaction. When you include transactions or update your transactions you need to recompute the hash of the merkel root, thus it is faster to start working with empty blocks (this doesn't mean that they are not quickly updated into a non-empty block).

This may be an explanation of why the average validation time of blocks with only the coinbase transaction is 5 times shorter than the average, because when these blocks are solved it is at an early stage. There may be other reasons...for example...start validating the next block before broadcasting the solved block to gain some advantage...and start validating an empty block because most of the transactions were included in the validated block.

If you can give other reasons you are welcome...

BTW...there are one transaction 1204 blocks since 2013, thus the average computed is meaningful.

If you can provide the data of local timestamps I can run more statistics on the discrepancies of timestamps. Anyone running a node since 2013 with that data?

Quote from: btchris on May 10, 2015, 09:45:37 PM

Quote from: gmaxwell on May 10, 2015, 09:00:07 PM

Quote from: valiron on May 10, 2015, 08:46:05 AM

Shorter validation time for one transaction blocks is expected for miners

It is unclear to me what you are talking about.

I believe one thing valiron is talking about is the practice (which I recall reading about, I've no idea if it's still in use, or ever has been) of pool operators sending out work for empty blocks to their miners immediately after a new block is found, to get the miners working on the new chain ASAP, and then creating a non-empty block & merkle tree at their leisure and updating miners once it's ready.

I think you explained it well.