Consensus: DigiShield (Initial work submission)

[ChillingSilence]

Preface:
While I'm well aware this is not a complete / finished implementation and will probably fail to build happily, unfortunately I'm not a developer (As any experienced coder will no doubt be able to see from the commit), however this is intended to start the discussion around DigiShield being implemented for Litecoin.
I understand that thrasher- has begun work on 0.18 however this seemed the more appropriate place to begin that discussion, rather than on his own two 0.18 branches. This can be pulled into one of those branches once merged of course, rather than Master.

Motivation:
At the block reward halving at the start of August 2019, Charlie Lee rightly indicated that 12 blocks were found in 17 minutes:
https://twitter.com/SatoshiLite/status/1158326430574399489
By comparison, DigiByte at the same time had found 200 blocks in 49.5 minutes (Expected was 50 minutes, a 1% deviation), being far more steady / stable, closer to the expected timeframe.

For Litecoin, this is quite a variance over the expected 30 minutes for 12 blocks, with blocks being found almost twice as quickly as they should have been. A healthier network should have more stable block production.

Charlie Lee has also recently discussed Litecoins block timings in late July, accurately recalling how the initial 10,000 blocks for Litecoin were mined in the first 24 hours of Litecoins existence. Although DigiShield was not around for Litecoins creation in 2011, because a lot of new blockchain projects are still to this day basing their blockchains off the Litecoin code-base, we can also "save them from themselves" by having DigiShield implemented in what becomes their "upstream". A win / win situation for all.

DigiByte has been utilizing DigiShield since Feb 2014, with Dogecoin also implementing DigiShield (Readers of this are no doubt aware that DOGE is merge-mined with LTC) following consultation with (and assistance from) the DigiByte developers at the time. DigiShield is presently used in a couple of dozen other major blockchains at this point in time in 2019.

There is no down-side to a more stable and steady block production schedule, and this only impacts block emission timings, and not the block-rewards in any way. The block timing will still remain 150 seconds (2.5 minutes), unchanged. This will simply be staying closer to it.

Proposed using version bit 2, nStartTime = 1569888000 being Oct 1st 2019 is approx 3 months away with a 12-month timeout to achieve consensus on the upgrade.
Chose Block 1,770,000 for fNewDifficultyProtocol as this is 6 months in the future. Theory being it should provide sufficient time for miners to upgrade even if the consensus is attained earlier, while also not being too far in to the future. Because there is no down-side to this DigiShield upgrade, and it also helps miners with a more reliable block timing, I don't see why this would be a controversial upgrade.

Additional work is almost guaranteed to be needed to finalize the implementation, add additional tests for testnet upgrade etc but as mentioned this is a starting point that I hope is received in good faith with #LoveFromDigiByte.

[ChillingSilence]

It's been brought to my attention that I should probably explain better the purpose of DigiShield.

DigiShield is a dynamic real-time difficulty adjustment method.

Every block, it readjusts the mining difficulty, keeping the timing as close to the intended emission (mining) schedule as possible, compared to the traditional 3.5 day adjustment period. This is especially important around times of block reward halvings due to the fluctuation of hashrate in and out. However, it has been broadly proven to offer a more stable block timing, especially for a blockchain that's the dominant hashrate for it's algorithm such as Litecoin.

This is beneficial for miners too, as they're less likely to spend longer mining a block for the same reward, if the emission time is more steady.

DigiShield does not affect the block size, change the block timing, throughput, speed, or anything else. It simply makes the block timing more reliable.

Thank you to Rob D (@BoilingPointLTC) for pointing out the needed clarification, really appreciate the feedback, and the support.

[FaysalM]

@ChillingSilence - i cant speak for how @coblee or @thrasher- would view this. But just from a classic view on how blocks are produced, the fact that we had 12 blocks in 17 minutes is a feature, not a bug. It tells us, the difficulty adjustment is working as expected. Yes this causes some headaches during very high periods of difficulty adjustment, but thats not quite a reason to jump ship.

One of the reasons to keep the block adjustment as-is would also be the fact that a lot of multi-mine pools switch through a lot of scrypt coins which are all essentially litecoin clones. This was a bigger problem in the past, I am not sure how much it is prevalent today. We want to encourage longer term miners more than opportunistic mining. This adjustment would make much more sense for the coins with lower hashrates, that try and compete with the litecoin hashing. imo doesnt make a very good case to go into ltc.

[ChillingSilence]

The 12 blocks in 17 minutes isn't difficulty adjusting anything though, the difficulty is still the same between all those blocks. The unexpected faster block timing only gets taken in to account at the time of the next difficulty adjustment, and it will slow things down by increasing the difficulty, which had not occurred at that stage.

If there is more hashrate coming in and going out from merge-mining, that's again a perfect opportunity for it to smooth the block timings, as DigiShield was originally created back in 2014 to prevent multi-mining pools from stalling the chain (This is what occurred with DOGE, which is why they implemented DigiShield).

[coblee]

NACK

This requires a hardfork, so it's unlikely to get adopted by Litecoin. Litecoin, like Bitcoin, has dominant Scrypt hashrate, so it doesn't need per-block diff adjustment like other coins do. I disagree that there aren't any downsides to Digishield. For one, it requires a hardfork, which is a huge downside. Second, it makes mining earnings less predictable as @FaysalM hinted at. It makes miners have to do work calculating profitable at every block instead of ever 3.5 days. Lastly, this opens up potential new attack surface against mining. For example, miners can set their block time to try to mess with the difficulty. When everything is average out in 2016 blocks, it's much harder for a small subset of miners to cause problems.

[ChillingSilence]

Thanks for the response.
I will agree the down-side is a hard fork, it's worth being mindful of for sure. If that is the show-stopper, perhaps this is worth keeping in the back pocket for such a time as another hard-fork occurs, if that is the last remaining concern? After all, Litecoin was able to gain consensus on SegWit, I'm sure it could put it to the miners to signal support (or not) for this too.

However, stating "We're the biggest so this won't apply to us" is a bit misplaced, especially given Ethereum is the largest in Ethash, yet they utilize a difficulty adjustment algorithm based off DigiShield and adjust every block.
Same goes for ZCash being the largest Equihash blockchain, they too use DigiShield.
DigiByte is also dominant in Skein, Qubit, was previously with Myr-Gr, and is now also with Odocrypt. I could go on. However, not being the "dominant" hashpower is not the sole (or even primary) reason to want it. In fact it was specifically not the reason it was suggested for Litecoin, but rather the unpredictable block timings would be made better.

That's the crux of the suggestion: Block timings on LTC are significantly less reliable currently than they would be with DigiShield.

If the miner reliability of earnings is truly your concern as you have stated, then if the blocks are more stable / regular (which means a steadier block reward for miners) then miners income is actually more predictable with DigiShield. Contrary to what has been stated about the earnings being more predictable with the current method, having 12 blocks in 17 minutes (instead of the intended 30mins) means regardless of if that was luck, random chance, or an influx of hash power (sustained or not) the next difficulty adjustment will have to compensate for that and further exaggerate the difficulty at next adjustment to throttle the block timings.

Unrelated to this pull request, but I have put together some graphs to visualize the difference between the current for BTC / LTC, and DigiShield. It's quite pronounced: https://medium.com/@josiah_digibyte/measuring-expected-block-timing-for-difficulty-adjustment-c7a5bbffa775
I'll include the graph here, you can view the link if you want more specifics

As for additional effort for miners adjusting difficulty every block, the computation there is negligible at best. We have the likes of Ethereum doing it successfully, yet having a far more distributed mining network and also significantly faster block timings. Same for DigiByte. I don't see why this would suddenly be an issue for Litecoin, with 2.5 min block timings? Can you shed some light on that for me please?

I also don't quite understand what you mean when you mention "miners setting their block time to mess with difficulty", can you clarify what you mean by that? The difficulty is not based on time or the unix epoch, so if you're talking about what has happened previously with the likes of Verge to mint blocks, that's not applicable to DigiShield. That said, if you are aware of attack vectors with DigiShield that DigiByte, Ethereum, ZCash etc are unaware of, I'm sure all projects would welcome your insight.

Thank you for your time and input :)

[CaptThomas]

"This won't affect us because we're the biggest"
Aged like fine wine