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.
FWIW, it's possible to do the LWMA without looping over N blocks, using only the first and last difficulties (or targets) and their timestamps. In terms of difficulty, I believe it's:
I discovered a security weakness on 5/16/2019 due to my past FTL recommendations (which prevent bad timestamps from lowering difficulty). This weakness aka exploit does not seem to apply to Monero and Cryptonote coins that use node time instead of network time. If your coin uses network time instead of node local time, lowering FTL < about 125% of the "revert to node time" rule (70 minutes in BCH, ZEC, & BTC) will allow a 33% Sybil attack on your nodes, so the revert rule must be ~ FTL/2 instead of 70 minutes. If your coin uses network time without a revert rule (a bad design), it is subject to this attack under all conditions See: zcash/zcash#4021
People like reading the history of this algorithm.
LWMA for Bitcoin & Zcash Clones
See LWMA code for BTC/Zcash clones in the comments below. Known BTC Clones using LWMA: are BTC Gold, BTC Candy, Ignition, Pigeon, Zelcash, Zencash, BitcoinZ, Xchange, Microbitcoin.
LWMA-2/3/4 are now not recommended because I could not show they were better than LWMA-1.
Use this if you do not have NiceHash etc problems.
The following is an idea that could be inserted right before "return next_D;
Known coins using it
Importance of the averaging window size, N
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.
The text was updated successfully, but these errors were encountered:
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
LWMA for BTC / Zcash Clones
LWMA-1 (LWMA-3 used is deprecated)
This version does not allow "negative solvetimes" that the original BTG allowed. This increases stability.
…algorithm back to original CryptoNoteConfig.h - reduced initial block size - reduced maximum number of blocks Currency.cpp - changed difficulty adjustment algorithm back to original -LWMA difficulty does not work to produce 9 second blocks. Blocks were coming out too fast at 2 seconds per block and difficulty was not increasing.
sir most btc/dash clones have it