On Bitcoin Cash’s Target Recalculation Functions by Juan Garay and Yu Shen

On Bitcoin Cash’s Target Recalculation Functions by Juan Garay and Yu Shen

1 Introduction
While opening up a new era in the area of cryptocurrencies, Nakamoto’s Bitcoin protocol [Nak09b,
Nak09a] has been critized for its heavy use of the computational resources needed by its underlying
proof of work (PoW) mechanism as well as its relatively long settlement time of transactions. As
a consequence, a number of alternative cryptocurrencies have been proposed with the purpose of
ameliorating the above issues. One such proposal is Bitcoin Cash (BCH)1
, created in August 2017
as a “hard fork” of Bitcoin, with the original motivation of increasing the size of blocks, and thus
allowing more transactions to be processed.
Due to lesser prominence and popularity, the computational “investment” on these alternate
cryptocurrencies is relatively low (for example, the hashing power invested on Bitcoin Cash is
approximately 5% of that on Bitcoin). Moreover, miners are able to evaluate their expected reward
and rapidly switch among different blockchains in order to achieve a higher profit, giving rise to an
environment where the number of participating miners on these minor blockchains may fluctuate
wildly, which in turn has a direct effect on suitable difficulty (of PoWs’) recalculation mechanisms2
.
The above two aspects—desired higher transaction throughput and higher participation variation—
are the motivation for this work. We focus on Bitcoin Cash as a representative of a newly proposed
target recalculation function, and perform a formal analysis of the protocol’s security under such
dynamic environment. The importance of an adequate target recalculation mechanism has already
been pointed out in [GKL17], where it is observed that if it is removed, the blockchain protocol
becomes insecure in the dynamic setting even if all parties behave honestly, resulting in a blockchain
that will diverge substantially (i.e., spawning “forks”) as the number of miners keeps increasing,
thus becoming vulnerable to many known cryptographic attacks. Furthermore, an inadequate
target recalculation function may break the balance between miners’ invested hashing power and
reward, thus reducing their confidence in the system and leading them to quit the mining pool,
arguably a situation that should be avoided.
Bitcoin Cash’s target recalculation algorithm has gone through three stages. When created,
the recalculation mechanism was a combination of Bitcoin’s target recalculation function and an
emergency difficulty adjustment (EDA) mechanism, which would suddenly enlarge targets by 25%
(i.e., decrease mining difficulty by 20%) if the block generating interval of 6 blocks exceeds 12
hours.
In November 2017, this initial function was replaced by a new function called SMA (for Simple
Moving Average, or “cw-144”). At a high level, SMA is analogous to Bitcoin’s recalculation function
in the sense that it determines the next target based on an “epoch” of blocks, except that in the
new algorithm the target value is recalculated more frequently—in fact, the target for each block
varies. Moreover, the epoch of blocks changes with every block in a “sliding window” fashion.
Generally speaking, the SMA function calculates target for the next block based on the length of
the epoch and the average target of the blocks in the epoch.
Finally, the recent (November 2020) update introduces a control-theory-inspired recalculation
function called ASERT (for Absolutely Scheduled Exponentially Rising Targets) [WISK20]), which
is completely different from previous recalculation functions. ASERT is not epoch-based, and
adjusts the difficulty level of each block simply based on its timestamp and height difference with
the “anchor” block. Specifically, once an anchor block is chosen, a timestamp can be computed
for all the subsequent blocks according to its height and ideal block generating interval. The
difficult adjustment is an exponential function of the block’s timestamp deviation from its scheduled

timestamp. the target changes is controlled by a “smoothing factor” m, which we will show is a
crucial parameter in our analysis.
Overview of our results. Our main contribution is establishing under what conditions regarding
party fluctuation Bitcoin Cash’s target recalculation functions (both ASERT and SMA) achieve a
steady and close to the ideal block generation rate, given that they are not epoch-based, and the
recalculation mechanism is invoked for every block—and further, in the case of ASERT, that it is
“memory-less,” meaning that the target for one block is only decided by the current timestamp
and the block’s height. As such, previous analyses based on the duration of an epoch no longer
hold, and new analytical tools are needed.
As in prior work on dynamic environments, bounds on the ways that miners come in and drop
out of the computation are necessary for things to work. We suggest a new methodology to capture
how the number of parties can fluctuate. In a nutshell, our definition is comprised of two parts
concerning both short-term and long-term participation. In such context, we first (Section 3)
perform a preliminary analysis of the ASERT function to establish whether in a suitable respecting
environment, the blocks in chains created according to the function will have blocks with timestamps
to make the probability of producing the next blocks close to the ideal block generation rate (we
will call such timestamps “good”). Through a closeness measure based on “calibrated timestamps”
and probabilitic analysis we conclude that they do.
Our conclusions then serve as a crucial part of the complete security analysis (Section 4), where,
following [GKL15, GKL17], we present an abstraction of the protocol we term the Bitcoin Cash
backbone, and follow the “template” of establishing two main properties of the blockchain data
structure—“common prefix” and “chain quality”—which serve as an intermediate step to build a
robust transaction ledger. As a result, (our abstraction of) the Bitcoin Cash protocol with chains
of variable difficult using the ASERT function running in a bounded-delay network and suitably
parameterized, satisfies, with overwhelming probability, the properties of consistency and liveness.
In addition (Section 5), we also provide a description and analysis of Bitcoin Cash’s previous
target recalculation function SMA. Even though the function has now been deprecated, it provides
insights and elements of comparison against ASERT with regard to party fluctuation.
Finally (Section 6), we compare our results with data from the Bitcoin Cash network, from
which we extract the actual party fluctuation rate and network delay. Our main conclusion is
that in order to satisfy security (namely, properties satisfied except with negligible probability)
increased parameter values should be used with respect to the ones used in practice—specifically, a
larger value of m (the smoothing factor in ASERT and epoch length in SMA)–concretely, m = 432,
compared to the value m = 288 that is being used in ASERT (which in turn corresponds to 2
days)— should be adopted. In addition, regarding the SMA function, a larger dampening filter
τ = 8 in the SMA function should be used, instead of τ = 2, which is the value that was last used.
Lastly, our comparison with the existing Bitcoin Cash network shows that the ASERT function
performs better than the SMA function under a pronounced party fluctuation.
Due to space limitations, some of the proofs and detailed protocol descriptions, and other
complementary material are presented in the appendix.
2 Preliminaries
In this section we present the network model where we analyze Bitcoin Cash’s target recalculation
functions as well as the Bitcoin Cash protocol abstraction, as well as some basic blockchain notation.
These notions and terminology follow closely [GKL17, GKL20], and therefore the presentation

On Bitcoin Cash’s Target Recalculation Functions by Juan Garay and Yu Shen