Does tezos node have any kind of protection that rejects a block that has already been injected from being injected again?

I'm trying to test my accuser module, but can't make any double baking.

If my app has already baked that block, when I try to inject it a second time I get this.

[{"kind":"temporary","id":"failure","msg":"Fitness too low"}]

Is there any kind of protection on the nodes already that rejects double injections of the same block?


Looks like that is now impossible to double bake while using tezos-node binary. Just tried to double bake with 2 different nodes and every injection that comes in second place gives a [{"kind":"temporary","id":"failure","msg":"Fitness too low"}].

  • Looks like that is now impossible to double bake while using tezos-node binary. Just tried to double bake with 2 different nodes and every injection that comes in second place gives a [{"kind":"temporary","id":"failure","msg":"Fitness too low"}]. Commented Apr 17, 2019 at 14:10

1 Answer 1


There are a few issues here.

What is double baking/endorsement?

It is important to understand that the doubling penalty has little to do with injection. The crime is signing two different blocks or endorsements, with different hashes, at the same level. Injection is just one way for your crime to be discovered.

You can safely inject a single block or endorsement, identified by its hash, any number of times into any number of nodes.

On the other hand, you could be punished for signatures of blocks or endorsements which were never injected at all, only included in the evidence operation.

So, a warning. You should not rely on mechanisms which prevent double injection. You should prevent double signing, using level high watermarks, like the baker, endorser, signer, and Ledger app. Double signing is the crime. Trying to prevent double injection is trying not to get caught.

Now, let's see how to double bake...

Fitness too low

First, the /injection/block RPC rejects unfit blocks. To force injection of unfit blocks, you can supply the force=true query parameter, mentioned in the docs.

Deterministic signatures

With a deterministic signature scheme (like tz1/ed25519, but not the others), if you sign the exact same block or endorsement data twice, you're going to get the same signature. Then the resulting block/op hash will be the same. Since it is the very same block/op, there is no doubling.

So, to cause double baking with tz1, you need to modify the block data between the two blocks, e.g. change the timestamp or operations.


Here is one relatively easy way to double bake in a sandbox:

tezos-client rpc get /chains/main/mempool/pending_operations | jq '.applied = []' > /tmp/empty_mempool.json
tezos-client endorse for bootstrap1
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json
# fix the path, for your TMP SANDBOX (!) client
# DO NOT delete your real "blocks" file!
rm /tmp/tezos-tmp-client.XXXXXXXX/blocks
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json

This works because:

  1. bake for uses the current timestamp by default, so if we wait a bit between bakes, the timestamp in the block data will be different, resulting in different blocks (even with tz1.)
  2. The node validates the block, and the accuser picks up on it.
  3. However, because we injected an endorsement but baked with none, the node then ignores the block. This makes it easy to repeat the bake, because the head will still be at the previous level.
  4. Finally, we subvert the baker's double bake protection, by removing the "blocks" high watermark file.
  • Thanks for your answer! Commented Apr 18, 2019 at 9:27
  • Tom, do you know why the accusers don't detect like 50% of double bakings, on zeronet sometimes my double bakings aren't detected, for example, sometimes my accuser is able to detect my double baking while others don't and sometimes my accuser doesn't detect and others do. This one was only detected by my own accuser: imgur.com/OTCv0uj This is because I'm making an accuser module for my baking app and I want to make sure everything is working correctly. Can that be a problem with "/monitor/valid_blocks" that doesn't track every valid block as it should? Commented Apr 22, 2019 at 20:39
  • @Seb Mondet already answered. "In general the network will propagate blocks that "improve" the fitness. So if your baked block has not been endorsed, accusers are not likely to see it and inject the accusation." "Overall the accusations are designed to penalize really annoying actors, not just accidental double-bakings that don't slow-down or hurt the network." "(it can still happen that in somewhat unlucky circumstances, an accidental double-baking gets accused of course)" Commented Apr 22, 2019 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.