Some questions about difficulty and fork

Mining
1

The block difficulty is adjusted(-1 ~ +1) every 10 & 100 block.
Most of all block difficulties were changed as intended like that.

[Difficulty sequence]
#80020 26-26-26-26-26-26-26-26-26-26
#80010 25-25-25-25-25-25-25-25-25-25
#80000 24-24-24-24-24-24-24-24-24-24
#79990 25-25-25-25-25-25-25-25-25-25

If the SOLVER_PERF succeeded to refine first nonce.
The block difficulty is likely to be increased by more than 1.
But I could find only a few real case as following in the block explorer.

[SOLVER_PERF’s trace]
#80020 29-29-29-29-29-29-29-29-29-29
#80010 25-25-25-25-25-:muscle:30-30-30-30-30
#80000 24-24-24-24-24-24-24-24-24-24
#79990 25-25-25-25-25-25-25-25-25-25

Q1:
Lessons from the real result:

  • It is hard to the SOLVER_PERF to find better nonce?
  • There is no need to find better nonce. If SOLVER_PRIME founds first nonce. It is enough to mine a new block.
  • SOLVER_PERF’s hidden intention is consuming miner’s hash power? :frowning:
  • Is the first nonce recorded only in the block chain?
    In spite of receiving better nonces sent by SOLVER_PERF.

Q2:
In the mining code,
Solvers send valid nonce with given difficulty instead of actual difficulty of sha256 digest.
I think it is intended to manage block difficulty. Right?

If difficulty 20 quiz is given to two miners.

  • Miner#1 found nonce, it’s actual difficulty is 30.
  • Miner#2 found nonce, it’s actual difficulty is 21.

Miner #1 & #2 sent the their own nonce to network at the same time.
How to chioce the best nonce?

  • Is the actual digest considered?
  • If Miner#2 will mint new block. Miner#1 will be :triumph:

Q3:
If a lucky miner founds a 35 difficulty nonce.
While quiz difficulty was just 25.

Finally, the lucky miner minted a new block.
The lucky miner found 35 difficulty nonce again for next block.
And the nonce was accepted.
So, the lucky miner minted 2 blocks(35 difficulty) in a row.

In this case,
Peers connected to the lucky miner will fork(change) their head block to the lucky’s one.

  • blocks of lucky : 35-35-25(common head)-24-24
  • blocks of peers : 25-25-25(common head)-24-24
  • Because lucky’s block difficulty is much higher :
    2^35 + 2^35 > 2^25 + 2^25

But the next block will be very hard(difficulty 35) to mint to most miners w/o any lucky.

The other peers not connected to the lucky miner,
will continue minting blocks with 24 ~ 26 difficulty.
(They are genuine lucky miners?)

The lucky miners and peers will not fork their chains
until the other chain(maybe main chain) aheads their chain by more than 2048 blocks. Right?

  • 2^35 + 2^35 = 2^25 * 2048

How to save lucky miners and peers from the orphan chain before 2048 minutes passes?

2

A1:

  • as hard as the next difficulty
  • Yes, SOLVER_PERF is meant to stop long streaks by giving miners a chance to refine their previous mined block while also working on the next one. If for some reason an incoming block is better than the local, the new incoming block will overtake the local fork. If validation is costly due to performance/networking, the wasted time spent on the next block is high and sets the miner behind. In this version, solver_perf tries to find a better nonce simultaneously to increase the probability of its prev_block being overtaken by the incoming prev_block and win the fork resolution. I agree with you and I also have my doubts about this new impl being ‘fair’, it may be biasing mining even more. But so far streaks are shorter, and no formal counterexample has been found that this impl is harmful, so the impl passed. If you come up with a counterexample we can discuss it.
  • Of course, nothing is free.
  • On finding a better nonce, the AuxPublisher rebuilds the candidate block with the new consensus. This is the new refined block and all blocks are published just like regular blocks. Thus, the refined difficulty will be in the chain.

A2 Actual difficulty is what stays in the consensus, Miner #1 will win. We have under discussion including the given difficulty in the consensus as you said for performance reasons.

A3. That doesn’t sound like luck. In your example: That is not a common head. Difficulty differs. And fork resolution should trigger immediately; if the nodes were peered. If they weren’t it is just a normal fork, and fork resolution will trigger once the two clusters communicate. In the example above, the lucky peer cluster would win fork resolution. I don’t think fork resolution works like the “2048” expression you show.

3

Thanks for your detailed reply.
As you said at another thread,
It looks like there are many clusters on the network.
And clusters does not meet(say hello~) other clusters.
So the ideal fork does not occur as expected.

Think about this case.

  • Cluster #1 :
    Try to refine nonce as implented.
    They will need more and more time to solve quiz as time goes.

  • Cluster #2 :
    We give up finding better nonce, We just focus on finding first nonce ASAP.
    We try to solve as many as we can before meeting Cluster #1.

After an hour, two clusters meet,
the fork solution will calculate the difficulty of each cluster’s block.

  • Cluster #1’s blocks :
    Heavy difficulty but few blocks.(5 blocks)
    { difficulty: 30-30-31-32-33 = 2^30+…2^33 = 17179869184 }

  • Cluster #2’s blocks :
    Light difficulty but many blocks.(64 blocks)
    { difficulty: 28-28-28-28-28-…28 = 2^28 * 64 = 17179869184}

Two cluster have same difficulty.
But I think Cluster #2 has more possibility to win on the fork.
Because it is more easy to solve one more 28 difficulty-quiz for 1 hour
than finding 5 nonces of 30 above difficulty-quiz during 1 hour.
I think a quiz which difficulty is greater more 30 is pretty hard to solve.

As I said before
SOLVER_PERF’s trace is hard to find in block explorer now days.

4

The problem that I see here is how to avoid small clusters, we are working on a better gossip protocol. The dynamic difficulty should tweak the difficulty to reach the target of one block per minute. It may be true that the AuxPulisher can bias difficulty upwards, I have expressed my concerns about this before, but haven’t come up with a strong argument yet. If what you said is true, there’s no way to help Cluster #1 in the current impl. When the next consensus is set to work it uses the difficulty calculated over the original previous block. when the refined block is published, the difficulty chain gets updated and there may be new difficulty requirements imposed over the consensus that has already been started (Solver_Prim), the miner could trash its own block at validation if the new diff requirement (refined previous_block) at validation is higher than what SOLVER_PRIM was trying to solve. I’m just guessing as I didn’t check the code while thinking about this. Anyway, this is a different issue than what you are concerned about. Under your current simplified example Cluster #2 would win (at difficulty tie, longer chain wins). Maybe we could weight the aggregated difficulty differently by giving more weight to the early blocks in the fork to avoid something like:

28-30-30
being more likely to lose against
30-30-28

I think in the current impl it should look more like this.
28-30r-28 ← wins (PoW with 2 solvers)
vs
28-28-28 (PoW with one solver)
Dynamic fork difficulty may increase difficulty over time, due to refined blocks but, because the publishing rate target is till 60seconds, difficulty on the long run will be higher only if the cluster can afford it, So in difficulty equilibrium a miner without a SOLVER_PERF doesn’t have advantage afaik. Assuming dynamic difficulty works as intended.

5

I also agree with you that mining streak becomes more shoter than 1.6.
And giving more weight to earlier blocks sounds like so reasonable.
I hope the improved gossip ptorocol will come to us very soon.

Thanks again.
Have a nice Friday.