Learning Objectives – after this chapter you will be able to:
- Explain double spending and how blockchains prevent it.
- Describe network-level attacks: 51%, Sybil, eclipse and DDoS.
- Recognise common smart-contract vulnerabilities and their defences.
- Distinguish soft forks from hard forks with real examples.
Double Spending
- Double spending means spending the same digital money twice. Digital files can be copied, so preventing this without a bank was the key problem Bitcoin solved.
- Blockchains prevent it by keeping one agreed order of transactions: once a coin (UTXO) or a nonce is used, any conflicting transaction is invalid.
- Attempts usually target unconfirmed or recently confirmed transactions – for example by broadcasting two conflicting payments (race attack) or by rewriting recent blocks with majority power. Waiting for enough confirmations (or for finality in PoS) defeats these attempts.
Network-Level Attacks
| Attack | How it works | Defence |
|---|---|---|
| 51% / majority attack | Controlling most of the hash power (PoW) or a large share of stake (PoS) to reorder or censor recent transactions. | Large, decentralized networks; confirmations; slashing and finality in PoS. |
| Sybil attack | Creating many fake identities/nodes to gain influence. | Influence tied to scarce resources (work or stake), not node count. |
| Eclipse attack | Surrounding a victim node with attacker-controlled peers so it sees a false view of the chain. | Diverse peer connections, peer limits per IP range. |
| DDoS | Flooding nodes or the network with requests or spam transactions. | Transaction fees/gas, rate limits, robust clients. |
| Selfish mining | A miner withholds found blocks to gain an unfair share of rewards. | Honest-majority assumptions, protocol improvements. |
Smart-Contract Vulnerabilities
| Vulnerability | Description | Defence |
|---|---|---|
| Reentrancy | An external contract calls back into the victim before its state is updated, withdrawing funds repeatedly. The 2016 DAO exploit used this. | Checks-Effects-Interactions pattern; reentrancy guards. |
| Integer overflow / underflow | Arithmetic wraps around, e.g. 0 − 1 becomes a huge number. | Solidity ≥ 0.8 reverts on overflow by default. |
| Access-control errors | Sensitive functions (mint, withdraw, upgrade) callable by anyone. | Proper ownership/role checks; never use tx.origin for authorisation. |
| Front-running / MEV | Others see a pending transaction in the mempool and place their own transaction before it. | Commit-reveal schemes, slippage limits, private transaction relays. |
| Oracle manipulation | Attackers distort a price source the contract trusts (Chapter 28). | Decentralized oracles, time-weighted prices. |
Reentrancy – vulnerable vs safe
// VULNERABLE: sends ETH before updating the balance
function withdraw() external {
uint256 amount = balances[msg.sender];
(bool ok, ) = msg.sender.call{value: amount}(""); // attacker re-enters here
require(ok);
balances[msg.sender] = 0;
}
// SAFE: Checks → Effects → Interactions
function withdraw() external {
uint256 amount = balances[msg.sender]; // check
balances[msg.sender] = 0; // effect (update state first)
(bool ok, ) = msg.sender.call{value: amount}(""); // interaction
require(ok);
}
Security practice: testing, independent audits, formal verification for critical code, bug bounties, and starting with limited funds.
Forks: Soft Fork vs Hard Fork
| Basis | Soft Fork | Hard Fork |
|---|---|---|
| Rule change | Rules become stricter | Rules are changed or relaxed |
| Compatibility | Backward-compatible – old nodes still accept new blocks | Not backward-compatible – old nodes reject new blocks |
| Upgrade need | Mainly block producers must upgrade | All nodes must upgrade to stay on the new chain |
| Chain split? | Usually no permanent split | Permanent split if part of the community refuses |
| Examples | Bitcoin SegWit (2017), Taproot (2021) | Ethereum/Ethereum Classic (2016), Bitcoin/Bitcoin Cash (2017); Ethereum’s planned network upgrades |
A temporary (accidental) fork also happens when two blocks are found at nearly the same time; it resolves automatically through the fork-choice rule (Chapter 15).
Key Takeaways
- Consensus and confirmations prevent double spending; majority attacks target recent history.
- Most large losses come from smart-contract bugs such as reentrancy and access-control errors.
- Soft forks tighten rules (compatible); hard forks change rules (incompatible, may split the chain).
Question / Answer (15 questions)
Answer : It is the risk that the same digital money is spent more than once, because digital data can be copied. A payment system must ensure each unit of value can be used only once.
Answer : All nodes agree, through consensus, on one ordered history of transactions. Once a UTXO is spent or an account nonce is used, any conflicting transaction is invalid and rejected.
Answer : Unconfirmed or very recent transactions can still be replaced by a conflicting transaction or a chain reorganisation. Waiting for several confirmations (PoW) or finality (PoS) makes reversal impractical.
Answer : An attacker with majority hash power (or a large share of stake) can reorder or censor recent transactions and double-spend their own coins. They cannot create coins out of nothing, change protocol rules or spend other people’s coins without their private keys.
Answer : An attacker isolates a target node by controlling all of its peer connections, so the node sees only the attacker’s version of the network. This can be used to double-spend against the victim or waste its mining power.
Answer : A mining strategy where a miner withholds newly found blocks and releases them strategically to cause honest miners to waste work, earning a larger share of rewards than its share of hash power.
Answer : A malicious contract repeatedly calls back into a vulnerable contract before the vulnerable contract updates its state, for example withdrawing the same balance many times. It was used in the 2016 DAO exploit.
Answer : A function should first check all conditions, then update its own state (effects), and only then interact with external contracts or send ETH. Updating state before external calls prevents reentrancy.
Answer : From version 0.8.0, arithmetic operations are checked by default; an overflow or underflow causes the transaction to revert instead of silently wrapping around.
Answer : tx.origin is the EOA that started the transaction, not the immediate caller. A malicious contract called by the victim could pass a tx.origin check and act on the victim’s behalf. msg.sender should be used instead.
Answer : Front-running occurs when someone sees a pending transaction in the public mempool and gets their own transaction included before it, often to profit from a predictable price change. Value extracted this way is called MEV (Maximal Extractable Value).
Answer : A soft fork tightens the protocol rules in a backward-compatible way: blocks valid under the new rules are also valid for old nodes. Bitcoin’s SegWit and Taproot upgrades were soft forks.
Answer : A hard fork changes the rules in a way that is not backward-compatible; old nodes reject the new blocks. If part of the community does not upgrade, the chain splits permanently, as with Ethereum and Ethereum Classic in 2016.
Answer : In 2017 part of the Bitcoin community disagreed about how to scale Bitcoin and created a hard fork with larger blocks, resulting in a separate chain called Bitcoin Cash.
Answer : Thorough automated testing, independent security audits, use of well-tested libraries and patterns (such as Checks-Effects-Interactions and reentrancy guards), and bug-bounty programmes; formal verification is used for critical contracts.
MCQ Test : Check Your Understanding (5 questions)
Select an option and press Check Answer, or answer all questions and press Submit Test to see your score. Each answer comes with an explanation.
Bibliography/References
The notes, questions and MCQs on this page are original explanations written for this course. The works listed below were consulted and are cited for attribution and further reading. Product names, logos and trademarks belong to their respective owners. Short quotations, where used, are marked and attributed.
- Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
- ethereum.org. (n.d.). Smart contract security. Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/smart-contracts/security/
- Solidity Team. (n.d.). Security Considerations. Solidity Documentation. https://docs.soliditylang.org/en/latest/security-considerations.html
- Bitcoin Project. (n.d.). Bitcoin Developer Guide. developer.bitcoin.org. https://developer.bitcoin.org/devguide/
- Narayanan, A., Bonneau, J., Felten, E., Miller, A., & Goldfeder, S. (2016). Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press. ISBN 978-0-691-17169-2.
- Antonopoulos, A. M., & Wood, G. (2018). Mastering Ethereum: Building Smart Contracts and DApps. O’Reilly Media.