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:	08cf7b4
Status:	✅  Deploy successful!
Preview URL:	https://6a1ba886.rfcs-6p3.pages.dev
Branch Preview URL:	https://sw-pow-changes.rfcs-6p3.pages.dev

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. I fyou 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)