[Consensus] Problems with difficulty drop consensus rule

[sanket1729]

The difficulty drop consensus rule creates an interesting scenario as follows:

Consider the following simple scenario: 1) Miners wait for difficulty to down significantly low (they can mine BTC meanwhile) 2) They mine 2016 blocks very fast. 3) Back to step 1

With a stable hash rate (stable referring to amount of hash power such that 2016 blocks are mined in 2 weeks), miners can wait for some periods of 12 hours and then mine. Assuming stable hash rate, some basic calculations I did showed that it is possible mine 2016 blocks in 6.3 days while maintaining the same difficulty across periods. I think the problem is even worse because the potential hash power(BTC + BCH) which can mine bitcoin cash is atleast 5 times higher than stable hash power.

I think such a faster rate of coin generation is problematic as it would lead to faster halving(less than 2 years), which leads to faster rise of transaction fees. This leads to the very problem for which bitcoin cash was created to solve. Furthermore, faster generation of coins will also lead faster into unexplored lands of comparable transaction fees overcome block reward incentive.

This is a big problem because if 95% hash power can meetup at a place, it is quite easy to collude for this profit as it fits perfectly in the consensus rules for Bitcoin Cash. Miners are also not necessarily bound to Bitcoin Cash, since they have main bitcoin to fall back on.

A simple solution would be remove the rule by adding a Soft Fork.

I am sure that that the scenario has been considered before designing REQ-7 of UAHF spec, but I feel these consequences do not justify the rationale.

I intended this for a mailing list discussion, but I can't seem to references to it in bitcoinabc.org or bitcoincash.org

[zanza321]

Digishield looks great. Can it handle sudden 95% or even 99% hash rate crash?

[DesWurstes]

We can improve it >v<, we have good devs.

UPDATE: DigiShield Difficulty system is 50% in https://github.com/digibyte/digibyte/blob/master/src/pow.cpp, 50% in https://github.com/digibyte/digibyte/blob/master/src/pow.cpp

[ghost]

Digishield should be able to handle sudden hashpower drops as it adjusts the mining difficulty between blocks. So in the case of BCC, every 10 minutes. It's definitely the most viable solution for our issue I believe. Dark Gravity Wave is speculated to have some issues with massive drops in hashpower

[slava-vishnyakov]

What is DigiShield & How it Works to Retarget Difficulty https://www.reddit.com/r/Digibyte/comments/213t7b/what_is_digishield_how_it_works_to_retarget/

We created DigiShield after seeing the threat that multi-pools pose to a crypto currency when they start mining a coin at a very low difficulty in relation to their net pool hash. This allows many coins to be quickly and easily mined before the difficulty increases.

Sounds exactly like what we have after each EDA.

The secret to DigiShield is an asymmetrical approach to difficulty re-targeting. With DigiShield, the difficulty is allowed to decrease in larger movements than it is allowed to increase from block to block.

This keeps a blockchain from getting "stuck" i.e., not finding the next block for several hours following a major drop in the net hash of coin.

The implementation of DigiShield v3/v4 can be seen here https://github.com/digibyte/digibyte/blob/3593b858681e61270a4a8a2539627926bca0ef3b/src/pow.cpp#L178-L338

Here is also an useful description of DigiShield v3: https://github.com/zcash/zcash/issues/147#issuecomment-202741851

DigiShield v3

The algorithm looks at a fixed number of previous blocks, and calculates the actual time they took (using medians to prevent timewarp attacks):

nActualTimespan = pindexLast->GetMedianTimePast() - pindexFirst->GetMedianTimePast();

An asymmetric floor and ceiling is applied:

nAveragingTargetTimespan = nAveragingInterval * multiAlgoTargetSpacing;

nMaxAdjustDownV3 = 16; // 16% adjustment down
nMaxAdjustUpV3 = 8; // 8% adjustment up
nMinActualTimespanV3 = nAveragingTargetTimespan * (100 - nMaxAdjustUpV3) / 100;
nMaxActualTimespanV3 = nAveragingTargetTimespan * (100 + nMaxAdjustDownV3) / 100;

if (nActualTimespan < nMinActualTimespanV3)
    nActualTimespan = nMinActualTimespanV3;
if (nActualTimespan > nMaxActualTimespanV3)
    nActualTimespan = nMaxActualTimespanV3;

The new difficulty is set to difficulty of the previous block (that had a matching mining algorithm) scaled by nActualTimespan/nAveragingTargetTimespan.

(also there is a note on difference between v3/v4)

The only difference between v3 and v4 (that I could see) was that they halved the averaging target timespan and increased the effect of the error. Thus AFAICT the only difference between them is in tuning, which we need to adjust anyway because we only have one PoW. If you can see any other differences though, I'd like to know. https://github.com/zcash/zcash/issues/147#issuecomment-224119523

[ghost]

Digishield would be a good replacement for the current EDA and would give us a more stable difficulty adjustment. We could also probably do merged mining like @maaku suggested. Two viable options, I'm in favor of both.

[josephNLD]

@lichtamberg The attack vector envisioned by Mr. Todd is easily detectable, and further it is an attack based on a false premise endemic to Core's philosophical roadmap, and on a fundamental misunderstanding of Bitcoin.

It is false that your personal wallet-with-chain, (full node), is the best protection against attack. This notion is the worst kind of centralization, individualism. While the notion of individualism appeals to many of us, it hazards an unnecessary and undesirable single point of failure, oneself.

The best protection against such fraud attacks is a broad consensus among your trading partners, with whom you hope to spend these coins! If it matters, check block explorers at a minimum. You aren't so likely to spend them to yourself, and if you do, it doesn't matter until you attempt to spend them with your trading partners.

Trace Mayer recently quipped how your full-node is your sword and shield. If so, broad consensus among your peers is a machine-gun.

EDA is a helpful improvement on Bitcoin. It provides for a swifter recovery of Bitcoin in case of global emergencies. Consider how fortunate Bitcoin Cash is, that this improvement was left undone by the former gatekeepers of Bitcoin's reference implementation.

I'd question the premise of this thread. What proof has been offered that the EDA will ever have to change? If it is only because of the situation of the moment, please notice that with each oscillation, Bitcoin Cash comes closer to stability. It seems to be doing what it is designed to do, which is to protect Bitcoin from failure. Core ought to adopt it, but they won't out of pride, which goes before a fall.

[ghost]

@josephNLD EDA is helpful, but there were smarter options available. EDA is good for the network in the case of something like a WW III, but not good in the current situation. Perhaps with every oscillation the difficulty adjustments become ever closer to stability, but how long will that take? It's been less than a week since the issue has been noted and the BCC chain is already 1,595 blocks ahead of Bitcoin's chain, which should not have happened. This issue needs to be fixed otherwise the halving will be reached much sooner and the inflation will keep lowering BCC's worth. Bitcoin Cash will die because of EDA if the current situation is not fixed. The EDA could stabilize, but whose to say how long that will take. If it takes another 5 days then another 20,000 BCC will be mined in that time. BTC Core is not dumb, (although we'd like to think so) but maybe they didn't adopt for a reason.

[checksum0]

I'd rather keep EDA until it stabilizes than switching to untest difficulty retarget algorithm. We already played way more than enough with the protocol as it stands. BTC retarget has a 8 years impeccable track record.

@jiosephNLD no it does not stabilize at all, or nowhere close to fast enough. We are 1600 blocks ahead, excluding whatever BTC was already ahead at the time of the fork. That's 20k coins that reach the market more than whatever core trolls dumps suppressing the price.

We got through last difficulty cycle as quick as the other one, it's ridiculous.

I'm all for ditching EDA ASAP (November/December) without changing regular diff. retarget. Please let's not fall into the "HF are hard..." core narrative here.

Also I'd like to consider BCC a serious project, meaning not replacing a huge important part of it with an extensive testing phase by untested or barely tested algorithm (DGW which is flawed anyway/Digishield).

The idea is to stay as close to bitcoin as possible, not getting creative and introducing all kind of shit...

[josephNLD]

There's the thing, how fast does it need to stabilize? What are the metrics? Bitcoin Core is unusable all the time because of fees. Bitcoin Cash is unusable for one day out of four for now because of block time, later one of five, then six... Changing it in December if it isn't stable enough makes sense, I'll be surprised to have been wrong about this, and agree. Doubly surprised if Core has resolved the fee issues by then.

Cash has a viability advantage with EDA that Core lacks, and may come to regret not having implemented when they could have done it without their pride getting in the way.

The accelerated emission provides a slight economic advantage later with a sooner halving. The 20k additional coin in the near term (maybe 50-100k+ before stabilization) are a nice early adopter bonus. The economic effect is an increased scarcity to the later adopters and more coin at a lower price to those who are paying attention.

In the end it comes down to survival fitness. The economics in the current environment favor EDA as is, especially as another chain fork is looming for the Core chain.

[checksum0]

I have no clue why I shouldn't just dump all my BCC at one on the market and just by a Chinese mine since I'll just have more BCC after that.

That's how fucking ridiculous the situation is to anyone that is invested in that project the slightest.

[ghost]

BCH just had the EDA kick in and the new difficulty is set at 119369386419 up from about 89000000000. With 14TH/s S9 @ $610 this puts the profit around $6.5k annually, which is quite close to BTC's $6k. It would seem the EDA oscillations are in fact becoming stable.

[TierNolan]

Has there been any coins which vary minting lockouts to improve stability?

The rule could be that you can't spend a coinbase output unless the MTP of the spending block is more than 28 days after the MTP of the coinbase's block and at least 4032 blocks have passed.

Realtime removes the incentive to abuse block rates. You always have to wait 4032 blocks, so that creates an incentive not to cause the chain to stall out.

[ghost]

I like the concept of DigiShield. The core concept, which is having a larger magnitude of downward difficulty adjustment and a smaller magnitude of upward adjustment is interesting. This could be helpful in dealing with a sudden hashrate drop-off, without relying on the unstable EDA. The issue I see with EDA is that you need to accurately time it. Too few EDAs, you don't reduce the difficulty enough; too many, you welcome a massive influx of hashrate. Since BTP.top operator over-slept recently and missed the mark, I say we plan a sunset of EDA.

But I also agree that we should wait until difficulty and hashrate stablizes first. And we have to go through extensive testing too.

[jihanwu]

Merged mining almost as broken as EDA

[schancel]

Closing this as the EDA has since been removed.