...
the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.
How, in code could one accomplish a 10 minute average PoW block period, I wonder? If the desire is 9 (up to 9?) PoS blocks, then the code would have to sense the 8 (9 -1) minutes since the last PoW block, and then start PoW-ing on the latest PoS block and on the average, solve for it in 1 minute?
Such type of block spacing calculation is already coded. Again,
LinkLooking at that link, that line in
GetNextTargetRequired(...) is calculating
nTargetSpacing for both PoS and PoW blocks. And is a constant for PoS blocks.
I don't quite understand what (60 seconds)*(
1 + pindexLast->nHeight - pindexPrev->nHeight) represents for PoW blocks only? Because I don't really know what the context of
pindexLast and
pindexPrev are themselves? Or in relation to each other?
Then later, the return value of the function for both PoW and PoS uses the same PoW limit number
bnTargetLimit as an upper limit. Seems "strange", superfluous or wrong, to do it for PoS blocks? Or am I missing something. Your proposed changes in this area maintain that "strangeness" at the end of the function.
I would prefer to see a clear block of code for PoS and another for PoW, even if they share some similarity. Compilers for a long time, I believe, can factor and reduce common sections with no trouble.
Looking at
GetNextTargetRequired(), I see that it is called twice by
CreateNewBlock(...), first with a PoS block and then with either a PoS or PoW blocks. And lastly in
CBlock::AcceptBlock() for either block. I can't quite see how all these things are related! And of course there is no bitcoin documentation! So your changes in this area are just as opaque to me as the original code. I predict that I cannot predict the behavior of the old code or your new code!! Even if all peers/nodes switched tomorrow, I have no clue how this "consensus" code would fare against a miner running his own "ignore PoS blocks" consensus code, or some other exploit!? (LOL)
. It's just that blocks sequences with fair, community composition don't score enough chaintrust to be considered "main" by peers.
...
Perhaps the code could "cook" a PoS block if no PoS (or PoW) one appeared after one minute, "randomly" rewarding someone or no one with a minimum PoS amount, whatever that is? Perhaps a minimum reward to the development team to goad them on to greater heights so that the coin will become popular enough that the minimum reward blocks would not be necessary? Perhaps those rewards could go towards funding a new feature, like the built in explorer or the live price display (LOL).
Cooking can be referred to mining or minting. We could also proof-of-stake cook more often, if our blocks wouldn't be ignored.
And what if main chef decides to ignore transactions?
There could be other problems too, depending on addressing issues with small PoS blocks.
What probelems are there with PoS blocks that are too small? Is it some kind of flooding the block chain with "dust" as it were?
Described
here.
Looking at that link I see the phrase:
However after recent 51% attack it is not clear yet if pure PoW chain takes less time to make than hybrid chain due to PoW difficulty getting raised after each PoS block.
I thought the change was to up the PoW difficulty after (two) consecutive PoW blocks? Perhaps you meant trust instead of difficulty? I'm confused since it seems to be the same, PoW difficulty++ after either PoW or PoS block??
I am just not sure if presumption about PoS blocks with more stake ever got more trust than those with small stake.
I guess all I can say is that if we do do these changes, they would have to be "synchronized" by some date-time and or block number or some such so that all s/w switches together. The
bitcoin-ers seem to talk about this a lot, lately, as they contemplate a block size limit change upwards.
Ron