Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
So since I don't understand things like why the special ctor CBlockIndex::CBlockIndex(unsigned int nFileIn, unsigned int nBlockPosIn, CBlock& block) is only called/instantiated by CBlock::AddToBlockIndex(), it is hard to see much deeper into the code.

instantiated only from CBlock::AddToBlockIndex() is my comment - I've made it while I've been checking constructor usage. And I forgot to delete it. It has no higher purpose. Sorry.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Also is the "best chain" whatever that is (!?) what the code is using?
...

If you mean pIndexBest - perhaps you also need to check current testing version source from github to make more sense. But yes, best chain is a valid one with highest chain trust.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
The first if() seems to be returning the number of PoW blocks / number of PoS blocks, only if the current block is PoS. Why isn't the return the same if it isn't? I'm missing something here too!

...

Having nPoSBlockCount stored only with PoS blocks takes less disk space (10 times less PoS blocks now). Besides if ratio would be 9.9999 at PoS block (rounded down to 9 due integral type) and after long sequence of PoW blocks back to 10 - and after next PoS block 9 again - that I did not want - I was considering removing noTwoConsecutivePoSBlocks rule when ratio hits 3 and I did not want that to float back to 4. This is only theory anyway, I might have missed the point completely.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Looking at your new CBlockIndex method GetPoWPoSRatio(), what is the intent of the integral nature of its return value? It seems to me that it (the return value), since the code is doing an integral division, will be 0, 1, 2,...
...

This value later dictates number of consequent PoW blocks after PoS block, after which difficulty jumps and trust falls.
Having it truncated also forces PoW blocks window to "shrink" a bit sooner than real ratio would, thereby stimulating PoS block inclusion.
Decimal value would cause unnecessary conversions in calculations later.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Does the
if ( ppos->nPosBlockCount == 0 ) // should never happen return 0;
should never happen comment mean that two consecutive PoW blocks were just found?? And what does the return 0 mean/signify/imply? Is it good? Is it bad? Is it immaterial? Is it boolean?
...

I wasn't sure what you get if you call GetLastBlockIndex( *, true ) before first PoS block or when a bug was present. I did not want to allow division with zero so I returned 0 before next step. GetPoWPoSRatio() should always be called only on PoS blocks. And not before we switch to new version. Feel free to advise on best correction.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
It is my reading that you are proposing adding a 32 bit unsigned int count of PoS blocks to the CBlockIndex class definition, to make some calculation faster/easier?
...

Are you asking, why we need that ratio?
As you know PoS blocks can be ignored by PoW miners. My fix goes like this:

1. Take the current PoW/PoS block ratio
2. Count PoW blocks after PoS block and if it gets over that ratio, incrementally raise difficulty and lower trust.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Looking at main.h, the CBlockHeader class's last members are the unsigned ints nBits and nNonce. I do not get the reason/purpose/intent of swapping their order? I must be missing some other piece(s) of information, but it seems to me that it is immaterial which is first? Similarly with nTime, the unsigned int before them?
...

I would not swap order. I would swap their content.
In my code, PoW block target moving average is now stored in PoS block nNonce (instead of current 0).
If it would be stored in PoS block nBits, we could later calculate approximate chaintrust from block headers only.
Currently PoS block nBits attribute holds PoS block difficulty and that would need to be moved and code changed. But moved where? nNonce is the only candidate left.

The problem is, you can only partly differentiate PoW block from PoS block if you do not have transaction data, only headers (because there are some PoW blocks with nNonce=0 and there are some PoS blocks with target < bnProofOfWorkLimit). And you can not mix and aggregate their targets (nBits) to arrive at final chaintrust value without knowing what "type" of nBits you are operating with.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Isn't a full node all ready in possession of the whole block chain?
...

Headers-only method has a well documented purpose. The need for it will be even more aparent with Yacoin than with Bitcoin.
There could be other and better solutions, that is why I wanted feedback.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
And as I said previously, doesn't that full node already scan all the blocks in its possession at start up, so that it (the node) "knows" all there is to know, PoW/PoS counts, ratios, last few block types, etc.?
...

I don't know how to quickly and repeatedly get PoW/PoS ratio now without scanning and processing ever growing now 1M+ items long hash map. Please let me know.

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
And it's not like the blocks are really that much bigger than their headers. Most have only the creation transaction, very few actual transactions, at least lately from what I have seen.
...

We'd like that to change one day. Wouldn't we?

Quote from: old c coder on July 26, 2015, 06:58:41 PM

...
Maybe I'm just different, but when I worked in the industry, we had a (much) higher standard of code "readability" and documentation.
...

No, you are not different. This is just not industry anymore. I am learning C++ while fixing yacoin. Imagine how much I am getting paid for extensive analysis design and documentation.

Thanks for your input. You are welcome to elaborate.

Regarding your version with integrated explorer: I do not have QT installed and haven't programmed with it ever. Would you mind posting a screenshot or two?
Another thing I wanted to ask - why not use http://msinttypes.googlecode.com/svn/trunk/ in MSVC release? Wouldn't that cut down number of ifdefs and make a code more compatible?