Hello Senj,
Inline below are a few questions and thoughts
I have looked at the code at both links.
First, since the original code (Bitcoin 0.7.4 aka Yacoin) is/was poorly documented, obscurely coded, unintentionally I'm sure, and written in a language (C++) that is more than opaque (1400 pages to "explain" the latest 4th incarnation of C++!!!! Come on) I find that it is difficult squared reading the source for true "grokness"
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.
Maybe I'm just different, but when I worked in the industry, we had a (much) higher standard of code "readability" and documentation.
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,...
How is that to be interpreted?
Also is the "best chain" whatever that is (!?) what the code is using? 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!
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 would at least like NEVER to see a magic number as a return value. One can always in C++, define a meaningful name to be 0, thereby denoting and connoting the meaning/intent/context of the return value.
I would suggest an old C #define if nothing else! Perhaps a C++ const unsigned int variable or even a C++ enum. They all are equivalent after any compiler digests it, and the code is the same, just as fast, but much more readable.
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?
I can't go much deeper until I can understand the things mentioned above.
I would be curious what other coders have to say about these things, or am I alone in the wilderness?
[/tt]
What I would like to do next is talk about my next goal: Before these changes go in effect, I would like to do more refactoring (prepare, this might hurt a bit) and swap PoS block nNonce and nBits.
And the reason has to do with what I believe will be one of next major yacoin issues - future implementation of
Headers-first method.
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 feel that there must be some (more) undocumented code that depends/relies upon the order of the members that I am not aware of? If it is just
undocumented magic number offsets in some code, for example, the definition of
nBlockNonce in
BitcoinMiner() in
main.cpp, then I think we should fix those undocumented items first!
I don't see what "headers first method" (what ever that is!) has to do with the header being ordered slightly differently?
Hard fork is the only right time to do such things. This way we can make it possible to determine chain trust from headers only (once you understand the changes I linked to), otherwise all clients will need to download and process full blockchain. This will become very time and resource consuming with each next block - and yacoin system generates a lot of them.
Isn't a full node all ready in possession of the whole block chain? Or am I missing something in your logic? 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.? 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.
Again, am I missing something hidden/not stated here?
However, before I start, I need some feedback from community - do I have your support? Will I get any help? Opposition?
And please check out two links above.
I am generally 'fer' it not 'agin' it, in principle. But whether I understand what the code is intending and how it is accomplishing it, or what the code is actually doing and whether that is what was intended, I can't say! I can't even say what the current code is intending, nor what it is doing and whether they are the same.
I come from the postion that if one wants open source code to be understood by the widest possible audience, then the code has to be edited much as a literary editor edits a book (fiction or non-fiction). layout (formatting) is important too, much like a book.
I think that if the code was much more transparent as opposed to being opaque, we might find that there are minds out there, that can see more deeply into the code and come up with insights that elude the "geek mind" that reads code through a constant filter (internal symbol table) in their own head, that memorizes and translates all the abbreviations, name-contractions, magic numbers, greater than 200 character lines, ... and then has to paraphrase every line, method, class, template, macro, file,... in the program to state what is going on.
No paraphrasing should be necessary.
The editing of the source, that leaves the executable identical, byte for byte, but increases the readability, should have been done to the first or very early versions of the Bitcoin source. Then all the coins wouldn't be in the state they are in.
We are six years into the life of Bitcoin, and there are functions, methods, names,... that haven't changed from the first versions. That is pure laziness, since editing is a very difficult but necessary job. See Joel Spolsky's rub a dub dub:
http://www.joelonsoftware.com/articles/fog0000000348.htmlA friend tells me that every 5 versions, where he works, they stop and do that, a cleanup, etc. of the code. Hard to justify to a "bean counter" manager/corporation that a no change to the executable pause should occur in the process. But since Bitcoin was/is not a private business thing, it should have been cleaned up, over and over again, from 0.3.1 to 0.11.0, but I see no evidence of it. Bad habits or the lack of ever having been exposed to good habits or laziness are the only explanations I can come up with.
Well, there's my 2centz
Ron
