It has recently been brought up that the Bitcoin Cash protocol perhaps ought to introduce a form of "drift correction" (alternatively referred to as "drift compensation" or "drift reparation" in some places).
Specifically, such a proposition has been bundled with the recently announced Grasberg difficulty adjustment algorithm [3] put forth by Bitcoin ABC.
The first time I read about such a proposal for BCH was in this technical draft [4] by Karol Trzeszczkowski, published on 18 May 2020. It arrived during a time when discussions on DAA replacement were already in full swing . Most people at the time did not think it was a very important topic to pursue.
What follows is my opinion on this notion with reference to some actual numbers and foreseeable consequence.
Is there a real problem?
"Drift" refers to Bitcoin Cash emission being slightly ahead of an ideal emission curve that one could construct based on the mathematical parameters that govern coin emission.
BTC is also ahead of its schedule, because the difficulty retargeting on BTC happens only about every 2 weeks, and hashrate has traditionally been increasing faster than the historical algorithm would be able to compensate for. So BTC blocks have, on average, been arriving at faster than the original number of blocks per hour envisaged by Satoshi Nakamoto's code.
This is widely known, but no-one really cares much about it in Bitcoin BTC.
When Bitcoin Cash was created, the difficulty algorithm had to change to ensure the coin can survive in an environment where some miners mine BTC, some mine BCH, some mine both or switch between them.
The initial algorithm in BCH, the "Emergency Difficulty Algorithm" (EDA), was a stopgap measure with ugly side effects. It caused a slew of blocks to be mined very fast by miners who quickly took to gaming the difficulty drop that could be produced.
This lead to early BCH miners accruing a lot of blocks mined at lower difficulty by way of gaming that algorithm. It also caused periods of extreme wait for confirmations, followed by periods of insanely rapid blocks with nearly no transactions in them.
Clearly such oscillations are bad -- even the major miners at the time had to concede that this was damaging to the reputation of Bitcoin Cash as a contender for a serious peer to peer cash system.
Developers and miners took action and in November 2017, only a few months after the creation of BCH, the difficulty algorithm was replaced by the current one (referred to simply as the "DAA" in most conversations even though that is a general term).
Since then, the average time between blocks has been very close to 10 minutes over long timescales.
Really, let's check the average block time since the upgrade in 2017 until now:
That's really close to 600s / block already!
The proposed ASERT DAA [1] would bring it even closer to the ideal 600s / block.
The current average block time on BCH is actually SLOWER than the target that Satoshi was aiming at, while BTC's average block time is consistently less than 10 minutes. How does this relate to "drift" ?
Well, as u/BigBlockIfTrue pointed out, any drift w.r.t. BTC caused by rapidly mined coins on BCH in its early lifetime would be naturally eliminated simply because BTC is being mined faster "than it should" and they have no plans to change their algorithm:
It should be emphasised that the EDA-era drift will be fully compensated (i.e. BTC block height overtakes BCH block height again) soon enough with both the current DAA and with ASERT, simply because we now have an average block time of 10 minutes whereas Satoshi's original DAA has a smaller average block time.
Quantifying the "drift"
This is easy enough... Bitcoin was designed to have 10 minute (average) block times, even if implementations fell a bit short of achieving that very reliably (BCH's DAA is actually a significant improvement over BTC's in that regard).
We can look at any drift from two different angles:
If we look at the current time, we can work out how many blocks should have been produced on an "ideal Bitcoin chain" that meets exactly the 10min/block target. Then we look at BTC and BCH, and we find they have more or less blocks than "should have" been produced. That's one way of expressing the drift.
We can look at how many blocks have been produced on BTC and BCH, and work out at what date their current top-most blocks should have been produced , in a alternative reality where the block time average is exactly 10 minutes. The difference in time is another way of expressing the drift.
Let's take a look!
What does it all mean?
The absolute drift in terms of schedule, for either of these chains, is less than one year out of an emission schedule whose total length is somewhere ~130-140 years (I don't care to be precise here because you can see the relative magnitude).
Are these drifts significant over the relatively short terms that these chains have existed? Yes, more significant if nothing were done about the average block times.
But on Bitcoin Cash, something HAS been done to get the average block time very close to 600 seconds. If ASERT is selected as the next DAA, this will get even more exact.
So you can say that on Bitcoin Cash, this drift has pretty much been "stopped in its tracks". Even if no DAA change were made, the offset would not change significantly in the future.
On BTC, the drift may continue since nothing is being done about it. Why is nothing being done about it?
Who cares about drift?
It has been said (read Karol's paper) that there is a "social contract" between Bitcoin / Bitcoin Cash users as far as the emission schedule is concerned.
Bitcoin emission schedule is one of the key elements in Bitcoin design, and a promise that was made to early investors. Furthermore, predictable inflation is believed to be one of the crucial components of hard money. Bitcoin is designed to have a specified number of bitcoins in a single block so technical considerations of block production, propagation and transaction confirmation get entangled with monetary policy. While [DAA proposal] addresses the technical aspects of block production, this [drift correction] proposal addresses the monetary policy aspect of it.
Occasionally, people do make calculations that assume that a Bitcoin (Cash) block should take on average 10 minutes.
Occasionally, people write time locks into smart contracts that make assumptions that a certain block height should equate, approximately, to a certain time in the real world.
Perhaps this isn't the smartest idea, but it does base on a kind of "contract" established by the design of Bitcoin. That is, the difficulty algorithm is there to govern the rate at which blocks are produced on average. It is there to maintain this average close to an ideal "target time" which Satoshi coded in at 10 minutes (6 blocks per hour).
To compensate for increasing hardware speed and varying interest in running nodes over time,the proof-of-work difficulty is determined by a moving average targeting an average number ofblocks per hour. If they're generated too fast, the difficulty increases.
- Satoshi Nakamoto, Bitcoin whitepaper [2], page 3
I'm no smart contract developer, but I know that certain Bitcoin op-codes have been adapted over the years to accept values that represent actual time instead of block heights and thus may allow some smart contracts to avoid the pitfall of relying on block heights to translate to time with some accuracy.
But IF your blockchain's average is close to the ideal time (as a good DAA can produce) then it's an assumption that can be made with some confidence, as long as you're considering long timeframes and are willing to tolerate a small bit of variance that naturally occurs because blocks are found by chance and not by someone looking at a clock and hitting a button.
Over longer timescales, you can then predict the time a block will be found even without any kind of "drift correction".
Apparently, this predictive accuracy IS something people want, because that is one of the stated benefits of the Grasberg proposal [3]. However, that does not require correction of a time offset. All it needs is that the rate of block production is stable and accurately predictable over the long term.
The effects of would-be drift correction on BTC and BCH
As we can see, by necessity one would need to slow down block production to compensate for the drift that already crept in on both these chains.
BCH actually inherited the BTC drift, most of which occurred before it forked off in 2017.
Direct effects of "drift correction" aka slowing down the rate of block production:
For a given time period, users must expect less confirmations (blocks) on average. Conversely, users will need to wait longer on average for a certain number of confirmations on a payment.
For the Grasberg DAA proposal, the average additional expected time per block is around 75 seconds (on top of the 600 of the ideal target) - for a number of years.
This add-on time is supposed to come down over time, until one day it reaches zero when the Grasberg DAA would perform roughly as well as the ASERT DAA in terms of producing 10-minute-average blocks.
I have not seen anyone actually offer a major tangible benefit for introducing a drift correction.
It does nothing beyond what a good DAA would to help smart contract developers estimate future block times based on height.
It actually breaks existing smart contract which do that and which assumed a figure which may now be significantly off, e.g. due to blocks taking more than 10% longer on average. That adds up to a LOT of time over a long interval, meaning that coins locked up may now stay locked up significantly longer.
Even miners are affected, they can only move bitcoins after they have "matured" through 100 confirmations. Guess what - that would suddenly take around 2 hours longer!
I think if you ask most people what they consider the social contract of Bitcoin, then not inflating the supply beyond ultimately ~21M coins is highest on the list.
Whether we are a year off on the final emission by the time more than a hundred years have passed, is NOT a concern I've heard anyone bring forward.
What matters, that the DAA performs optimally, that IS a real concern that many Bitcoin Cash users have brought up especially over the last 6+ months where the existing BCH DAA has been gamed to the detriment of both loyal miners and loyal users.
We should not let esoteric considerations get in the way of fixing that.
P.S. I'm also not a fan of the term "reparations", but same as for the "tax" term, there is no need to get hung up about it. Sure - people can debate the accuracy or applicability of terms, but ultimately that's somewhat besides the point of fixing and improving the protocol. Words are something that those who want to divide groups can easily use to stir up distractions. Consider the actual effects and do not be distracted too much by whatever language used to describe them.
References:
[1] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-8887b9c1#stable-daas
[2] https://www.bitcoin.com/bitcoin.pdf
[3] https://read.cash/@deadalnix/announcing-the-grasberg-daa-ff52e96d#comment-4bf763a6
[4] https://gist.github.com/KarolTrzeszczkowski/90946ad06b92891a386927afbf6d361b
Lead image: Le Radeau de la Méduse (The Raft of the Medusa), Théodore Géricault (1817-1818)
I knew youd tie in that dishonest political abuse of language in there. You'll say ANYTHING to discredit your opponents and make them not look libertarian.
This is exactly what happened with Core/Blockstream. Infiltrators (e.g. Adam Back) convinced the libertarians that they were the real libertarians, stealing away the hearts of the community. And your modus operandi is the same: STIFLE ALL INNOVATION AND IMPROVEMENT ON BCH IN THE NAME OF "NO CONSENSUS!"