A Penalty System for Delayed Block Submissions


#1

I just took a look at https://zencash.com/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-ZenCash.pdf, which was posted on the blog.

Great concept! I love that it keeps the system wholly within the blockchain, unlike most Notary Node proposals I’ve seen (which tend to record information on a second chain.) And using the number of “blocks delayed” as a basis for the penalty count is a nice way to introduce a 'time penalty" without referencing actual time, thus avoiding the usual complications (time authorities, etc.)

A couple of concerns occurred to me…

First

At first glance, I immediately fear that natural fork resolution (when 2 different blocks are found at once) gets exacerbated. Normally, if 2 blocks are found, there are two competing chains of length 1, and whoever finds a second block nearly immediately causes their chain to become mainchain for all.

With this delay model, that does not happen, because that adoption is delayed for another block, during which the other chain may well mine another block, extending the competition. It now takes a 3rd block to resolve the split. What would have been a 1-block reversion for a fraction of the nodes will necessarily become a 2-block reversion.

This complication is resolved by simply reducing the delay factor by 1… thus allowing the most common “natural split” to be resolved without penalty, and preserving most of the penalty for actually malicious attacks.

Second

It seems to me that the whole scheme can still be easily attacked, especially for a small hashpower coin, by releasing blocks in two pieces.

To defeat a 6-block confirmation time… the attacker needs to private-mine 27 blocks… and the Exchanges get no extra time to respond.

They perform the attack by releasing 6 of the 27 blocks with the double-spend in the new blocks. The other nodes do not accept this immediately; instead, they impose a 21-block delay. (6+5+4+3+2+1).

Then the attacker releases the other 21 blocks, meeting the delay requirement and completing the attack.

Now, to point out the obvious: WIHTOUT the delay penalty, the attackers only needed to mine 7 blocks. Forcing the attacker to mine 27 blocks is a huge improvement.

For a large hashrate coin, this may be sufficient, but I think the smaller coins may still be quite vulnerable.

This may be improvable by careful tuning… but we need more people smarter than me to think through all the potential negative consequences. For example, what happens when a pool of disconnected nodes gets re-connected to the network - do the penalties cripple the ability to re-sync? We don’t want to exacerbate natural problems - we need the networks to remain resilient!

Looking forward to the discussion on the proposal.


#2

I was going to ask this same thing about the pool. If a big pool disconnects for whatever reason, but miners kept mining, on eventual rejoining what happens?

Also from the document i read:
“Confirmation can not start until a fork is in progress”

This is not clear to me. Confirmations on which chain? Also, does this means anyone with 51% hash power can freeze the network indefinitely as long as he has this power? (Because the confirmations will be frozen while in fork mode)


#3

Hi,
regarding the natural forks we are considering to not apply penalties for forks having block receiving delays lower than 3 or 4 blocks. This threshold would prevent to apply penalties in situation caused by normal network latency / slow block propagation time.

About the second point, the penalty can be calculated also taking in consideration the current mining difficulty. We are currently doing some simulations to evaluate this approach.