# How many stale blocks can be minted in 1.7?

**URL:** <https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322>\
**Category:** Uncategorized\
**Created:** [June 19, 2021, 9:24pm UTC](https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322 "2021-06-19T21:24:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![doebrmann](https://avatars.discourse-cdn.com/v4/letter/d/dbc845/32.png) [@doebrmann](https://community.creditcoin.org/u/doebrmann)\
**Post date:** [June 19, 2021, 9:24pm UTC](https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322/1 "2021-06-19T21:24:55Z")

</div>

I saw my mining rig followed  
300~400 stale chain compare to  
block explorer.  
Is it normal situation?  
Stale chain can grow up before connecting to a peer holding main chain?

How does fork logic choice main block?

- highest chain?
- old chain?
- high difficulty?

block a: 26 difficulty block minted at 14:00:00  
block b: 27 difficulty block minted at 14:00:01  
block c: 28 difficulty block minted at 14:00:59  
a,b,c are from same parent block.

block c is regareded as promising to be included main chain in 1.7?

Let me know how to calculate weight of chain  
and when does fork fuction start working

- after 30 blocks trailing?
- every 30 minues?
- when meet different block?

---

<div class="post-metadata">

**Author:** ![taelimoh](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.creditcoin.org/taelimoh/32/3_2.png) [@taelimoh](https://community.creditcoin.org/u/taelimoh)\
**Post date:** [June 20, 2021, 6:26am UTC](https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322/2 "2021-06-20T06:26:21Z")

</div>

We see nodes occasionally creating long forks, especially when they lose “good” peers and get isolated. By good peers, I mean a node connected to other nodes and propagating the heaviest blockchain of the network to my node. When a node gets isolated, it will start mining by itself, continuously growing its fork.

Given multiple forks, the node chooses the heaviest one. The weight of a fork is the sum of the difficulty of each block in the fork. In your example, a node will choose Block C since that is the heaviest.

A node resolves forks whenever it encounters one.

You can read how the node compares forks in the link below. I will circle back w/ a plain English explanation later. I want to answer your other questions first.

[https://github.com/gluwa/Creditcoin/blob/dev/Creditcoin/PoW/PoW/](https://github.com/gluwa/Creditcoin/blob/dev/Creditcoin/PoW/PoW/) **init**.py#L657

---

<div class="post-metadata">

**Author:** ![doebrmann](https://avatars.discourse-cdn.com/v4/letter/d/dbc845/32.png) [@doebrmann](https://community.creditcoin.org/u/doebrmann)\
**Post date:** [June 20, 2021, 8:37am UTC](https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322/3 "2021-06-20T08:37:14Z")

</div>

thanks again.  
I understood.  
how do you think about  
this mining strategy

- start solving quiz with higher difficulty by increasing original difficulty
- if found nonce, never solve quiz again,  
but just wait next quiz.
- close connection to peers if stale blocks are increasing.

IMO,  
When I examine the main blocks  
the main block difficulty is not much higher  
than i expected.  
1 or 2 higher than given condition.

---

<div class="post-metadata">

**Author:** ![taelimoh](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.creditcoin.org/taelimoh/32/3_2.png) [@taelimoh](https://community.creditcoin.org/u/taelimoh)\
**Post date:** [June 20, 2021, 8:48am UTC](https://community.creditcoin.org/t/how-many-stale-blocks-can-be-minted-in-1-7/322/4 "2021-06-20T08:48:52Z")

</div>

1.7 has a similar strategy implemented already. When it successfully mines a block, and it took less than the goal block time, instead of mining the next block, the node continues to mine the current block, hoping to mine a block with greater difficulty than the current one. The idea behind the strategy is similar to yours, optimize for the weight, not length.

I want to note that we will see fewer forks as the difficulty of the network increases, which we expect to happen soon.
