I’m sure everyone is well aware of the large hashrate swings resulting in certain lanes dominating block production periodically or others getting drowned out entirely. This is causing block times to temporarily exceed the 2min target - often approaching 3min or more and sometimes resulting in chain reorgs many blocks deep.
I was thinking about proposing a modified DGW/MultiShield implementation, but I saw @blackwolfsa 's issue here about adding a consecutive block penalty to Tari’s current LWMA implementation. This seems like a much simpler/more elegant solution to me, and I’m of the belief that smaller architectural changes are typically better when it comes to consensus.
What are everyone’s thoughts on implementing this or something else like Digibyte’s MultiShield?
@blackwolfsa is there any reason that you decided not to go ahead with this proposal?
3 Likes
Its still in proposal stage. Changing the PoW is something that needs to be approached with caution and enough time.
But the lanes should not effect each other. But target difficulty changes is inherant to the design of pow and an a side effect of mining. Miners will swap to and from a chain if its more or less profitable to do so. That will just impact that chain, but should not impact the other chains. See my explanation on the other post about pow.
My proposal is about reorgs which we dont see atm.
2 Likes
Sorry, I didn’t mean to imply that hashrate on one lane is directly impacting block times on another - I am saying that the slow adjustment of the LWMA paired with the violent hashrate swings (in both directions) are resulting in overall block times exceeding the 2min target.
This is part of the problem, right now the ability to mine many blocks in quick succession is resulting in pools gaming the network to exploit small windows profitability on a particular lane, after which they usually switch off/abandon the network. You can see others observing this behavior in the hashrate concentration thread. This is causing a “hangover” effect with these hyper-fast blocks in the LWMA difficulty calculation window. Your solution somewhat remedies this by preventing these hyper-fast blocks in the first place.
I understand you initially proposed this to solve reorgs, but I believe it would indirectly solve some of this blocktime variance issue as well.
You also mentioned “tuning some of the parameters to make it adjust quicker” in your issue, which is the most appealing part of your proposal. If we could just shrink the window from 90 to 45, for example, that would be a much simpler fix compared to implementing something entirely new like DGW/MultiShield or an EMA. Maybe I misunderstood and you only meant tuning the target_time parameter and not block_window?
Also, we do see reorgs every day as far as I know. Just glancing at the network as I write this I can see a 3 block reorg from 27893-27895 with 4 blocks mined in rapid succession ~1min. It’s not a massive reorg, but it is an issue - and if bridge limits are removed like many in this community are asking for this could become significant unless confirmation requirements are raised (which has UX tradeoffs).
2 Likes
Bridge safety limits are an entirely different conversation, and I am of the opinion to keep it on the safe side. Most crypto hacks and attacks that steal money are targeted at a bridge.
But the LMWA jumps relatively quickly. But if you make the block window too small, it jumps too erratically. Having block times that are not exactly 2 mins are fine. A good example of this is Bitcoin, it only adjusts the difficulty every 2 weeks. Now I know they have much, much higher hash rates, so it’s difficult for it to swing.
Block target time is only there for an estimate for the pow and so you give the network time to sync new blocks. As long as the avg block time is roughly 2 mins, its fine.
With Mythos and other AI amlified security work, I agree it’s a good time to keep the bridge limits on the safe side for now.
I would love to be able to mine and hodl XTM again. But I cant because of the hashrate swings. Even though I dont sell the XTM I mine, I cant in good conscience mine it as a charity, which is what it is right now. A new difficulty targeting algo would definitely help build that loyal miner base I think we want.
2 Likes
I think its good to be honest about this, PoW swings are going to be a thing for smaller pow chains like Tari, nothing we do can stop this. We can try and optimise how its handled, but it will happen, its part of the economics of PoW.
A clever Rx Pool will be able to mitigate the algo changes very easily as the hardware required to mine RxT vs RxM is exactly the same. Sha3 vs C29 vs Rx{T/M} is different, in that it is ASIC/FPGA vs GPU vs CPU.
1 Like
While I’d love to see the wild RxT and C29 swings gone, I’m not sure an incremental penalty, exponential or not, is the answer - wouldn’t that just make gaming the swings more predictable?
It’s easy to redirect hashpower, so now instead of booming for 4-5 hours, while the current algorithm slowly catches up, one could push for 2-3-4 quick blocks, and then redirect elsewhere, since no-one is going to find more blocks in that lane anytime soon. And, depending on how the penalty peters out, it could also be quite predictable when a given POW lane is ripe for the next push.
I could very well be missing something but couldn’t a simple penalty on consecutive blocks in a lane make for even wilder swings and maybe even fewer blocks found by the regular, non-switching miners?