Adaptive blocks proposal


#1

Is this good solution for Peercoin?


#2

I’m a big fan of this solution to the block size debate.
It is resistant against surges and prevents new block size debates in the future.

There are other block limits that should also be adressed like the maximum number of OP_CODES per block.
But let’s take it one step at a time.

I’m voting for an adaptive blocksize.


#3

Moved from private subforum to public, I ask everyone for opinion about this.


#4

Another vote here. Adaptability usually wins.


#5

Added a medium article explaining for non-developers.


#6

I also think it would be good, but we cannot use their implementation. It uses floats in consensus code, and the size limit of a block is calculated from the parents of the current best block, not from its own parents.

If we implement the rule correctly then it raises the problem that we cannot check the size validity of an orphan block. It may not be a critical problem because the size would still be limited by the message size limit (MAX_SIZE) which is currently 32 MB, and an orphan block still needs a valid and unique proof of stake. But an attacker with a large stake could possibly affect low memory nodes by propagating large orphan blocks each time he finds a proof (instead of getting the reward, which he can get later and he would only lose compound interest).

A possible solution could be to have a special rule for orphan blocks (that may depend on the best block). A better solution would be to calculate the block size limit from an earlier block, for example when the stake modifier of the proof of stake was calculated, because since we were able to validate the proof of stake we also have a reference block where the modifier was generated. Another option would be to prevent the orphan block list from growing too much (which we should probably do that regardless of this issue).


#7

Yes solid remarks!

Using floating point numbers in consensus is a bad idea, but that should be a trivial fix.

A solid review and maybe reimplementation of the code is definitely required, but I’m happy you agree on the concept.