A Penalty System for Delayed Block Submissions


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…


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.


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.


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)


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.


Block penalties are determined based on when they are witnessed publicly. How is the witness “time” recorded, and how is consensus reached regarding when a block was witnessed?


It’s not based on time; it’s simply the order of receipt.

If I’ve already received blocks a2000 through a2007, and then someone sends me a different set of blocks numbered b2001 through b2010, I don’t immediately accept them as replacements for a2001 through a2007. This isn’t because b2001 was received at a later time or contains a later timestamp; it’s solely because b2001 was received after a2007 - it’s late by 7 blocks.

A long as I receive the blocks in an order, I can use this method to accept the blocks or to delay acceptance of “delayed” blocks - and so can any other node - with no consideration of the time.

That will make it more stable, but also means that waits of 3 or 4 blocks are not given any additional protection. The scheme adds a lot of protection to longer chains (better than the current situation!), but the scheme is not helpful in short spans (perhaps there’s a better solution?)

I’m afraid I don’t intuitively see how that helps. Remember, I’m talking about a smaller chain - the malicious attacker will have more hashpower than the authentic chain, so whether you count by blocks or count by accumulated difficulty, the attacker will have more - a two-part attack will be made with blocks mined at higher difficulty.


I don’t mean “time” as in a timestamp. That was a poor choice of words. I referring to when a new block is witnessed by the network, which in the whitepaper is stated to be by block interval, which I interpret to be the block height.

However, the question I have is still the same, and refers more directly to how it would be implemented. When a block is witnessed by the network for the first time, how and where is it recorded that this new block was witnessed at a specific block height?


The method being discussed here is not based on when a block is “witnessed by the network.” It’s based on when a block is received by a given node, and I should think it takes place entirely within the node with no external relay or recording.

The node’s local database should record the order of receipts in the journal - that’s sufficient information for the node to be able to perform the necessary functions, even if the node needs to be restarted while a contentious pair of chains are still growing.


If block penalty scoring is determined locally only, this means that different nodes can have different viewpoints on what the correct tip is even after they are fully back in sync. This is mitigated for short-term connectivity problems if the penalty does not come into effect for the first x block intervals. For longer durations, a fully synced node may continue to follow the wrong tip for an extended period. My concern being that there may be a way to exploit this by using it in reverse.

One theoretical attack could involve targeted DDoS attacks against pools. It strengthens the attack since the pool may continue to mine its own chain even after the DDoS has ceased and the blocks have fully synced. If gone unnoticed, this could result in the pool mining on the wrong tip for an extended period. If launched against multiple pools in a series, this could result in a temporarily weakened network. A 51% attack would still be very difficult, but it may increase the success of greedy mining.


Right - by not imposing the penalty for forks of 1 or even 2 blocks, the likelihood of this from natural mining becomes quite low.

I agree. We need lots of thought and experimentation around potential new attack vectors. So long as the new attack vector is more costly than current attack vectors, the approach is still conferring a benefit.

Good point; my thinking tends to focus on how much it raises the cost of a 51% attack, and have thought about nuisance attacks against the coin, but you’re right to expand the concern to pools & other parts of the system that could be targetted.

Having said that, I should think pools don’t make their full node addresses publicly available, which should insulate them against direct DDoS attacks, no? (Though I suppose a devoted attacker may be able to ferret that out over time on the network as blocks are broadcast from the node.)


Pools generally route through services which are designed with DDoS attacks in mind. However, the success of these services to mitigate said attacks can vary heavily based on protections offered by the service and the sophistication of the attack. And yes, with enough dedication the attacker could probably determine details about the node if it was going through one of the more common economical services.

Pool operators for growing coins have often been targeted for DoS attacks at some point and time. This has definitely proven true for Zencash. Many of the pools, especially the smaller operations with minimal operating budgets, lack any form of sophisticated protection. Solo miners are even more likely to run bare clients without any form of protection at all.