old c coder, I considered your comments and realized you made very substantial arguments.
Therefore I've made changes:
GetPoWPoSRatio() function now returns double, and there is new GetSpacingThreshold() function that adjusts, rounds and converts that ratio to integer.
Now Proof Of Work target moving average does not get stored in PoS block's nonce attribute. I've added to CBlockIndex class new member nBitsMA for that purpose. Like you said - having it in PoS block's nonce was not needed, and second: I think it is even better, if we can keep PoS nonce at 0 and force PoW blocks have nonce>0. That is how we will be able to easily differentiate blocks in future and derive chaintrust only from headers.
Next I've managed to complete code upgrade. I've split github commits into logical contexts. I suggest you start scrutinizing from oldest one on, because that functionality get's reused in later commits.
Last commit will need to be explained, but in short: it deals with small value ProofOfStake blocks in a way Balthazar mentioned more than a year ago (the need to make attack energy expensive). I had a complex solution for that, but then I came up with a better one: reuse scrypt-jane and transform stake kernel hash operation to use memory(scrypt-jane) for hash, and stakeNfactor used gets calculated from stake kernel value. I also introduced new higher dynamic threshold - you now need more than 20 coins (in one input) to generate stake and that value is incrementally increasing. Again, a lot of explaining needed here, also regarding optimizations...
First, I need proficient eyes to take a look and raise flags on possible obvious errors.
Unfortunately I do not have resources to test this, so this is done kind of Beethoven style (after he went deaf).
But I think we can make it work.
here:
https://github.com/senadj/yacoin/commits/smallpos
Therefore I've made changes:
GetPoWPoSRatio() function now returns double, and there is new GetSpacingThreshold() function that adjusts, rounds and converts that ratio to integer.
Now Proof Of Work target moving average does not get stored in PoS block's nonce attribute. I've added to CBlockIndex class new member nBitsMA for that purpose. Like you said - having it in PoS block's nonce was not needed, and second: I think it is even better, if we can keep PoS nonce at 0 and force PoW blocks have nonce>0. That is how we will be able to easily differentiate blocks in future and derive chaintrust only from headers.
Next I've managed to complete code upgrade. I've split github commits into logical contexts. I suggest you start scrutinizing from oldest one on, because that functionality get's reused in later commits.
Last commit will need to be explained, but in short: it deals with small value ProofOfStake blocks in a way Balthazar mentioned more than a year ago (the need to make attack energy expensive). I had a complex solution for that, but then I came up with a better one: reuse scrypt-jane and transform stake kernel hash operation to use memory(scrypt-jane) for hash, and stakeNfactor used gets calculated from stake kernel value. I also introduced new higher dynamic threshold - you now need more than 20 coins (in one input) to generate stake and that value is incrementally increasing. Again, a lot of explaining needed here, also regarding optimizations...
First, I need proficient eyes to take a look and raise flags on possible obvious errors.
Unfortunately I do not have resources to test this, so this is done kind of Beethoven style (after he went deaf).
But I think we can make it work.
here:
https://github.com/senadj/yacoin/commits/smallpos
Hello Senj,
I have been thinking about the code and wondering if one could "slow down" the PoW "attack" by requiring (or making it more "atractive") to have a PoS block between PoW blocks?
The current miner code, in the daemon & Qt code has this line in the function:
void BitcoinMiner(CWallet *pwallet, bool fProofOfStake)
{
...
if (fProofOfStake && pindexPrev->IsProofOfStake())
{
bool
fFastPOS = GetArg("-fastpos", 0);
if (!fFastPOS)
Sleep(500);
continue;
}
...
}
Which suggests to me that two (consecutive/contiguous) PoS blocks aren't allowed. Could we add a similar:
if (!fProofOfStake && !pindexPrev->IsProofOfStake())
{
bool
fFastPOS = GetArg("-fastpos", 0);
if (!fFastPOS)
Sleep(500);
continue;
}
or some such, forcing a PoS block? At the moment the average block period goes up sometimes over 5 minutes, I presume because there are few miners mining and the "difficulty" is high? Is there too much risk that no one online can PoS and so stop the flow of blocks? I said somewhere that perhaps being able to mine every block instead of every other block as a PoW one may be the "break-even" money point (at ~ 1minute/block average period) that makes this ploy worth doing. If he/she/they can PoS along with someone else, would the code the rest of the nodes are running fairly allow one or the other PoS block and reject the other, even if the greedy miner adds a PoW block onto the "weaker" PoS block.
Just musing... on to the unit tests in a separate message
Ron