Double-Spend Attacks on Major Public Blockchains: Vulnerabilities and Mitigation

In 2008 Satoshi Nakamoto introduced Bitcoin, a peer‑to‑peer electronic cash system whose core security relies on Proof‑of‑Work (PoW) to prevent double‑spend attacks. Ten years later, numerous digital currencies exist, yet discussions often focus only on the 51% attack, ignoring many other practical double‑spend vulnerabilities.

1. Proof‑of‑Work and Double‑Spend Attacks – PoW requires each block to contain a hash that satisfies a difficulty target, forming a longest‑chain consensus that resists double‑spending unless an attacker recomputes the entire PoW.

2. New Classification of Double‑Spend Attacks – The authors categorize discovered vulnerabilities on EOS, NEO and other platforms into three groups: (1) insufficient verification, (2) state‑machine execution inconsistency, and (3) consensus‑engine induced forks.

3. Double‑Spend Caused by Insufficient Verification – Two NEO vulnerabilities are described: (a) GetInvocationScript allows different verification scripts for the same unsigned transaction, enabling an attacker to craft two conflicting outcomes; (b) MerkleTree binding can be bypassed by duplicating the last leaf when the number of leaves is odd, producing identical Merkle roots for different transaction sets.

4. Virtual‑Machine Execution Inconsistencies – Several EOS VM issues are detailed: (a) a remote‑code‑execution (RCE) vulnerability in the WASM function table; (b) uninitialized memory after grow_memory leading to nondeterministic behavior; (c) out‑of‑bounds memory reads that can be exploited for double‑spending; (d) inconsistent implementations of standard functions such as memcmp across platforms; (e) version‑specific differences in big‑integer division; (f) other sources of nondeterminism like system time or OOM conditions.

5. Consensus‑Engine Induced Double‑Spend – The paper examines ONT’s vBFT VRF implementation flaw where a private key of zero yields a constant VRF value, compromising randomness, and NEO’s dBFT consensus which can produce forks allowing double‑spends.

6. Efficient Mitigation for VM Execution Inconsistency – The authors propose recording the sequence of database write operations during block production, hashing this sequence (write_db_hash), and having full nodes recompute and compare the hash (write_db_hash') after executing transactions; mismatches indicate inconsistent execution and the block is rejected.

7. Conclusion – The study highlights the severity and variety of double‑spend attacks across major blockchains, notes that all reported vulnerabilities have been patched, and emphasizes ongoing research and responsible disclosure to improve blockchain security.