There’s a lot of FUD being instigated, even from some who are not aligned to BCC. Where are we at and what needs doing?
Being a minority chain comes with challenges. Emergency Difficulty Adjustment (EDA) which was implemented into Bitcoin (BCC) provided a survival mechanism, and has since been the cause of some wild swings in hash rate as miners jump from one chain to the other.
The oscillations are not particularly deadly, but they can affect user experience. This experience, is not particularly desirable long term.
If the Bitcoin (BCC) difficulty algorithm was to change, it would have to be extremely well tested, proven, and mathematically viable in all conditions, both with Bitcoin (BCC) being a minority and a majority chain. It should also have solid consensus… At the risk of sounding just like Adam Back, another split would look like a joke. Some BCC opposing factions would very much welcome such a scenario.
The options on the table however, range from the well thought out, to the absolute absurd. But notably, three good coding suggestions are worth investigating.
Firstly ABC’s ‘deadalnix’ has proposed an interesting method that involves difficulty adjustments based on both a 2016 block window, as well as one based on timestamps. If a difference of more than 25% exists between the two methods, the time based algorithm is used. This solution is based on the ZCash difficulty algorithm – which is tried and tested, although ZCash does not exhibit two methods. It makes sense on face value, but it would require heavy testing under many different conditions and circumstances. Testing particularly needs to look at ways in which this algorithm could be gamed. Generally, complexity opens attack vectors. Some testing has already been done though, and Sechet’s work is thorough, and respected, and I’m certainly not saying attack vectors exist, just urging caution on big changes.
Kyuupichan’s method looks at the last 6 blocks and calculates an adjustment depending on the timestamps of those blocks. Its strength is that it is simple. Can it be gamed by rogue miners? Unlike deadalnix’s algorithm, it is not based on an existing alt-coin algorithm, and its viability only exists in tests so far. However, testing so far, does indicate a surprisingly positive response in many conditions.
Bitcoin Classic’s Tom has a proposition which is to counter balance the EDA, and have an upward adjustment implemented (in case of excessive hash power). Without a doubt the most basic change among all contributions. It reminds me of Gavin Andresen’s code changes to Satoshi’s code. Often implementing little changes, with least baggage. In this case however, although it assists in the upward shift if needed (that can be helpful when blocks are slow), but it doesn’t correct the EDA issue in itself, and in tests, shows it has its own oscillations in certain conditions.
Now there is another solution, not in the form of code. That is, increased hash-rate. The oscillation generally exists with Bitcoin (BCC) being a minority chain, but given sufficient hashing power, the issue would be negligible. However, this doesn’t necessarily mean adding truck loads of hash power out of thin-air. It simply needs to be relatively large enough, compared to the BTC chain. This means, even if BTC was to have a heavy drop in price, and BCC moves up a little, it could solve the BCC’s problem in itself. Is it possible for BTC to drop, and BCC to gain some? It may sound unlikely, but we cannot ignore the possibility either.
Whatever outcome the community opts for – rushing into a ‘solution’ could be disastrous. In direct correspondence, Gavin Andresen once mentioned the overwhelming pressure, a developer has, particularly when working on a project that has billions of dollars of everyday people invested in it. The margin for error is minute, and critical. The situation with the EDA today, is not ideal, but it is not deadly. There are many reasons why waiting for the fall-out of Segwit1x vs Segwit2x may be favourable for Bitcoin (BCC). With hash rate splitting, and potential uncertainties concerning which chain adopts the BTC ticker, it is worth waiting this one out. BCC’s EDA causing a death spiral for Segwit1x and 2x, is unlikely, but not impossible. But even movement such a direction could give a significant boost to BCC.
Bitcoin.com’s Roger Ver recently stated that the Segwit1x/2x split will simply provide him with more coins to sell for Bitcoin Cash – which in his opinion, is ‘real’ Bitcoin. Myself and many others agree.
Segwit1x (BTC) in itself is in a hype cycle right now. Undoubtedly. Now it may go to the moon – but every bull market, is followed by a season of bearish activity. The price will come down at some point, and the hash rate will drop.
Finally it’s ever so important not to buy into the FUD that some are spreading. Bitcoin (BCC) is doing well given it’s mere 3 month tenure. Growth opportunity is huge. This is temporarily overshadowed by a giant BTC bull-run, the bullish nature of which cannot be sustained long-term.
I’m afraid that rushing into a fork now, as if we are at the mercy of the 1x/2x fallout, plays right into the hands of the opposition who would like nothing more than to see the BCC community split. I am certainly not suggesting we don’t implement a difficulty algorithm change. An improvement to the current algorithm would be a welcome change, provided it has been thoroughly tested. Waiting for the outcome of 1x/2x, and potentially having a nuclear weapon which can steal hash rate when we need it the most might be our best play.
An often unlooked at fact, is that the EDA cannot kill BCC (in fact it saves it), but it can kill a dominant chain. We need cool heads to prevail, and to give time to our 3-month-old project.
Fundamentally, if the community agrees and significant testing is done, then I’m on board. Dr Craig Wright also echoed, the sentiment, “Testing… we have to be professional about it”. Bitcoin Cash is a $5b project at present. That is $5 billion dollars’ worth of investor’s money, and it should be treated as such, – with utmost testing and care, paying due diligence to those who have placed their trust and money in it. Essentially, we should never compromise testing for any reason, except for a catastrophic disaster type emergency.
Eli Afram
@justicemate
New to blockchain? Check out CoinGeek’s Blockchain for Beginners section, the ultimate resource guide to learn more about blockchain technology.