I just analysed the reasons for why my pool minted an orphaned block.

Here is the sequence of events:

My pool minted block No=1 in its allocated slot=28 at T=28.050 seconds. This block propagated across the network and was received by other, not directly connected, relays within 1 second (ie. by T=29 seconds).

My pool and other relays received block No=0 which was generated in slot=0 at T=30s. This block is 30 seconds delayed; it arrived 30 seconds after it was produced at T=30. However, this block predates my block and contains transactions which my block included. This results in the cardano node switching tip to this block No=0 and invalidating my block.

So here is the problem:

Lets say I wanted to increase my stake pool rewards.

Every time my pool is due to mint a block I could disconnect my relays from the block producer. Then wait for the block to be minted and wait another 30 seconds or more. Then connect my relays to the block producer. The relays would then pull the freshly minted block and other connected nodes would in turn pull the minted block and it would propagate across the network. The net result is a block delayed by 30 seconds or more.

Any other pools that mint a block during this 30 second or more window of time will get their blocks invalidated.

Thus selfish mining / denial of service on Cardano ??????????

Addition: 2012-12-17:
Timestamp seconds are actual values and last 2 digits of block and slot numbers are also actual values.

xx:xx:45 cardano-node: TraceNodeIsLeader  
xx:xx:45 cardano-node: block String "yyyy" Number 48 blockPrev "wwww"  
xx:xx:45 cardano-node: Chain extended, new tip:yyyy at slot 74  
xx:xx:45 cardano-node: TraceAdoptedBlock  
xx:xx:45 cncli-sync: block 48 of 48, 100.00% synced  
xx:xx:46 cardano-node: TraceNodeNotLeader  
xx:xx:47 cardano-node: TraceNodeNotLeader  
xx:xx:47 cardano-node: BlockFetchDecision SlotNo 45 blockPointHash = zzzz  
xx:xx:47 cardano-node: Block fits onto some fork: xxxx at slot 45  
xx:xx:47 cncli-sync rollback to slot 19  
xx:xx:47 cardano-node: Valid candidate xxxx at slot 45  
xx:xx:47 cardano-node: Switched to a fork, new tip xxxx at slot 45  
xx:xx:47 cardano-node: Ignoring block already in DB: xxxx at slot 45  
xx:xx:47 cncli-sync block 48 of 48, 100.00% synced  
xx:xx:48 cardano-node: TraceNodeNotLeader  
xx:xx:49 cardano-node: TraceNodeNotLeader  

Note that my block was produced at time = 45 seconds for slot = 74. The delayed block was produced 29 seconds before this (at time = 16 seconds) for slot = 45 but was received at time = 47 seconds.
Upon receiving this delayed block, the cardano-node rolls back to the block prior to this delayed block (block at slot = 19) and then adds the delayed block for slot = 45.
Now my block for slot 74 is invalid - presumably because it contains transactions that were in the delayed block and it has the same block number of 48.

Note: Cardano slots occur every 1 second.

Immediately after seeing these logs I did the following cncli query:

cncli validate --db db/cncli.db --hash yyyy

"status": "orphaned",
"block_number": "48",
"slot_number": "74",
"pool_id": "blahblah",
"hash": "xxxx",
"prev_hash": "wwww",
"leader_vrf": "blahblah"

My block is orphaned!

cncli database records:

select id, block_number, slot_number, hash, orphaned from chain where block_number > 40 and block_number < 52;
35|          46|         xx|vvvv|0
36|          47|         19|wwww|0
37|          48|         74|yyyy|1
38|          48|         45|xxxx|0
39|          49|         xx|zzzz|0
40|          50|         xx|aaaa|0
41|          51|         xx|bbbb|0

1 Answer 1


Update 12/13/2021:

My first question on Cardano Stack Exchange was What is the Penalty for Running 2 Block Producer Nodes? Which I was told, "Network can penalize." But I never received an answer as to what that penalty was, which I believe is because there is not a penalty.

With that said, I believe your question is a result of a pool running 2 block producing nodes with the same keys. When one of these pools is elected slot leader and creates a block they actually create 2 blocks. 1 of these 2 blocks will be orphaned, but damage could be done to other pools before that happens (like your case, I believe). With the 2 blocks propagating, it is possible that a pool, let's call it pool A, creates their next block on the losing, bad block. If this happens, pool A is going to have their block orphaned when the chain is rolled back to fix the duplicate block issue. This is what I believe happened to you.

With that said, your comment about disconnecting the relays from your BP for 30 seconds still wouldn't work to cause this. If you wanted to cause this you would have to run 2 block producer nodes. Which I do not recommend, and as a community, we should figure out how we are going to penalize these pools.

Here is a reference: https://www.reddit.com/r/CardanoStakePools/comments/rdzbhq/two_years_after_reporting_a_problem_with_cardano/

Original Answer:

I believe this happened because you lost a slot leader battle. So basically the other pool you were competing with had a better overall propagation time and that is why your block was orphaned. From your point of view, it looks like your block had the better propagation time but that is because you are looking at the nodes you are connected to.

As far as waiting 30 seconds to try to cause a DoS attack, it wouldn't work and you would just orphan your block. This is because even if there isn't another slot leader to take that block, another block will be created in 20 seconds that will create the new longest chain.

I hope this is helpful!

  • No evidence of slot battle. cncli validate says my block is orphaned. Also the logs do not show another block for the same slot as my slot. Instead the logs show that this earlier block arrived 30 seconds late which was 2 seconds after my block was minted. Then the node switched tip to this earlier block, invalidated my block causing it to be orphaned.
    – 74d4
    Dec 7, 2021 at 21:13
  • Can you share the specific slot, block and logs you are looking at? Dec 7, 2021 at 23:58
  • The logic in my question post seems correct. Watch the NerdOut video by Andrew Westberg: youtu.be/4j_SymkuxfU
    – 74d4
    Dec 11, 2021 at 21:09
  • Re: Update 12/13/2021: I have checked the cncli database on my node and there was only 1 block produced by the previous block producer which was delayed 30 seconds. My block producer produced its block when it should have (and I do only run 1). The previous block producer's block arrived 30 seconds late which happened to be 2 seconds after my block was produced with the same block number. Because this delayed block was for an earlier slot all the nodes in the network switched tip to this delayed block and invalidated my block.
    – 74d4
    Dec 13, 2021 at 23:33
  • 1
    I updated the question with logs and data from cncli database.
    – 74d4
    Dec 17, 2021 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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