Full Report
In March of 2013, an unexpected Bitcoin fork occurred, as documented in BIP 50. This was because a block with many transactions was mined. Bitcoin 0.8 nodes could process it, but pre-0.8 nodes could not. This caused a fork because pre-0.8 Bitcoin nodes accounted for about 60% of the mining power. When switching to version 0.8, the upgrade now uses LevelDB instead of BerkeleyDB. BerkeleyDB had a limit on the number of transactions that could be in a block due to DB locks; this unintentionally became the new rule on the network. This limitation was removed on BerkeleyDB. A user deposited $10K in BTC to OKPAY, which was included in the 0.8 fork. After some analysis, they realized that the TX was never confirmed on the 0.7 fork. They then created two transactions from the OKPAY transaction and broadcast them on the pre-0.8 fork block. It's a double spend because one fork was actually being used by the payment provider, who used a different one. In reality, once the fork was detected, the payment processor should have stopped accepting Bitcoin transactions until the issue was resolved. Overall, a really interesting case of a double spend leading to stolen funds.
Analysis Summary
# Incident Report: The March 2013 Bitcoin Fork & OKPAY Double Spend
## Executive Summary
In March 2013, an unintentional chain fork occurred in the Bitcoin network due to a database incompatibility between Bitcoin version 0.8 (using LevelDB) and pre-0.8 versions (using BerkeleyDB). Exploiting this split, an attacker successfully executed a double-spend attack against the payment processor OKPAY, resulting in the theft of approximately $10,000 USD. The incident highlighted critical vulnerabilities in merchant automated acceptance during consensus failures.
## Incident Details
- **Discovery Date:** March 12, 2013
- **Incident Date:** March 11-12, 2013
- **Affected Organization:** OKPAY (Payment Processor) / BTC-e (Exchange)
- **Sector:** Cryptocurrency / Financial Services
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** March 12, 2013, 08:08 (UTC+8)
- **Vector:** Intentional deposit during a network split.
- **Details:** The user deposited 211.9093 BTC (~$10,000) to an OKPAY address to fund a BTC-e account.
### Lateral Movement
- **N/A:** This was an external double-spend exploit, not a traditional network intrusion.
### Data Exfiltration/Impact
- **Date/Time:** March 12, 2013, 10:08 (UTC+8)
- **Details:** The transaction was confirmed on the 0.8 chain fork. OKPAY’s automated system credited $9,800 to the attacker’s account, allowing for potential withdrawal or further trading.
### Detection & Response
- **Date/Time:** March 12, 2013, 12:53 (UTC+8)
- **Discovery:** The attacker realized the original transaction was rejected by the pre-0.8 chain (holding 60% of mining power) due to the BerkeleyDB lock limit.
- **Response:** The attacker used the Raw Transaction API to broadcast two new transactions using the same inputs (vins) on the pre-0.8 fork. These were confirmed at 13:01, successfully invalidating the payment to OKPAY on the winning chain.
## Attack Methodology
- **Initial Access:** Technical exploitation of a blockchain consensus failure (BIP 50).
- **Persistence:** N/A.
- **Privilege Escalation:** N/A.
- **Defense Evasion:** Exploited the fact that the payment processor was monitoring a different fork than the majority of the mining hashrate.
- **Credential Access:** N/A.
- **Discovery:** Analyzed block 225446 to identify that the transaction was missing from the BerkeleyDB-compatible chain.
- **Lateral Movement:** N/A.
- **Collection:** N/A.
- **Exfiltration:** Broadcasting double-spend transactions via Raw Transaction API.
- **Impact:** Theft of funds through ledger manipulation.
## Impact Assessment
- **Financial:** Loss of approximately $10,000 USD (211.9 BTC) for the payment processor.
- **Data Breach:** None.
- **Operational:** OKPAY and other merchants were forced to temporarily disable Bitcoin processing.
- **Reputational:** Significant concern regarding Bitcoin’s reliability as a payment method for high-value transactions.
## Indicators of Compromise
- **Network Indicators:** Forked blockchain at height 225446.
- **File Indicators:** Incompatibility between LevelDB (v0.8) and BerkeleyDB (v0.7).
- **Behavioral Indicators:** Sudden appearance of conflicting transactions (double spends) on parallel forks.
## Response Actions
- **Containment:** Community developers issued an emergency alert to downgrade 0.8 nodes to 0.7 to reunite the hashrate.
- **Eradication:** Miners moved hashrate to the 0.7 fork to ensure it became the "longest chain," eventually orphaning the 0.8-only blocks.
- **Recovery:** BTC-e and OKPAY updated their monitoring systems and paused transactions until the chain stabilized.
## Lessons Learned
- **Software Dependencies:** Changes in underlying database engines (BerkeleyDB to LevelDB) can introduce "accidental rules" that affect consensus.
- **Automated Risk:** Merchants and payment processors should never rely on low-confirmation counts during periods of high network instability or known software forks.
- **Consensus Vulnerability:** A majority hashrate on an older software version can override the ledger of a newer version.
## Recommendations
- **Safe Mode implementation:** Automated systems should enter a "Safe Mode" and pause processing if a block fork of more than 2 blocks is detected.
- **Version Parity:** Maintain consistency in consensus-critical code when upgrading node infrastructure.
- **Alert Monitoring:** Subscribe to official developer emergency broadcast channels for immediate notification of consensus failures.