Select Language

Analysis of Hashrate-Based Double-Spending in Bitcoin

A quantitative analysis of the stochastic processes underlying double-spending attacks in Bitcoin, focusing on attack probabilities, confirmation waiting times, and economic implications.
computingpowercoin.com | PDF Size: 0.1 MB
Rating: 4.5/5
Your Rating
You have already rated this document
PDF Document Cover - Analysis of Hashrate-Based Double-Spending in Bitcoin

Table of Contents

1. Introduction

Bitcoin's security model hinges on preventing double-spending—the malicious act of spending the same digital coin twice. This paper provides a quantitative, stochastic analysis of double-spending attacks based on an attacker's hashrate. It clarifies and expands upon the foundational statistical model presented in Satoshi Nakamoto's original whitepaper, moving from qualitative understanding to precise probabilistic frameworks.

2. The Blockchain and Branch Selection

The Bitcoin blockchain is a tree of blocks, each referencing its predecessor. Network consensus selects the longest chain (or the chain with the most cumulative proof-of-work) as the valid history. Temporary disagreements (forks) are resolved when a new block extends one branch, making it longer. This mechanism is the battleground for double-spending attacks, where an attacker secretly builds an alternative chain.

3. Playing Catch-Up

This section models the core attack scenario: an attacker with a fraction q of the total network hashrate tries to overtake the honest chain (with hashrate p = 1 - q) after being z blocks behind. The process is modeled as a Binomial Random Walk. The probability of the attacker ever catching up from a deficit of z blocks is derived as:

$P = \begin{cases} 1 & \text{if } q \ge p \\ (q/p)^z & \text{if } q < p \end{cases}$

This elegant result shows that for an attacker with less than 50% of the hashrate (q < 0.5), the success probability decreases exponentially with the number of confirmations z.

4. Waiting for Confirmations

The analysis shifts to the merchant's perspective: how many confirmations (n) should one wait before considering a transaction secure? The paper calculates the probability that an attacker could still succeed after the merchant sees n confirmations. This involves calculating the probability that the attacker finds n+1 blocks before the honest network finds n blocks, factoring in the ongoing race. The resulting probabilities provide the foundation for recommended confirmation depths.

5. Graphs and Analysis

The paper presents graphical analyses plotting the probability of a successful double-spend against the number of merchant confirmations (n) for various attacker hashrates (q). Key insights visualized include:

These graphs are crucial for risk assessment and setting practical confirmation policies.

6. Economics of Double-Spending

The paper introduces an economic model, framing the attack as a gambler's ruin problem with variable stakes. The attacker's potential reward is the value of the transaction he aims to double-spend. The analysis considers the expected value of the attack for the attacker, concluding that unless the value of the stolen goods is extremely high relative to the block reward, a rational attacker with q < 0.5 would find mining honestly more profitable than attempting double-spends. This aligns with game-theoretic security principles.

7. Conclusions

The analysis provides a rigorous mathematical foundation for understanding double-spending risk. It confirms that the Bitcoin protocol is highly robust against double-spending by attackers with less than 50% of the network hashrate, provided recipients wait for a sufficient number of confirmations. The work quantifies the security trade-off between confirmation time and risk tolerance.

8. Core Insight & Analyst's Perspective

Core Insight: Rosenfeld's work isn't just math; it's the first rigorous risk pricing model for Bitcoin's settlement layer. He transforms Nakamoto's intuitive "longest chain rule" into a quantifiable security SLA (Service Level Agreement), where confirmation depth n is the premium paid for a specific probability of finality 1-P. This is the bedrock upon which all modern crypto-exchange security policies are built.

Logical Flow: The genius lies in framing the attack as a Binomial Random Walk—a classic stochastic process. By modeling block discovery as a Poisson process, Rosenfeld reduces the chaotic, parallel mining race to a solvable one-dimensional gambler's ruin problem. The leap from Section 3 (catch-up probability) to Section 4 (merchant waiting time) is critical; it bridges the attacker's capability to the defender's policy.

Strengths & Flaws:
Strengths: The model's simplicity is its strength. The closed-form solution $P = (q/p)^z$ is powerful and easily interpretable. The economic analysis in Section 6 was ahead of its time, prefiguring today's rigorous blockchain game theory research seen at venues like the ACM Conference on Advances in Financial Technologies (AFT).
Critical Flaw: The model assumes a static adversary with a fixed q. It fails to account for strategic, fluctuating hashrate—like an attacker renting massive cloud mining capacity in a short, targeted burst (a "Goldfinger attack"), a threat highlighted in later research like the "Mining Pool" paper by Eyal and Sirer. It also ignores network latency and selfish mining strategies that can effectively increase an attacker's effective q.

Actionable Insights: 1. For Exchanges: Don't use a one-size-fits-all confirmation number. Use Rosenfeld's formula dynamically. For a $100 deposit, 3 confirmations may suffice. For a $10 million withdrawal, you need dozens, or better yet, move to a finality-gadget-enhanced chain. 2. For Protocol Designers: This paper is the canonical argument for Proof-of-Stake (PoS). The exponential security cost ((q/p)^z) in PoW is economically brutal. PoS systems like Ethereum's Casper, as documented in its research specifications, seek to replace this probabilistic finality with cryptographic, slashable finality, fundamentally altering the attack calculus. 3. For Merchants: The real takeaway is that for small-value, instant payments (like coffee), waiting for any confirmations is impractical. This economic reality directly fueled the development of off-chain payment channels (the Lightning Network), which sidestep Rosenfeld's problem entirely by moving transactions off the base layer.

9. Technical Details & Mathematical Framework

The core model treats block discovery as independent trials. Let p be the probability the honest chain finds the next block, and q = 1-p for the attacker. The state of the system is the attacker's deficit z. The probability p_z that the attacker ever reaches parity from deficit z satisfies the recurrence relation derived from the gambler's ruin problem:

$p_z = q \cdot p_{z-1} + p \cdot p_{z+1}$

With boundary conditions p_0 = 1 (parity is success) and p_\infty = 0. Solving this yields the closed-form solution $p_z = (q/p)^z$ for q < p.

For the merchant scenario with n confirmations, the probability the attacker succeeds is the probability he can build a chain longer than the honest chain starting from n blocks behind. This is calculated by summing over all possible lead scenarios when the merchant broadcasts the transaction.

10. Analysis Framework: Example Case

Scenario: A cryptocurrency exchange receives a large deposit. It must decide how many confirmations to require before crediting the user's account.

  1. Define Parameters:
    • Attacker's estimated hashrate share: q = 0.2 (20%). This could be based on public mining pool data.
    • Value at risk (deposit amount): V = $500,000.
    • Exchange's risk tolerance: Acceptable probability of double-spend: $\epsilon = 0.001$ (0.1%).
  2. Apply Rosenfeld Model: We need to find the smallest n such that the attack probability $P(n, q) \le \epsilon$. Using the formula $P \approx \sum_{k=0}^{\infty} \frac{\lambda^k e^{-\lambda}}{k!} \cdot (q/p)^{n+1-k}$ for $k \le n+1$ (where $\lambda = n(q/p)$), or consult pre-computed graphs/tables.
  3. Calculation/Result: For q=0.2 and \epsilon=0.001, the required confirmations n is approximately 9.
  4. Policy Decision: The exchange sets its confirmation requirement for this asset to 9 blocks. For a block time of 10 minutes, this implies a 90-minute holding period for the deposit, balancing security and user experience.

11. Future Applications & Research Directions

12. References

  1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
  2. Rosenfeld, M. (2014). Analysis of Hashrate-Based Double-Spending. arXiv:1402.2009.
  3. Eyal, I., & Sirer, E. G. (2014). Majority is not Enough: Bitcoin Mining is Vulnerable. International Conference on Financial Cryptography and Data Security.
  4. Buterin, V., & Griffith, V. (2017). Casper the Friendly Finality Gadget. arXiv:1710.09437.
  5. Gervais, A., Karame, G. O., Wüst, K., Glykantzis, V., Ritzdorf, H., & Capkun, S. (2016). On the Security and Performance of Proof of Work Blockchains. ACM SIGSAC Conference on Computer and Communications Security.