We'll all probably get away with it (staking small'ish blocks) for another month or so, but I'm guesstimating that soon enough, we'll stop worrying about hitting the cap, and start worrying about having enough size/weight to stake before reaching 30 days maturity.
Personally, my block sizes are anything between 2K ~ 4K at the moment, but by the end of the month I'll be aiming at 3K+ blocks.
I just realised this could prove bad for network security, since bigger blocks => less block => less security.
I'd like your input on this. Extending max age or removing it altogether (like Blackcoin was the first to do, I think) would alleviate this issue and would lead to ever-diminishing blocks (and would require a hard fork). Difficulty would rise exponentially.
OTOH, after a transition phase from small blocks to large blocks during which network security would be reduced, we would again gain network security because inflation would lead to more block. Security/Difficulty would increase smaller, though (the larger the blocks, the smaller the difficulty rise).
Opinions?
I have no math to back this, but my take is that it will make little difference to security. Large blocks will stake faster, small blocks will take longer, but the network will continue to adjust to meet the time per block specifications. I suspect we'll see wild swings in difficulty as people figure out the optimum (for them) method of staking, but that over time it will stabilize. I'm not fully versed in the difficulty adjustment specs for HyperStake, but I believe it readjusts with every block, so the security risk is minimal.
Here are fragments of code that calculates the target (main.cpp source file):
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();
.......
// ppcoin: target change every block
// ppcoin: retarget with exponential moving toward target spacing
CBigNum bnNew;
bnNew.SetCompact(pindexPrev->nBits);
......
int64 nInterval = nTargetTimespan / nTargetSpacing;
bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
bnNew /= ((nInterval + 1) * nTargetSpacing);_______________
pindexPrev->nBits - the target of the previous block;
nTargetTimespan - 1 hour (3600 sec.), it is used as the max calculated spacing time;
nTargetSpacing - 90 sec.;
nActualSpacing - the time between the previous block and its predecessor;
Retargeting is smooth as it is done in an exponential manner. The target is decreased/increased in a bigger proportion if the previous decreasing/increasing wasn't enough.
I haven't found any other conditions of the target adjustment in the code yet. Looks like it complies with original bitcoin specs.