Quote from: SuperClam on July 08, 2015, 03:06:19 AM

Quote from: dooglus on July 08, 2015, 12:07:53 AM

Quote from: SuperClam on July 07, 2015, 01:35:06 PM

Awesome work with the stake data chilly2k - we're happy to have you as part of the family

Deb calls it "the clamily".

Quote from: presstab on July 08, 2015, 02:46:09 AM

Interesting about the mask, that is the part of the code I was not processing correctly. Ok so I think we have the wait 16 seconds part of it cleared.

Quote from: dooglus on July 08, 2015, 02:03:57 AM

No, because look at the lines before that:

Quote

if (nSearchTime > nLastCoinStakeSearchTime)
{
int64_t nSearchInterval = IsProtocolV2(nBestHeight+1) ? 1 : nSearchTime - nLastCoinStakeSearchTime;

It only gets into that block if nSearchTime is greater than the last search time. And nSearchTime has already been rounded down to a multiple of 16 seconds. So it will only get into this block at most once per 16 seconds.

After 16 seconds have passed this code continues, and nSearchInterval becomes 1. I still can't follow exactly where it iterates 16 different timestamps in one hashing session? I might have to add a couple of log prints with timestamps into the code to visualize this better.

dooglus can verify and expound on this; but, the concept is that it doesn't iterate all 16 One second increment timestamps. In fact, if you look at the timestamps of on-chain blocks (approved by network consensus) - all of them have 16 second interval timestamps.

CheckCoinStakeTimestamp() mandates that block timestamps must follow the 16 second mask.
You could hash all 16 seconds if you pleased, but peers would reject the block as a timestamp violation.

Wow! Ok now that you say that I see the same 16 second mask in the check stake code. Now this all makes sense in the context dooglus put it in. This is a pretty cool way to hash for proof of stake. Now I know why I was so lost :/