Bonded Mining: Difficulty Adjustment by Miner Commitment
George Bissias, David Thibodeau, Brian N. Levine

TL;DR
Bonded Mining introduces a proactive difficulty adjustment algorithm that uses miner commitments secured by bonds to maintain consistent block times and resist manipulation, outperforming traditional reactive DAAs in simulations.
Contribution
The paper proposes a novel proactive DAA using miner commitments and bonds, with a statistical detection method for deviations, improving stability over existing DAAs.
Findings
More effective at maintaining target block time than Bitcoin Cash DAA
Detects hash rate deviations with high sensitivity and low false positives
Supports miners with at least 1% of total hash rate in simulations
Abstract
Proof-of-work blockchains must implement a difficulty adjustment algorithm (DAA) in order to maintain a consistent inter-arrival time between blocks. Conventional DAAs are essentially feedback controllers, and as such, they are inherently reactive. This approach leaves them susceptible to manipulation and often causes them to either under- or over-correct. We present Bonded Mining, a proactive DAA that works by collecting hash rate commitments secured by bond from miners. The difficulty is set directly from the commitments and the bond is used to penalize miners who deviate from their commitment. We devise a statistical test that is capable of detecting hash rate deviations by utilizing only on-blockchain data. The test is sensitive enough to detect a variety of deviations from commitments, while almost never misclassifying honest miners. We demonstrate in simulation that, under…
| committed | short | long | short | long | |||||||||
| hash rate | window | window | threshold | threshold | |||||||||
| 1% | 2 | 100 | |||||||||||
| 10% | 20 | 1000 | |||||||||||
| 25% | 50 | 2500 | |||||||||||
| 50% | 100 | 5000 | |||||||||||
| Committed | Short-range | Long-range | ||
|---|---|---|---|---|
| hash rate | detection rate | detection rate | ||
| 1% | 0.033 | 0.271 | ||
| 10% | 0.108 | 0.653 | ||
| 25% | 0.837 | 0.660 | ||
| 50% | 1.000 | 0.546 |
| Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | Day 6 | Day 7 | Day 8 | Day 9 |
| 10% | 7.5% | 22.5% | 11.3% | 22.5% | 28.1% | 56.3% | 42.2% | 21.1% |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
11institutetext: College of Information and Computer Sciences, UMass Amherst 11email: {gbiss,levine}@cs.umass.edu 22institutetext: Florida Department of Corrections
22email: [email protected]
Bonded Mining: Difficulty Adjustment
by Miner Commitment
George Bissias 11
David Thibodeau 22
Brian N. Levine 11
Abstract
Proof-of-work blockchains must implement a difficulty adjustment algorithm (DAA) in order to maintain a consistent inter-arrival time between blocks. Conventional DAAs are essentially feedback controllers, and as such, they are inherently reactive. This approach leaves them susceptible to manipulation and often causes them to either under- or over-correct. We present Bonded Mining, a proactive DAA that works by collecting hash rate commitments secured by bond from miners. The difficulty is set directly from the commitments and the bond is used to penalize miners who deviate from their commitment. We devise a statistical test that is capable of detecting hash rate deviations by utilizing only on-blockchain data. The test is sensitive enough to detect a variety of deviations from commitments, while almost never misclassifying honest miners. We demonstrate in simulation that, under reasonable assumptions, Bonded Mining is more effective at maintaining a target block time than the Bitcoin Cash DAA, one of the newest and most dynamic DAAs currently deployed. In this preliminary work, the lowest hash rate miner our approach supports is 1% of the total and we directly consider only two types of fundamental attacks. Future work will address these limitations.
Keywords:
Difficulty adjustment protocols cryptocurrencies
1 Introduction
Blockchain protocols maintain a public ledger of account balances that are updated by authorized transactions. Proof-of-work (PoW) mining is the process of assembling transactions into blocks and earning the right to add the block to a growing chain [24]. PoW mining involves repeatedly cryptographically hashing the assembled block, each time with a different nonce. The hashes are generated uniformly at random from a space with maximum value . When a hash falls below a target , the corresponding block is said to be mined, and it is added to the blockchain. Closely related to target is the difficulty111Technically , where is the target with highest possible difficulty, but this detail is not important for our analysis. , which is equal to . The expected time required to mine a block is a function of and the rate that hashes are generated, or hash rate . Hash rate fluctuates (sometimes rapidly) over time, and therefore PoW blockchains must adjust to ensure that the expected block time remains roughly constant. Currently, all PoW blockchains use a difficulty adjustment algorithm (DAA) to adjust as fluctuates.
Although implementations vary widely, each DAA is essentially a feedback controller analogous to a thermostat. The DAA uses previous block creation times to detect a change in , and then it makes an adjustment to in order to move the expected times toward the desired value . There are three major limitations to this reactive approach.
There is a tendency to either over or under correct, which can cause oscillations in block time [30, 29]. 2. 2.
Contentious hard forks create significant instability in block times for minority hash rate blockchains, which must resort to a backup controller that compensates for swings in miner hash rate allocation preference [31]. 3. 3.
Most control algorithms can be gamed by miners without consequence in order to extract higher rewards[18, 21], causing fluctuations in block time as a result. 4. 4.
Feedback control is inherently reactionary; it only uses historical block time and difficulty data to produce future difficulty values.
Contributions. We present Bonded Mining, a protocol that enhances PoW mining with a proactive approach to difficulty adjustment so that inter-block times are always near their desired value despite sudden hash rate changes. The idea is to ask miners to commit to their individual hash rate and financially bind them to it by holding bond. Difficulty is adjusted based on these self-reported commitments. Miners are incentivized to commit to a realistic estimate of their future hash rate and honor their commitment, even if it becomes nominally more profitable to direct their hash rate elsewhere. The protocol is flexible: miner commitments last until they mine their next block; and they can deviate from the commitment (incurring a penalty commensurate with their deviation) as long as they are truthful about the deviation.
For security, we derive a statistical test (using on-blockchain data only) that is capable of detecting both short- and long-term deception from miners. Miners who fail the test suffer a significant financial penalty. The test is sensitive enough to detect a miner who drops to 20% of her commitment for a week or more, and it can also detect when she strays from her commitment by as little as 1% every block over the course of 70 days or more. This sensitivity comes with very little risk for honest miners. Even when a miner deviates from her commitment, if she truthfully reports that deviation, then the probability of failing any test over the course of a year is less than 0.3%.
Because of its proactive design and the penalties associated with deception, Bonded Mining is better capable of maintaining the desired expected block times than are conventional, reactive approaches. In Bonded Mining, the extent to which block times remain close to desired time is the extent to which miners value their bond more than a change in their hash rate. In simulation, we find that even when miners are willing to sacrifice 25% of their bond in order to change their hash rate, Bonded Mining still demonstrates lower amplitude and duration of deviations from than does the DAA of Bitcoin Cash, the latter of which is one of the newest and most dynamic DAAs currently deployed.
2 Protocol Details
Bonded Mining enhances existing PoW mining schemes by adding a collateral requirement to ensure hash rate commitments are honored. Figure 1 illustrates many aspects of the protocol, and a List of Symbols appears in the Appendix. To bootstrap, miner must post bond to the blockchain by paying coins into a bond pool account via a validated deposit transaction. The bond is posted prior to mining the first block and is locked until the miner produces his first blocks, where is a tunable security parameter depending on the miner’s hash rate. As part of the deposit transaction, miner also stipulates his commitment for the hash rate he will apply to mining his first block, .
Mining. Now consider the next blocks mined by : . Define as the time that is mined. Let be defined as the time of the block containing the deposit transaction. When mining block , miner adds a new deposit transaction to the set of transactions being mined, which deposits an additional coins to the bond pool. In assembling the block, he uses the typical block header, and includes two new pieces of information: report and commitment . Report is an attestation from miner of his actual average hash rate during the time period between and . And is ’s commitment for the next block . If wishes to stop after blocks, then he can issue a divestment transaction (see Bond state section below) and is unnecessary; otherwise should contain the commitment for the next block. When block is eventually mined by , the coinbase is immediately transferred to the miner’s wallet, but bond is released only upon reconciliation. To be clear: the miner can adjust commitments each block starting from block ; but reconciliation begins from block onward and evaluates a window of the previous blocks.
Reconciliation. If blocks, , have been mined by , then his block includes a reconciliation transaction that pays himself a reconciliation payment from the bond pool. is the refunded portion of the bond deposited by while mining block , which is now eligible to be reconciled. (Miners never forfeit coinbase rewards.) Miner signs and confirms his own reconciliation transaction, but if he repays an inappropriate amount, then the transaction is considered to be invalid by other miners and the entire block is ignored. The value of is determined in two stages. The first tests ’s reporting accuracy via binary hypothesis test , which deterministically rejects or accepts the null hypothesis that the inter-block times from are samples that came from the distribution implied by reports . If the null hypothesis is rejected, then ; i.e., loses all his bond deposited in block . However, if the null hypothesis is not rejected, then in the second stage we evaluate ’s commitment fulfillment by setting
[TABLE]
We tune the hypothesis test so that if honestly reports his hash rate for each block , then he is very likely to pass, and then will be repaid his bond as the absolute difference between his committed and actual hash rates.
Bond State. We define four distinct states for bonded miners: Bootstrapping, Fully Bonded, Divested, and Abandoned. A new miner who has not yet deposited total bond is bootstrapping. Once she has contributed mined blocks to the main chain, her total bond reaches and the miner is considered fully bonded. Note that the number of blocks required to reach the Fully Bonded state depends on the miner’s committed hash rate as a fraction of the total. Accordingly, miners may fluctuate between Bootstrapping and Fully Bonded states if the total hash rate changes. A fully bonded miner is eligible to divest her bond in order to reduce her hash rate on the blockchain to zero. The miner signals this intent by submitting a divestment transaction, which can appear in any block, not just one that she mines. The transaction contains reconciliation payments (see above) for each of her bond deposits that remain in the bond pool. Once the divestment transaction is confirmed, the miner is fully divested: she is committed to zero hash rate and has no remaining bond. In order to begin mining again, a divested miner must proceed through the Bootstrap state. Finally, a miner can reach the Abandoned state from either the Bootstrapping or Fully Bonded states if she fails to generate a block in a reasonable amount of time given her last commitment (see below). If the miner reaches the Abandoned state, all of her bond is lost, and she transitions to the Divested state. (The bond is burned, but could be redistributed as future coinbase.)
Abandonment Detection. The test for abandonment is distinct from the test Valid. It is conducted every block (as opposed to only those generated by the miner). For each miner in either the Bootstrapping or Fully Bonded state, we have , the latest commitment from . We argue in Section 4 that if honors her commitment, then the inter-arrival time of her th block, , is exponential. Specifically, where is the target inter-block interval for the network. Now let be the quantile function for such that . With probability , we know that will be less than . Therefore, for large , we can be almost certain that has abandoned mining at her committed hash rate if no block hash been seen for time .
For example, consider a miner who commits to 10% of the total hash rate in a protocol like Bitcoin with minute block times. With probability exceeding 99.999%, it will take no more than 20 hours to mine her next block. Thus, by setting the abandonment time to 20 hours, we can be highly confident that has in fact abandoned mining at her committed hash rate.
Difficulty Adjustment. Let and be the total committed and actual hash rates, respectively, across all miners for the time period in which block will be mined. Bonded Mining makes the assumption that security parameters and are tuned so that miners are incentivized to honor their committed hash rate during this time period, i.e. . It is known [25] that the hash target is related to total hash rate by the equation
[TABLE]
where is the expected time to produce a block and is the size of the hash space, as defined above. Given the equivalences and (defined in Section 1), we arrive at the following formula for difficulty.
[TABLE]
Commitment Constraints. Because the difficulty is derived directly from miner commitments (Eq. 3), it is possible for an attacker to falsely raise the difficulty arbitrarily high at a cost limited to bond . To prevent this attack, it is important to ensure that every miner’s commitment is realistic given their past hash rate. This constraint has ramifications for both bootstrapping and fully bonded miners (those with coins in the bond pool). For a fully bonded miner, we stipulate that she can change her commitment by no more than some multiple times her average commitment over the previous blocks (e.g., ). As a protection against Sybil attacks[10] described later, we allow up to fraction of the total commitment for block to come from bootstrapping miners (i.e., miners who have deposited fewer than coins into the bond pool). If the aggregate commitments exceed fraction , then they are cut proportionately down to the maximum. Fraction , which is also tunable, should be fairly small (e.g., ) because new miners have much less at stake than established miners (fewer coins in deposit), and the network has observed fewer blocks from which to assess their hash rate potential. The values for both and should be set by the community at large (not just miners) and can also be updated regularly to respond to changes in miner composition.
Mining Pools. The Bonded Mining protocol is agnostic to the presence of mining pools, but the protocol does not greatly impinge on the ability to operate a pool effectively. Commitments must be made at the pool level, thus they can be changed only as often as the pool mines a block. A pool could aggregate constituent miner preferences in between blocks and update the overall commitment based on those preferences for the next block. Thus, if a pool mines a block approximately once an hour, then miners would be free to adjust their hash rate allocation to that pool with the same frequency.
3 Threat Model
Primary Threats. In the next sections, we focus our security analysis on attacks from miners who report their hash rate dishonestly. Rational miners intent on deviating from their commitment for blocks will report dishonestly when their preference to deviate exceeds the greater of the value of coins at risk or penalty associated with honestly reporting the deviations (i.e., ). (We discuss coins at risk in Section 5 and preference in Section 6.) In this sense, Bonded Mining can ensure miners honor their commitment only to the extent that the fiat value of bond exceeds the value of mining on a different blockchain. There are numerous ways that an attacker can falsify reports, but in this preliminary work we focus on short-range and long-range attacks. A short-range attack involves an attacker significantly deviating from his commitment for a relatively small number of sequential blocks. In this context, we are primarily concerned with the attacker committing to a large hash rate, and subsequently dramatically lowering that hash rate, which would tend to increase block times during the attack. In contrast, the long-range attacker deviates subtly from his commitment over the course of many blocks. Although not catastrophic during a short period of time, this attack can lead to systematic deviations from the target block time.
Sybil Attacks. A single miner (or a cooperating coalition of miners) can always split his hash rate to appear to be multiple, lower hash rate miners in a Sybil attack [10]. Therefore, it is important to make incentives equitable for miners of any hash rate in order to encourage honest representation of affiliation and avoid the formation of mining cabals. We tune the Bonded Mining protocol to ensure that: (i) after Bootstrap, the amount of bond locked up at any given time is proportional to the miner’s committed hash rate; and (ii) the expected lockup time for bond and the expected probability of losing that bond are equal across hash rates for honest miners. We do not, however, attempt to align penalties for attacking miners with varying hash rates. That is to say, it will be possible that an attacker will suffer a lesser penalty by breaking up his hash rate among multiple identities. Note that this sort of asymmetry exists with other attacks. For example, a selfish mining attack only becomes possible for miners with a certain minimum percentage of the total hash rate.
Other Attacks. Bonded Mining’s commitment validation test uses the inter-block times of each miner’s own blocks; therefore, one miner’s hash rate cannot influence the test results of another miner. We do not consider out-of-band denial-of-service attacks. A selfish mining (SM) attack [12] by one miner would alter inter-block times of the other miners by increasing their orphan rate. However, bonded miners could easily adjust their commitment to account for orphaned blocks due to an SM attack. Alternatively, Eq. 3 could be modified to take into account a miner’s orphaned blocks [14]. In fact, Bonded Mining makes it possible to attribute SM behavior to one or more miners who have a much lower orphan rate than other miners; we leave this analysis to future work. Doublespend (DS) attacks [24] are more challenging to carry out in Bonded Mining since the attacker must both succeed and avoid a commitment validation test failure in order to prevent loss of bond. Lastly, a miner could falsely report the timestamp in her own block headers. We do not investigate the impact of timestamp manipulation in this preliminary work, but note that the Bonded Mining protocol could impose restrictions on timestamps to greatly reduce the impact of such an attack. For example, it could stipulate that miners should synchronize clocks using NTP and that a miner should discard any block header that reports a timestamp deviating from their own clock by more than a reasonable block header propagation delay, perhaps 30 seconds.
4 Report Validity Test
We require a statistical test of the validity of a sequence of reports from miner . The test should have have both high precision and recall in order to simultaneously prevent malicious attacks while refraining from bond slashing honest miners with high probability. It should also be capable of simultaneously detecting various types of attacks. In this section, we describe a statistical test that effectively detects both short- and long-range attacks. It requires a sample of of the miner’s most recent reports, where varies with her hash rate, but can otherwise be treated as a black-box test within the Bonded Mining protocol.
Our approach is to use the popular one-sample Kolmogorov-Smirnov (KS) test [22] as a building block for test Valid. It is tempting to use a simpler point estimate of hash rate expected value as opposed to a goodness-of-fit (GoF) test over an entire distribution (which is provided by the KS test). There are two reasons that a distribution test is more desirable. First, the KS test is much more sensitive to systematic deviations in hash rate. Second, point estimates allow for attacks in which miners game the system by, for example, front loading all of their hash rate at the beginning of a test window; in that case the correct mean will be achieved, but the distribution will be wrong.
Consider the random sequence , denoting the inter-arrival times of blocks mined by . By we denote the actual average hash rate for miner , with associated with the time between blocks and ( when reports hash rate honestly). Eq. 3 can be rewritten as
[TABLE]
where is the average difficulty between blocks and ; i.e. the expected time required for to mine her th block is equal to the average difficulty divided by her hash rate. It is well known [27, 5] that each follows the exponential distribution. That is, . And because the distribution is a scale family, it is straightforward to show that . Now define statistic such that . When reports honestly, we have .
The one-sample Kolmogorov-Smirnov (KS) test is a statistical test of the null hypothesis that samples , collectively an instance of , were drawn from a given distribution. In our case, the distribution is . The KS statistic is given by , where is the cumulative distribution function for and is the empirical distribution function derived from samples . The alternative hypothesis contends that the samples were not drawn from . Now let be the -value for and define to be a realization of . By definition [8],
[TABLE]
Therefore, assuming that was drawn from , we are guaranteed that the rejection region will carry probability of type-I error (falsely rejecting ) no greater than . Accordingly, large -values provide evidence in support of and low values provide evidence in support of .
Figure 2 shows the empirical cumulative distribution for drawn from two different distributions: true and deviant. The true samples (blue, dashed curve) are drawn from distribution while the deviant samples (orange, solid curve) are drawn from a sequence of exponential random variables with mean changing according to a random walk about with standard deviation equal to . The true samples produce nearly perfect -values in that approximately fraction of all trials fall below -value , indicating an accurate estimation of type-I error. The deviant samples manifest significantly lower -values, indicating high confidence in . Approximately 30% of deviant samples register a -value very close to 0. We summarize a binary test based on the KS statistic below.
DEFINITION 1: For tunable threshold , test is equal to 1 when the -value of KS statistic exceeds and 0 otherwise. Accordingly, the probability of a type-I error is equal to .
Because we are interested in detecting both short- and long-range attacks, we apply two KS tests: one over a short window ; and the other over a longer window . Associated with these tests are the thresholds and , respectively. The window sizes and thresholds vary with both test type and the miner’s committed hash rate. We combine the two tests into one to form Valid by multiplying their output. The probability of a type-I error in Valid is bounded by because it occurs if there is a type-I error in either of the KS tests.
DEFINITION 2: is equal to 1 when both and are equal to 1, and it is 0 otherwise. The probability of a type-I error is bounded by .
5 Attack Risk and Detection
In this section, we quantify the coins at risk for miners who report their hash rate dishonestly, which we regard as an attack. When a miner fails test Valid, her entire bond of coins are lost and she must proceed through the Bootstrapping state to resume mining. Thus, at a minimum, the coins at risk are the expected amount of bond lost when test Valid fails. But, any failure is also a significant step back for a miner, the parameter (see Section 2) limits her committed hash rate during bootstrap (a period of about 70 days), which amounts to an opportunity cost in terms of coinbase revenue.
We ran a simulator of PoW block mining to test the ability for a dishonest miner, with varying fraction of the total hash power, to conceal short- and long-range deviations from her commitment. We evaluated miners in three categories: (i) honest, (ii) short-range dishonest, and (iii) long-range dishonest. All miners varied their commitment each time they generated a block by performing a random walk with standard deviation equal to 1% of their originally committed hash rate. Honest miners always reported this deviation, while long-range dishonest miners reported that their commitment never changed from its original value. Short-range dishonest miners were honest about their long-range deviations in hash rate (just like honest miners), but at the end of each test window they mined at 1/5 of their committed hash rate for approximately one week, while reporting no deviation from their commitment.
We generated block creation times by sampling from , where was given by the ratio of total hash rate to actual miner hash rate . ( is equivalent to Eq. 4 when actual hash rates are known.) Each block was randomly assigned to either the honest or dishonest groups with a probability proportional to the fraction of total hash rate possessed by the dishonest group.
Test Application. There are two separate, but related, goals for test Valid. First, given a single sequence of consecutive blocks called a test window, we require that Valid can distinguish between honest and either short- or long-range dishonest miners by means of a statistical test on sub-windows of size and within the those blocks. Second, to understand the probability of ongoing attack success, we also require that Valid continue to differentiate between honest and either short- or long-range dishonest miners during a long temporal sequence of overlapping test windows. The two goals are met by applying test with the long window , short window , short threshold , and long threshold all defined so that the probability of a type-I error remains extremely low for an entire year of mining. Our metrics for success are type-I error and attack detection rate (i.e., the rate at which when applied to the attacker’s test windows). The former should be sufficiently close to 0 so as to encourage honest miners. And the latter should be somewhat higher than 0 so as to discourage dishonest miners. These parameters can be chosen offline and independent of blockchain conditions.
Parameter Selection. Table 1 shows the parameter choices we made, which we applied to all experiments reported below. In general, lower hash rate miners (as a percentage of the total) require smaller windows for Valid to produce dishonest-detection rates that would be significant to attackers. This is a desirable property because lower hash rate miners require more time to produce blocks. We chose and so that the expected temporal duration of each test sub-window was the same for miners across all hash rates (approximately 1.5 days for and 70 days for ). We then chose the values for and to render the probability of type-I error close to 0, even after one year of expected mining time. These parameter choices are validated in the next sections.
Attack Detection. In Table 1 we specify short- and long-range test sub-windows for committed hash rates varying from 50% down to 1% of the network total. Given these parameters, the short-range sub-window for a miner committed to 1% of the hash rate is . To discourage Sybil attacks parameters must be chosen equitably for honest miners with any hash rate, as we argue in Section 3. This implies that, in its current incarnation, Bonded Mining cannot support miner commitments less than 0.5% of the total hash rate, because this would require a value for that is less than 1. Note that this limitation is tied to the amount of proof of work we receive from miners; i.e., we cannot detect an attack during periods of time when the miner does not produce blocks. For BTC and BCH, respectively, 99.4% and 98.6% of the total hash rate from March 24–June 24, 2019 was contributed by miners with at least 1% of the hash rate.222See https://btc.com/stats/pool and https://bch.btc.com/stats/pool. Smaller miners do not need to be excluded from the system as they can join a larger pool. And in future work, we will explore PoW schemes such as Bobtail [5] and FruitChains [26] that have miners broadcast additional PoW information. For example, Bobtail could easily decrease Bonded Mining’s minimum allowable hash rate by several orders of magnitude.
5.1 Accuracy of Valid Over the Bootstrapping Window
Table 2 shows the probability of attack detection at the end of the bootstrapping window (block ) for short- and long-range attackers. Results are based on parameters from Table 1 for four different hash rate percentages, averaged over 1000 trials for each. We do not show the rate of type-I error when miners are honest because not a single error was encountered in the 1000 trials. However, by construction, the probability of a type-I error in any given test window is bounded by .
The most important detection rate is for the 1% miner because a high hash rate miner can masquerade as multiple low hash rate miners. Thus, a determined attacker can avoid detection during the Bootstrapping state with 96.7% probability. From Table 1, ; and thus there are coins at risk for the attacking miner. We show next that any initial success will likely be short-lived and the coins at risk will rise if the attacker continues as a fully bonded miner.
5.2 Attacks by Fully Bonded Miners
Once in the Fully Bonded state, a miner can remain in that state by continuing to add a new commitment for each additional block mined. Valid is tested against the sliding window of the most-recent blocks generated by the miner. These sliding windows are highly dependent since adjacent windows share all but one block. If any single test fails, the total bond of is lost.
We simulated one year’s worth of blocks from attacking miners subject to Table 1 parameters, and we determined the mean probability (across 1000 trials) that Valid detects at least one attack during the year. Results in Figure 3 show that approximately 30 days after bootstrapping, even attacks by 1% miners are detected with 50% probability. Thus, since again , the coins at risk after 30 days of attack is .
Probability of type-I error. We ran the same experiment for honest miners who similarly varied their hash rate as in the short- and long-range attacks for multiple test windows spanning a year in duration, except that in these experiments miners reported their hash rate honestly. Over the course 1000 trials for each set of parameters selected from Table 1, test Valid never returned a false positive in any test window throughout the simulated year of mining across all hash rate commitments and for both short- and long-range deviations. Therefore, the probability of type-I error is no higher than 0.003 based on a 95% confidence interval from the 1000 trials [15]. Overall, miners that honestly report their commitments are very unlikely to fail test Valid.
6 Block Time Stability
Section 4 introduces a hypothesis test for determining when a miner reports his hash rate honestly over a window of consecutive blocks that he has mined. If the miner fails this test, his bond of coins is lost; and if he misbehaves such that his probability of failure is , then we say that he has coins at risk. On the other hand, an honest miner, who passes the test, is eligible to submit a transaction in the next block that reconciles the bond deposited for the first block in the window, with the reconciliation fee being paid according to Eq. 1. Thus, when deviating from his commitment for blocks, a rational miner will report honestly when exceeds . Section 5 quantified for various attacks. In this section, we assume that coins at risk are high enough that the miner always reports his hash rate honestly (i.e. ). Nevertheless, he might still change his commitment dramatically or even deviate significantly from his commitment (all considered honest behavior). Naturally, these deviations can affect the performance of the DAA. Thus, our goal is to (i) quantify the affect on block times given various magnitudes of hash rate deviation, and (ii) quantify the financial cost to a miner who performs these deviations.
6.1 Block Time Simulation
To achieve the goals of this section, we created an expected block time simulation that takes aggregate miner hash rate as input, generates blocks according to current hash rate and difficulty, and runs a DAA to update the difficulty. We compared two scenarios: one using the DAA for Bitcoin Cash (BCH, for brevity); and the other using the Bonded Mining protocol DAA (BM, for brevity). We chose to compare against Bitcoin Cash because it uses one of the newest and most dynamic DAAs currently deployed. Because the simulation reports expected block time, it is deterministic given miner preferences (Table 3). The simulation is meant to highlight DAA behavior in a variety circumstances, we leave more systematic analysis to future work.
Blocks. Both BCH and BM targeted block time seconds. In both cases, the expected block time was calculated as (a relationship that follows from Eq. 2), where and are the total hash rate and difficulty, respectively, during the period when block is mined.
Preference. At any given time we assumed that miners had a preference for what percentage of their hash rate they would like to apply to mining on the Bonded Mining blockchain. The notion of preference captures a miner’s tendency to either divert her hash rate to another blockchain or stop mining altogether. Preferences could change, for example, because of changes in coin or energy prices. We do not model miner preferences but rather treat them as input.
Hash rate. For simplicity, we adjusted all hash rates in unison every block (as though all miners acted in concert). But we set the block window to and updated commitments only every 10th block as if the network was comprised of 10 miners, each having 10% of the total hash rate. Over the course of two weeks of simulated mining time, miners developed the preference for a given hash rate at different times, expressed as a percentage of their total hash rate available (see Table 3). For BCH, miners immediately realized their hash rate preference. However, for BM, miners were restricted in two ways: (i) we set the commitment constraint to (see Section 2) so that miners could not change their commitment by more than twice the average of their earlier commitments; and (ii) miners were averse to deviating from their commitments because such deviations would result in a loss of bond. Note that BM miners were assumed to be fully bonded, so parameter was not relevant.
Cost tolerance. Miners obeyed a variable cost tolerance, , expressed as a fraction of per-block bond , which is the amount of bond that they were willing to lose per block due to deviation from their commitment. For example, if and USD, miners are willing to lose up to USD per block by deviating from their commitment if there exists a 10 USD opportunity cost for mining on the present chain over another.
Difficulty adjustment. The target block time for the simulation was seconds. BCH used the Bitcoin Cash DAA [28]: the rolling sum (over the last 144 blocks) of difficulty (which gives the expected number of hashes performed) and block time are calculated; the block time sum is clamped with a high and low pass filter: ; and the new difficulty becomes . The DAA for BM was Eq. 3: , which is the product of target block time and total committed hash rate.
6.2 Simulation Results
During the two weeks of simulated mining time, hash rate preferences changed according to Table 3. Figure 4 compares the resulting expected block times for each. BCH (left plot) shows several interesting features. First, we can see that expected block time deviates significantly from the target time during periods immediately following a major change in hash rate: the most dramatic drop is to 250 seconds, and the most dramatic rise is to nearly 1500 seconds. Moreover, these deviations were not corrected by the DAA for up to one day following the change in hash rate. Second, even during times when hash rate remains unchanged (for examples the period after Day 11, the expected block time oscillates about the target time. We suspect that this phenomenon is due to a feedback cycle that emerges from the DAA, which itself is essentially a feedback controller.
In contrast, Figure 4 (right) shows that BM has much lower amplitude and duration of deviation from expected block time relative to BCH. And when hash rate is not changing, BM is able to maintain an expected block time that exactly matches the target time.
The Bonded Mining protocol is able to keep expected block time close to the target time by controlling the change in commitment and the tendency to deviate from that commitment. Miners are not allowed to vary their commitments by more than factor from the average of previous commitments. Nevertheless, they may still vary their actual hash rate as long as they can tolerate the penalty. Figure 4 (right) shows that miners with cost tolerance will follow their hash rate preference, but only up to a point. When the preference deviates far beyond what the factor allows, miners cease to change their hash rate in order to avoid bond loss beyond 25% per block. Figure 5 shows how the expected block time begins to deviate more and more as the cost tolerance increases up to 1.0. What is not shown in the figure is that for , the hash rate preference is followed perfectly, meaning that miners sacrifice as much bond as is necessary to meet their preference. For , the worst-case scenario for Bonded Mining, Figure 5 also shows that while the duration of deviation from the target block time is longer than for BCH, the maximum deviation is less.
6.3 Setting the Bond
We have intentionally not specified how the community should choose the per-block bond value . It is a security parameter that trades off between accessibility and security of mining, and the correct tradeoff is subjective. For example, consider setting equal to 1/10 the coinbase value. This requires a fully bonded miner (with any committed hash rate) to lockup the equivalent of approximately 10% of her mining profit for 70 days. This financial commitment is a strong deterrent for would-be attackers since failing even a single test Valid results in a total loss of bond. We do note that it could be a significant hardship for miners who operate on slim profit margins.
7 Related Work
Considerable effort has been devoted to refining the PoW difficulty adjustment algorithm (DAA) in the context of feedback control. In comparison to Bonded Mining, these past approaches do not solicit information on future hash rate from miners. They suffer from oscillations and delay in reaching the target block time because they are reactive rather than proactive.
Alternative DAAs include methods by Kraft [20], Meshkov et al. [23], Fullmer and Morse [13], and Hovland et al. [17]. Meshkov et al. note that alternating between coins has an effect on inter-block time. Grunspan and Pérez-Marco [14] recently proposed a modified DAA that includes uncle blocks in the difficulty calculation to thwart selfish mining. The recent fork of Bitcoin Cash (BCH) [1] from the core Bitcoin blockchain [2] (BTC) sparked a flurry of DAA research. The principal concern was to mitigate affects of fickle mining [21], where miners abruptly move their hash power from the BCH to the BTC blockchain (or vice versa). See also Aggarwal and Tan for an analysis of mining during that time [3]. Séchet devised the algorithm cw-144 [28], which is currently used in BCH; it uses the ratio of the rolling average of chain work to block time and was based on an early model from Kyuupichan [6]. Harding’s wt-144 [16] is a similar solution, weighting block time by recency and block target. Stone [30] proposed adding tail removal to the algorithms above, which drives down the difficulty within a block interval in order to guarantee liveness and dampen block time oscillations.
We use a bond as collateral for a pledge to perform an offered hash rate over a specific period of time. Similarly, Proof of Stake (PoS) protocols (including hybrid PoW/PoS) [4, 11, 7] accept collateral as a pledge to act honestly in validating transactions over a specific period of time. We do not intend our work to be a replacement for PoS, but note that Bonded Mining similarly provides a fixed set of consensus participants that in our case are validated by PoW. For hybrids of PoW/PoS and hybrids of PoW/BFT[9, 19], Bonded Mining can bolster the performance of the PoW component.
8 Conclusion
We presented Bonded Mining, a proactive DAA for PoW blockchains that sets the mining difficulty based on bonded commitments from miners. The protocol incentivizes a miner to honor his commitment by confiscating a fraction of bond that is proportional to the deviation from his commitment. We developed a statistical test that is capable of detecting short- and long-range deviations from commitments with very low probability of falsely implicating honest miners. In simulation, and under reasonable assumptions, we showed that Bonded Mining is more successful at maintaining a consistent inter-block time than is the DAA of Bitcoin Cash, one of the newest and most dynamic DAAs in production. The present work is preliminary, having the following limitations: (i) currently the lowest hash rate miner that it supports has 1% of the total; (ii) we have only demonstrated defenses against two types of attacks; and (iii) we only directly compare Bonded Mining to the Bitcoin Cash DAA. Future work will seek to address these limitations. We recommend these limitations be fully investigated before deployment.
Appendix 0.A List of Symbols
[TABLE]
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] Bitcoin Cash. https://www.bitcoincash.org/ .
- 2[2] Bitcoin Core. https://bitcoin.org .
- 3[3] Aggarwal, V., and Tan, Y. A Structural Analysis of Bitcoin Cash’s Emergency Difficulty Adjustment Algorithm. http://dx.doi.org/10.2139/ssrn.3383739 , May 6 2019. · doi ↗
- 4[4] Bentov, I., Gabizon, A., and Mizrahi, A. Cryptocurrencies without proof of work. In Conf. on Financial Cryptography and Data Security (2016), Springer, pp. 142–157.
- 5[5] Bissias, G., and Levine, B. N. Bobtail: A Proof-of-Work Target that Minimizes Blockchain Mining Variance. Tech. Rep. ar Xiv:1709.08750, September 2017.
- 6[6] Booth, N. The K-1 Difficulty Adjustment Algorithm. https://github.com/kyuupichan/difficulty , August 2017.
- 7[7] Buterin, V., and Griffith, V. Casper the friendly finality gadget. https://arxiv.org/abs/1710.09437 , October 2017.
- 8[8] Casella, G., and Berger, R. L. Statistical inference . Brooks Cole, California, 2002.
