> For the complete documentation index, see [llms.txt](https://dev-angelist.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev-angelist.gitbook.io/home/crypto-and-ai-ml/crypto-and-blockchain/blockchain-security/back-end-risks/3.1-consensus-vulnerabilities.md). # 3.1 Consensus Vulnerabilities ## **Consensus Vulnerabilities** Blockchain consensus mechanisms are vulnerable to various types of attacks that exploit weaknesses in how distributed networks reach agreement on the state of the ledger. These attacks can undermine the trustworthiness of the blockchain and disrupt the system's operations. Below are detailed explanations of several common consensus attacks, including **Majority Attack**, **Alternative History Attack**, **Finney Attack**, **Race Attack**, **Vector 76 Attack**, and **Replay Attack**. ### **Majority Attack (51% Attack)** A **Majority Attack**, also known as a **51% Attack**, occurs when a malicious actor or group of actors gains control of more than **50% of the computational power** or **stake** in a blockchain network. Once they have majority control, they can manipulate the consensus process in several harmful ways: * **Double-Spending**: By rewriting the blockchain's history, attackers can spend the same cryptocurrency more than once. * **Block Reorganization**: Attackers can force the network to accept a forked version of the blockchain, potentially invalidating legitimate transactions. * **Prevent Transactions from Being Confirmed**: They can halt or delay transaction confirmations by refusing to validate new blocks or controlling the block production process.
A **51% attack** is a major concern in **Proof of Work** (PoW) systems like Bitcoin but can also be a risk in **Proof of Stake** (PoS) systems, depending on the distribution of stakes. *** ### **Alternative History Attack (Long Range Attack)** In an **Alternative History Attack**, an attacker creates a **fork** from an earlier point in the blockchain’s history (often from the genesis block or another early block) and builds an alternative chain longer than the current main chain. This is sometimes called a **long-range attack**. * The attacker’s chain may be created offline and kept secret until it is sufficiently long to outpace the legitimate chain. * Once it is released, the blockchain network may accept the new, longer chain, effectively invalidating the original blockchain's history. This type of attack can be a concern in **Proof of Stake (PoS)** and **Delegated Proof of Stake (DPoS)** systems, especially if the network doesn’t have proper **finality** mechanisms like **checkpoints** to ensure that blocks can’t be rewritten after they’re validated. *** ### **Finney Attack** The **Finney Attack** is a type of **double-spending attack** that can occur in **Proof of Work** blockchains. It was named after Bitcoin developer **Hal Finney** who discovered this vulnerability. * **Mechanism**: The attacker creates a transaction that spends coins, and then they mine a new block that includes that transaction. The attacker then tries to send the transaction to the network before the newly mined block is broadcasted. This allows the attacker to **double-spend** the same coins by having the network accept the new transaction, while the original transaction is invalidated by the block they secretly mined. * The attack works because the attacker’s block is initially hidden and only becomes part of the blockchain once the original transaction is broadcast to the network. To prevent this, blockchain networks rely on **network propagation** times (ensuring that all participants receive transactions in time) and **block confirmation** processes that make it harder for an attacker to secretly mine a block and propagate a transaction. *** ### **Race Attack** A **Race Attack** is a type of **double-spending attack** where the attacker broadcasts two conflicting transactions to the network at the same time, with the goal of getting both transactions mined by different miners. * **Mechanism**: The attacker sends a transaction to one recipient (for example, a merchant) and at the same time sends a different conflicting transaction to the network. The goal is to get one transaction confirmed before the other, effectively tricking the recipient into accepting the transaction that they believe will be valid. * If the attacker’s version of the transaction is accepted first, they effectively double-spend the same funds. Race attacks rely on **transaction propagation** and the **timing** of the mining process. They can be prevented through various methods such as **zero-confirmation policies** (which involve merchant verification of transaction validity) and ensuring **proper propagation of transactions** through the network. *** ### **Vector 76 Attack** The **Vector 76 Attack** is an attack that targets the **transaction validation process** in blockchain networks, particularly in **Bitcoin-like** systems. The attack uses a malicious miner to **invalidate** a legitimate block, or to **force a reorganization** of the blockchain chain by causing a discrepancy between the accepted block and the attacker’s version. * **Mechanism**: The attacker exploits how Bitcoin nodes initially validate and broadcast blocks. By manipulating the way the nodes validate transactions, they can trick nodes into accepting a malicious or modified block (or transaction) as valid. * **Vector 76** is a type of attack that takes advantage of the **blockchain's consensus rules** and timing to interfere with the expected behavior of miners and validators. This vulnerability is especially relevant when nodes do not fully verify the chain’s history or fail to validate transactions correctly before accepting blocks into the chain. *** ### **Replay Attack** A **Replay Attack** occurs when a transaction that was **valid on one blockchain** is broadcasted on a **different blockchain**, and the transaction is accepted as valid there as well. This attack is particularly dangerous after a **hard fork** has occurred or when a blockchain splits into two versions. * **Mechanism**: After a fork, transactions on one chain can be replayed on the other chain because the same transaction data can be valid on both chains. This can result in **double-spending** or **unintended transactions** being executed on both chains. The attacker can take advantage of this and potentially steal funds. * **Example**: In the case of a hard fork, users might send a transaction on one chain (e.g., Bitcoin), and that transaction could be replayed on the other chain (e.g., Bitcoin Cash). If the user isn’t careful, they may inadvertently lose funds or have their transaction invalidated on one chain. **Replay protection** is the primary way to mitigate this attack. This is typically done by **adding unique transaction identifiers** or **chain-specific signatures** that prevent a transaction on one chain from being valid on another chain. *** ### **Mitigation Strategies for These Consensus Attacks** 1. **Finality Mechanisms**: Implementing finality mechanisms like **checkpointing** or **proof-of-authority** helps prevent attacks like **long-range** or **alternative history attacks** by ensuring that once a block is added to the blockchain, it cannot be easily altered. 2. **Multi-Signature Transactions**: For preventing attacks like the **Finney Attack** or **Race Attack**, **multi-signature wallets** can be used, requiring more than one signature to approve a transaction. 3. **Delayed Transactions**: Some systems may delay the acceptance of **zero-confirmation transactions**, which helps reduce the likelihood of race attacks by giving the network time to confirm that the transaction is legitimate. 4. **Replay Protection**: Ensuring that hard forks or chain splits have **replay protection** can prevent attackers from replaying valid transactions from one chain to another. 5. **Security Audits**: Regular auditing of blockchain consensus mechanisms, transaction validation processes, and node communications can help identify and patch vulnerabilities before attackers can exploit them. 6. **Incentive Structures**: Properly designed **incentive mechanisms** in **Proof of Work** and **Proof of Stake** networks help deter attacks like **51%** and **Sybil attacks** by making them prohibitively expensive or difficult to execute.