Okay, sorry it’s taking longer than expected. Here are some of my initial results.
I’m was making a little JS app people could run locally and audit the source code, but had to make some privacy compromises temporarily in order to get it working asap and audit my own work.
I’m going to keep working on that and release it to all or share it with @blackwolfsa and other devs if I cant get the PII out of my source
TLDR: Block Window of 45 + penalty reduced the max block time by the most compared to actual, 60 + penalty, and 30 + penalty. Surprisingly, LWMA30 without the consecutive block penalty had the best results, but I left that out as I assumed the consecutive block penalty would be getting added regardless as a security improvement.
Going to run some more simulations, see if I can clean up my code, and make another post with a detailed methodology
I am going to write my TLDR as a separate post to keep the post a bit smaller.
So the smaller the block window, the faster the response back down to ideal. But the problem is that PoW mining is random, its not a set time, there is variance in mining. I added randomness to the solve time with a poisson distribution while keeping the hash rate the same.
The is where the tradeoffs happen, lower block window you faster response times, but you also gain more variance with just the randomness of solve times.
With Pow you get randomness, see this screenshot of BTC’s solvetimes, yes I know BTC has a terrible DAA, but it also has the most stable hash rate of all PoW coins by a fair margin, they dont get hash attacks.
In this window of 8 blocks, we have 2 mins → 59 mins. The nature of PoW mining will lead to these things happening. Even if we reduce the block window its still going to happen.
I think there are other problems worth solving before this gets solved. Exactly how bad is it if one algo mines all the blocks? The chain continues. Double spends are still prevented.
I think some of the impetus for this change derives from concern that Tari’s promise of “mining for everyone” is unfulfilled. The perception is that smaller miners are being disadvantaged by large-scale miners and/or pools which could be taking advantage of algorithm oscillation.
Is it the protocol’s responsibility to help ensure miner sentiment and profitability remain high? Perhaps not, but doing so may contribute to Tari’s success. I would think that’s a directional question which once had a clear answer.
Respectfully, it’s exactly this attitude towards miners that has largely contributed to Tari’s decline.
Tari spent years marketing itself as basically a mining app, and consistently since launch miners have been treated as an afterthought. Look at the results of those choices.
Miners are users. Miners are developers. Miners are community members. Do we have a surplus of those hidden somewhere I don’t know about?
What other proposals are on the table anyway? We can do multiple things at once.
Is this LWMA + consecutive block penalty or just LWMA by itself? My simulations are all with the consecutive block penalty added which should bring down max block time and variance.
It doesn’t solve the issue entirely. But we’ve all acknowledged that it probably wouldn’t even before any simulations were run. It’s not a block time fix on it’s own, its a security fix with a side effect.
I was expecting around 50% reduction in max block times and its really looking more like 12-25% depending on the LWMA window. Disappointing, but I’d still consider that to be significant.
If you have an alternative proposal, or think we should just go with DGW or multishield, or something else entirely, I’m open to hearing it.
Okay, I’ve rerun the simulations, only change is a different seed for the prng, and using the mean for all 10 runs instead of the median. The results are pretty different.
Max block time down from 24min (actual) to ~7.5min
Obviously need some eyes on, I’m almost done cleaning everything up and will post shortly
I specifically kept it out, as its designed to do something else, and its going to muddy the results. The consecutive block penalty changes the target time only, does not change the block window or any of the other variables.
The simulations is about how close the LWMA with its parameters can keep to the target time/difficulty, If we add the penalty, we cant see how it fairs.
These simulations are purely on a single algo run, as in practice the chain runs 4 totally independent algos which it chains together at a later stage to form the chain, but they have to impact on each other.
According to your simulation the 90 is way better than actual
EDIT: @kinkajou
I think the biggest issue with your simulation is that you average each run 10 times, because its run is around 2 mins + rng, the avg should hug 2 mins.
This is way your simulations mirror the 2 min solve time so closely. Even the 90 does this as shown here.
EDIT2:
I removed the 10 block avg, now it looks a lot like the actual, and the lwma-60 is not performing much better if at all.
I thought this might be a problem. It’s why I was using median originally.
Probably better to switch back to median and just do more simulations rather than averaging them there.
You can view the result of each simulation below the mean graph as well, also for this reason.
FWIW the summary does not use mean, and you can still see the difference there. But again it’s back to the ~10-30% improvement seen in earlier simulations.
This is why I did those separate simulations, my biggest worry, lmwa 90 if the hash rate stays the same, the block solve times vary at max 50% where as 45 goes up to 70%, its much worse for stabilty
I have pushed my code to this branch if you want to take a look, its messy, but its there, I used a phython script for the graph
I asked Claude to be critical of my simulations and made a few suggestions, including adding Poisson variance to the solve time of the response.
This graph perfectly sums up why I think an lwma of 45 won’t work. It does not really converge, whereas 90 takes longer to respond, but it does converge and stabilise somewhat; 45 does not.
This post says we should be using a lower window like 3 times at the very top
My current estimate of the best N based on the target solvetime for LWMA is: T = 600, N=45 T = 300, N=55 T = 150, N=70
Changing N when T changes Once we know the ideal N and T for a particular algorithm, we should choose a larger N for a coin that has a smaller T, and vice versa. Since there are more sample points in real time for a smaller T, we can have a better functioning algorithm. With a smaller T we can choose a faster response, less random variation, or a smaller improvement in both.
Based on this it sounds like N should be somewhere between 45 and 55, which is around my initial estimate.
The problem with these simulations, is that we are not testing the adjustment as it is proposed or as it will actually function on the network. This is why I moved to replay simulations based on actual historical network data (also to see interaction with other lanes which is difficult to simulate correctly) and applied the consecutive block penalty.
The proposal is not to adjust the LWMA window, the proposal is to add a consecutive block penalty, and adjusting the block window is secondary to that. The penalty helps difficulty spike faster, reducing the window helps bring it back down faster.
Testing various LWMA windows without the proposed penalty is not really helpful - that is not what the proposal is for. And once the consecutive block penalty is added - it technically isn’t even LWMA anymore.
