feat: adds tip004 pow changes

[SWvheerden]

Description

adds a proposed changed to change how the difficulty is calculated

[gemini-code-assist]

Code Review

This pull request introduces a new proposal document, TIP-Proc-MT-0004_MinoTari_PoW_Difficulty_changes.md, which outlines proposed changes to the MinoTari Proof-of-Work (PoW) difficulty adjustment mechanism. Specifically, it proposes an exponential backoff mechanism for consecutive blocks mined by the same PoW algorithm to prevent a single algorithm from dominating and causing disproportionate reorgs. The review feedback suggests fixing a broken relative link in the TIP metadata table, resolving an undefined markdown link reference [OEP], and removing an empty list item.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[PotR3288]

I would support this change, despite it requiring a hard fork. It would reduce the ability of an attacker to 'rock the boat' and depress one algorithm's difficulty either to attempt a reorg or to gain an advantage with a timed burst of mining on the depressed algorithm.

• Is 2 the right multiplier?
• Would a graduated increase be a softer brake? (1.25x after the second successive block, 1.5x the third, etc)

[m4r1m0]

I would support this change, despite it requiring a hard fork. It would reduce the ability of an attacker to 'rock the boat' and depress one algorithm's difficulty either to attempt a reorg or to gain an advantage with a timed burst of mining on the depressed algorithm.

* Is 2 the right multiplier?

* Would a graduated increase be a softer brake? (1.25x after the second successive block, 1.5x the third, etc)

If the goal is to stop reorgs on a network with as little nethash as Tari currently has, a more gradual increase like you suggested wouldn't sufficiently mitigate the threat of reorgs. It needs to be be a stiff penalty for consecutive blocks.

I think the exponential increase is the right move.

[Kelketek]

@SWvheerden Small comment on the header, but otherwise this looks good to me. Exponential backoff as a mitigation to making any lane dominant seems straightfoward to implement and likely to resolve immediate issues.

[cloudflare-workers-and-pages]

Deploying rfcs with    Cloudflare Pages

Latest commit:	d9bcdb5
Status:	🚫  Build failed.

View logs

[stringhandler]

I don't think this will solve the problem.

Some faults off the top of my mind:

1. If you are behind on C29 blocks, multiple C29 blocks are hard to mine in succession.
2. If you interleave 2 algorithms, there is no penalty.

If anything you should adjust the target time for the other 3 algorithms when a C29 block has not been mined. This strategy is complicated and also flawed.

You would have to find a sequence in the chain's history where this proposal would have actually made a difference.

From my experience with P2pool, trying to artificially limit POW does not have the desire effect, and often has the reverse of what you are trying to achieve.

[SWvheerden]

I will address you comments here quick:
1: this is not to let c29 or behind algo catch up, its stop a single high hash rate actor mining a bunch of selfish blocks and reorging the chain.

2: This will only work with RxT/RxM as they hardware is the same, but also not 100% as you need to closely match the PoW of the network for that algo. Tari's PoW is calculated as Sha * C29 * RxT * RxM.
If you do the algobra math, you can write it out, as this, worse case say all sha3 miners collude to selfish mine, that means that the network will compare:
a: (Sha +x) * C29 * RxT * RxM
vs
b: Sha * (C29 + y) * (RxT+ z) + (RxM * w)
Most cases b will win. If you write out the algebra, you get that for Sha to win, you need
x >
sha(z/Rxt + y/c29 + yz/RxtC29 + w/Rxm + zw/RxtRxm + yw/c29RxM + yzw/c29RxM)

Which you further boil down to:
x/Sha3 > y/c29 + z/RxT + w/Rxm

This can be seen the (Sha3 % increase) > (C29 % increase) + (Rxt % increase) + (RxM % increase)
this is not very likely, but possible, so if you double the sha mine time, you make it much harder to accomplish.

[stringhandler]

I'm not going to die on this hill, but this still seems dumb to me. Anyway here is what claude thinks:

(prompt: this feels so dumb to me, but I can't explain why. can you have a look and see if you agree with me. https://github.com/tari-project/rfcs/pull/174/changes)

Why the exponential backoff won't work

Accumulated difficulty per unit time equals hashrate, regardless of the target. LWMA sets D = H * T_target, so solve time is T_target and work per second is D / (D/H) = H. The target cancels.

So doubling Sha3x's target makes each block worth 2x and take 2x as long. Over any window longer than a few blocks, x in

x/Sha > y/C29 + z/RxT + w/RxM

is unchanged. Selfish mining costs hashrate x time; the proposal moves neither. "Neutral: does not change the geometric-mean comparison logic" is the tell.

Also:

• Evadable at linear cost. One cheap block on another algorithm resets the counter; RxT/RxM interleave for free.
• Hits honest miners. ~25% of blocks follow a same-algo block. Those are runs, not attacks.
• Slows emission. Inflated targets mean genuinely slower blocks. Not in Consequences.
• Breaks LWMA's estimator. It regresses solve times against target times over 90 blocks; a target jumping by powers of two makes that noisy.
• Invites tip reorgs. Difficulty now depends on the previous block's algorithm, so orphaning the tip resets your counter.
• No cap, no simulation, no historical sequence where this would have mattered.

The fix belongs in the accounting, not the scheduling. The comparison is sensitive to an algorithm's growth rate of accumulated difficulty. Normalize each block's work by that algorithm's recent average difficulty before summing, so a block is worth ~1/N of a chain-block whatever lane it came from — see Zawy's issue #3, already in the References.

Minor: Last Modified (2026-05-17) predates Created (2026-06-11), and the References row still has the Open edX OEP boilerplate.

[Kelketek]

Type is Architecture, per the type definitions

[Kelketek]

@SWvheerden Could you make sure to add the change to the LWMA as discussed in the forum thread and approved by the council? I think we landed on 45, but Kinkajou should remember if neither of us does.

[Kelketek]

Suggested change

-

[Kelketek]

Please bump this upon addressing notes