Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
LWMA difficulty algorithm #3
CN coins: The last test of your fork is to make sure your new difficulties when you sync from 0 are matching the old difficulties when running the pre-fork code. See this note.
LWMA for Bitcoin & Zcash Clones
I currently have LWMA and LWMA-3 code for BTC and Zcash clones. See the LWMA code for BTC/Zcash clones BTC Clones using LWMA: are BTC Gold, BTC Candy, Ignition, Pigeon, Zelcash, Zencash, BitcoinZ.
LWMA-2 is LWMA with 8% jump when last 3 solvetimes were < 0.8xT. Finished Aug 2018.
LWMA-4 is LWMA if all the options are removed. (And convert the 97 to 99.)
Use this if you do not have NiceHash etc problems.
Do not use LWMA-4 if you are a CN/Monero/Bytecoin/Forknote coin unless your pools are adjusting the timestamps during hashing. If your pools have not fixed this error, LWMA-4 will make their results worse and cause more delays in your coin, giving Nicehash an advantage over your pools.
LWMA-4 for CN / Monero coins
For dealing with NiceHash or other extensive on-off mining problems.
Old code for the last option that tells size current hashrate as multiple of what D expected.
LWMA-4 (long commented version)
Known coins using it
Importance of the averaging window size, N
Why are your jumps in LWMA-2 and 3 not symmetrical? Isn't the lack of symmetry dangerous or causing some other problem?
Using MTP for bad timestamps
Masari forked to implement this on December 3, 2017 and has been performing outstandingly.
Comparison to other algorithms:
The competing algorithms are LWMA, EMA (exponential moving average), and Digishield. I'll also include SMA (simple moving average) for comparison. This is is the process go through to determine which is best.
First, I set the algorithms' "N" parameter so that they all give the same speed of response to an increase in hash rate (red bars). To give Digishield a fair chance, I removed the 6-block MTP delay. I had to lower its N value from 17 to 13 blocks to make it as fast as the others. I could have raised the other algo's N value instead, but I wanted a faster response than Digishield normally gives (based on watching hash attacks on Zcash and Hush). Also based on those attacks and attacks on other coins, I make my "test attack" below 3x the basline hashrate (red bars) and last for 30 blocks.
Then I simulate real hash attacks starting when difficulty accidentally drops 15% below baseline and end when difficulty is 30% above baseline. I used 3x attacks, but I get the same results for a wide range of attacks. The only clear advantage LWMA and EMA have over Digishield is fewer delays after attacks. The combination of the delay and "blocks stolen" metrics closely follows the result given by a root-mean-square of the error between where difficulty is and where it should be (based on the hash rate). LWMA wins on that metric also for a wide range of hash attack profiles.
I also consider their stability during constant hash rate.
Here is my spreadsheet for testing algorithms I've spent 9 months devising algorithms, learning from others, and running simulations in it.
Here's Hush with Zcash's Digishield compared to Masari with LWMA. Hush was 10x the market capitalization of Masari when these were done (so it should have been more stable). The beginning of Masari was after it forked to LWMA and attackers were still trying to see if they could profit.
This was referenced
Dec 6, 2017
This was referenced
Dec 19, 2017
This was referenced
Jan 4, 2018
changed the title from
WHM difficulty algorithm
LWMA (WHM) difficulty algorithm
Jan 11, 2018
Here is the Python implementation of LWMA algo in Bitcoin Gold:
def BTG_LWMA(height, timestamp, target): # T=<target solvetime> T = 600 # height -1 = most recently solved block number # target = 1/difficulty/2^x where x is leading zeros in coin's max_target, I believe # Recommended N: N = 45 # int(45*(600/T)^0.3)) # To get a more accurate solvetime to within +/- ~0.2%, use an adjustment factor. # This technique has been shown to be accurate in 4 coins. # In a formula: # [edit by zawy: since he's using target method, adjust should be 0.998. This was my mistake. ] # adjust = 0.9989^(500/N) # k = (N+1)/2 * adjust * T k = 13632 sumTarget = 0 t = 0 j = 0 # Loop through N most recent blocks. "< height", not "<=". # height-1 = most recently solved rblock for i in range(height - N, height): solvetime = timestamp[i] - timestamp[i-1] j += 1 t += solvetime * j sumTarget += target[i] # Keep t reasonable in case strange solvetimes occurred. if t < N * k // 3: t = N * k // 3 next_target = t * sumTarget // k // N // N return next_target
@zawy12 , please note that your original pseudocode has a mistake at the last line:
If I understand it correctly, it should be:
Apparently, there's a superfluous factor