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:	90f131e
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.

[SWvheerden]

I was treating that as a separate move, but we can do it here as well.

[Kelketek]

Suggested change

-

[Kelketek]

Please bump this upon addressing notes

[Kelketek]

@SWvheerden Looks good to me! 👍 Matches my understanding of the approved changes.

[m4r1m0]

* **Evadable at linear cost.** One cheap block on another algorithm resets the counter; RxT/RxM interleave for free.

Yes, you're right about this. The Kryptex bot could very well just move hashrate between the two lanes and attempt to gain a profitability advantage that way. This is much more difficult to execute in practice though and still prevents offline reorgs/selfish mining attacks.

• Slows emission. Inflated targets mean genuinely slower blocks. Not in Consequences.

This is concerning. Do you have any data to back this up? We're already sitting on a 3min blocktime average fairly regularly depending on the window - and this is one of the main things I'd like to fix with this change.
It's also by far the most clear result from every single simulation I've run - max block times get reduced by a minimum of 10-12%. Every single simulation. The median goes up but the max goes down. This is the single most consistent result I've gotten.

The fix belongs in the accounting, not the scheduling.

I agree with you here. This was the focus of my initial suggestions, but changing the difficulty algorithm entirely is a much larger fix and it was my view that this was a much less contentious way to go about solving the immediate issue of daily reorgs and 20min+ blocktimes. We discussed scheduling another, permanent improvement, for 6months out.

• No cap, no simulation, no historical sequence where this would have mattered.

I beg you, and everyone here, please go use my sim https://github.com/m4r1m0/tari-diff-sim/tree/main
Obviously I also asked AI before I published my initial proposal and came to a different conclusion.

You can attach your own historical block data. You can craft fictitious block data and slap it in there. I spent 3 days extra moving my python over to JS so people would audit and test my work/run their own simulations.

I don't want to be the guy responsible for making the network worse, that's why I relied on simulations and data to support my assertions and published the code and methodology for others to audit rather than just taking the AI at it's word.

[stringhandler]

I beg you, and everyone here, please go use my sim https://github.com/m4r1m0/tari-diff-sim/tree/main

I appreciate the work there. However, I might be missing it, but there doesn't seem to be a simulation of the problem stated in this PR.
There certainly are many factors to consider, but the problem stated in this PR: If one algorithm suddenly has a spike in hashrate due to ASICs/New pool/Active attack, bad things happen. The main "bad thing" is that other algos don't get mined.

So I would expect a simulation to have that. Selfish mining would make the most sense to simulate (apologies if you have this and I missed it). Assuming a bad actor, with 2x the hashrate, and the exponential increase in target time will this proposed change:

1. Allow other algos to be mined?
2. Keep the block time low?

I suspect that, even with the doubled target time, the difficulty difference does not change. In that case you would see:

1. More reorgs of lesser algos.
2. Consecutive blocks at 2x the target time. (i.e slow emission)

In which case this solution makes the problem worse. The selfish mining scenario is not an unlikely scenario. We have already seen it with qubic's attacks on monero.

[SWvheerden]

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

In theory, I think there is something here, as the amount of work done over a large period is still the same. But as your target time increases, you give more chance for the other algo's to increase their work percentage-wise to catch up.
With this here the devil will be in the detail, and I will rework this to better show what we want, as the idea is not to break the lwma, its to force the double blocks to take longer to mine. But the increased difficulty should not count towards the geometric mean, as that will offset the penalty.

Also:

• Evadable at linear cost. One cheap block on another algorithm resets the counter; RxT/RxM interleave for free.

This is true, nothing we can do about this, its a free swap between this. But at the same time it wont really work for RxT pools as their hash rate is lower than RxM. It will only work for RxM.

• Hits honest miners. ~25% of blocks follow a same-algo block. Those are runs, not attacks.

A lot of the quick blocks are with pools jumping on and off Tari, this will penalise them as well, which is good.

• Slows emission. Inflated targets mean genuinely slower blocks. Not in Consequences.

I dont agree. It will slow down the emission if its too quick. The slow emmision on the other algo's are due to pool hash rates, which the 45 block window will help.

• Breaks LWMA's estimator. It regresses solve times against target times over 90 blocks; a target jumping by powers of two makes that noisy.

I dont agree, LWMA does hash estimations per block, you can set the target time per block.

• Invites tip reorgs. Difficulty now depends on the previous block's algorithm, so orphaning the tip resets your counter.

I dont see the problem? Your difficulty always depends on the previous block. If you reorg, you need to look at the latest tip and recalculate your template anyway?

• No cap, no simulation, no historical sequence where this would have mattered.

I am guessing you forgot all the work we did when sha3x kept causing 10-block reorgs?

[stringhandler]

I dont see the problem? Your difficulty always depends on the previous block. If you reorg, you need to look at the latest tip and recalculate your template anyway?

In other words, it is easier to mine on the previous tip to get a block reward than it is to accept the current block if it's the same algorithm as you. Rational mining pools should ignore any blocks that are of the algorithm they are mining.

I am guessing you forgot all the work we did when sha3x kept causing 10-block reorgs?

Regardless of whether I remember or not, this event is not in this TIP. Claude, who wrote this message, cannot remember this event.

A lot of the quick blocks are with pools jumping on and off Tari, this will penalise them as well, which is good.

So your logic is that if you hurt the honest miners as well as the bad miners then it's good. Ok, that does not solve the problem that honest miners will lose profitability. Enjoy the lower hash rate as miners move away.

Again, I did not write these comments. I asked Claude to review it. You can reproduce them with the prompt I supplied. Admittedly, I started with a negative prompt, but you can also reproduce it by asking if there "are any problems with this TIP".

Chatgpt had it's own problems. E.g.

4. Security proof

The RFC says

Makes selfish mining exponentially more expensive.

Intuitively yes.

I'd love to see that quantified.

For example:

After k consecutive blocks, expected work required increases by 2
k
, reducing the profitability of withholding strategies by ...

Even a rough economic argument would strengthen the proposal considerably.

1. Is doubling the right function?

The exponential shape seems sensible.

But why

2^n

instead of

1.5^n

or

1.8^n

or

3^n

The RFC chooses doubling without much justification.

I'd expect either:

simulation results
economic modelling
sensitivity analysis

to justify that constant.

[SWvheerden]

I dont see the problem? Your difficulty always depends on the previous block. If you reorg, you need to look at the latest tip and recalculate your template anyway?

In other words, it is easier to mine on the previous tip to get a block reward than it is to accept the current block if it's the same algorithm as you. Rational mining pools should ignore any blocks that are of the algorithm they are mining.

This is incorrect,
Lets assume that the pool does what you say and keeps mining on the current. And lets assume they get a new solution on the previous tip. They wont cause a network reorg, just just mined a fork. The newly mined block will have the same PoW as the current tip, so no new node will reorg to that block. The only way to cause a reorg is to mine a higher PoW, which means one of two things, 1: they need to mine an addition block, which leaves them back at square 1 and they just wasted time mining on a fork, or 2 they need to get 3/4 of the network (aka the other 3 algos) to mine on their fork, which those nodes wont do as the nodes wont reorg.

A lot of the quick blocks are with pools jumping on and off Tari, this will penalise them as well, which is good.

So your logic is that if you hurt the honest miners as well as the bad miners then it's good. Ok, that does not solve the problem that honest miners will lose profitability. Enjoy the lower hash rate as miners move away.

I dont think I agree, honest miners are not getting the blocks because pools are jumping on and getting all the blocks cheaply, then leaving as soon as the difficulty jumps, this leaves honest miners trying to mine to get the difficulty down again after having lost all those blocks. If a pool jumps onto an algo, there is nothing you can do, their hash rate is far greater than the rest. They will take the blocks for that algo. This stops them from taking all the blocks and forces other algos get some blocks, while also stopping them from reorging out the network. This is primarily a security thing.

[stringhandler]

Ok seems like you have this all thought out. I hope it works

[SWvheerden]

@stringhandler
I rewrote it to match how I envisioned the implementation would look and added extra detail

[stringhandler]

In the last 20 blocks as I write this (height 314697), the following block patterns appear:

1. 2x C29 blocks, 9 minutes apart (7 minutes after prev c29 block)
2. 2x sha3 blocks 7 seconds apart (30 mins after prev sha3x block)
3. 2x C29 blocks 30 seconds apart (2 min after prev c29 block)
4. 3x Monero blocks 8min, 4 min apart.

This proposal would make these gaps even worse. I don't have access to reorg data in this period (block 314678+) so I don't know if blocks are being added and then removed.

My prediction is that this proposal just makes the chain slower and doesn't solve anything you are trying to solve. 25% of the blocks in the chain had the same algo as their parent. So potentially you are looking at a 25% slower block time.

[m4r1m0]

Updated my diff sim https://github.com/m4r1m0/tari-diff-sim

It looks like the new proposed changes may actually make the issue worse.
Would appreciate any feedback.

[m4r1m0]

I updated my sim again to include a comparison against Zawy's WTEMA: https://github.com/m4r1m0/tari-diff-sim/tree/wtema-proposal

The readme is very verbose, too much so, because I just had my agent dump all its context in there. I figured this would be useful for auditing.