A replay attack occurs when a valid message or authorisation is reused in a context where it should not authorise another action. Cryptographic signatures can prove a message was signed by a key, but without suitable context and freshness checks, a copied signed message may be misused.
Alicia signs a paper slip allowing Tricia to borrow one science kit on Monday. Kai Kai finds a photocopy and tries to use it again on Tuesday. The original signature is genuine; the problem is that the permission was meant for one action in one context.
This chapter is for children, parents and adult beginners. It explains blockchain as technology rather than cryptocurrency investment. All school examples are fictional, and no real wallets or student information are needed.
The answer in one minute
A replay attack occurs when a valid message or authorisation is reused in a context where it should not authorise another action. Cryptographic signatures can prove a message was signed by a key, but without suitable context and freshness checks, a copied signed message may be misused.
A school story to make it clear
Alicia signs a paper slip allowing Tricia to borrow one science kit on Monday. Kai Kai finds a photocopy and tries to use it again on Tuesday. The original signature is genuine; the problem is that the permission was meant for one action in one context.
1. A valid signature is not a one-time ticket
A signature checks a relationship between a key and signed data. If the message contains no appropriate unique reference, expiry, sequence or context, an application may mistakenly accept it more than once.
2. Replay across networks
After a network split or between similarly configured chains, a transaction intended for one chain may be replayable on another unless the signing and validation design separates those contexts. Ethereum’s EIP-155 introduced chain-ID-based replay protection for certain transaction types.
3. Replay within an application
A smart contract that accepts signed approvals may need a nonce, unique message identifier or consumed-status record. Chain ID alone does not stop repeated use of a signature within the same application.
4. Domain separation helps define context
Well-designed signed messages identify the relevant application, network, contract or action as appropriate. A signature for one purpose should not silently become valid permission for another.
5. Expiry and revocation have limits
An expiry condition can stop a message being accepted after a cutoff. Revocation or nonce consumption can prevent later reuse under the application’s rules. Neither can undo a transfer already completed before the protection took effect.
6. A screenshot is not proof of safe authorisation
A wallet may show a simplified signing request. Users should know what the signed message permits, its domain, spender, amount and any validity window. A request that transfers no assets immediately can still grant dangerous authority.
7. Why double spending is a different concept
Double spending concerns conflicting uses of digital value under a ledger’s rules. Replay concerns reusing an authorisation in an unintended context. They can interact, but should not be taught as identical attacks.
8. Paper activity: use once
Write a pretend borrowing permission with a unique reference and a single-use box. Have the organiser mark it consumed. Present a photocopy and ask why the second attempt should fail even though the signature matches.
9. The real-world limit
Preventing replay does not prove that a borrowed science kit was returned or that the original permission was fair. The institution still needs evidence and accountable procedures.
A five-question evidence check
What was requested? Who had permission? What digital result can be checked? Which network and state reference apply? What physical or institutional fact remains uncertain? These questions keep technical validity separate from real-world truth.
A parent-and-child activity
Use the paper exercise above. First complete the normal sequence. Then change a rule, hide a message or introduce an incorrect entry. Ask which evidence is missing and how a responsible person should resolve it. The exercise illustrates logic, not cryptographic security.
When a simpler system is enough
A school can often use a conventional database, signed approvals and an audit log. Blockchain adds value only if its independent verification or governance properties address a specific requirement that simpler alternatives do not meet.
Frequently asked questions
Does this guarantee the physical-world claim is true?
No. The mechanism supports a defined digital check under its assumptions. Physical delivery, fair decisions and educational achievement need separate evidence.
Do children need cryptocurrency to understand this?
No. Paper cards and fictional records are sufficient. No investment, keys or live accounts are necessary.
Does every blockchain work this way?
No. These mechanisms have platform-specific rules, particularly for Ethereum. Check the actual network and contract design before applying them.
Continue through the learning hubs
Read the related practical chapter, the English learning hub, the Chinese learning hub and the Master Blockchain hub.
Sources and scope
Technical source: https://eips.ethereum.org/EIPS/eip-155. General background: NIST Blockchain Technology Overview. School scenarios are fictional and do not describe a deployed eduKateSG blockchain.