中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC063
Losing a device, losing every usable signing secret, losing current off-chain state and discovering that someone else can use your still-valid authority are four different problems. A backup that addresses one may do nothing for another.
The first recovery question is therefore not “Where is the restore button?” It is “What capability is missing or no longer trustworthy, and which independent capability already exists to address that specific loss?” The answer must include the system’s actual policy and state requirements.
This lesson compares four fictional loss cards. It does not ask for secrets, show recovery words, restore a real wallet or perform a channel operation. The result is a way to evaluate a recovery claim without confusing restored access with exclusive control or reversal of history.
Choose your reading route
In this guide
- 1. Name the object that must be recovered
- 2. Card A: the device is gone, but the complete recovery capability survives
- 3. Completeness includes the context needed to interpret the material
- 4. Card B: every usable signing copy is lost
- 5. Card C: the key returns, but current off-chain state does not
- 6. Do not turn peer assistance into a universal recovery promise
- 7. Card D: authority still works, but someone else has it too
- 8. A recovery dependency must survive the loss it is meant to handle
- 9. Replacement is not reproduction, and neither reverses history automatically
- 10. Define recovery success without exposing secrets
- 11. Compare the four conclusions directly
- 12. Exercises and worked answers
- Sources and next reading
Sections 1–3 define recovery objects and examine device loss. Sections 4–7 distinguish total authority loss, missing application state and compromised authority. Sections 8–10 test dependencies, preconfigured replacement and recovery evidence. Worked answers show which conclusions follow from the supplied facts and which remain unsupported.
For a short introductory discussion, see the recovery chapter in How Blockchain Works. For organisation-wide backup and incident principles, see Cybersecurity and Digital Resilience. This article focuses on matching loss type to a specific surviving capability.
Back to contents · Next section
1. Name the object that must be recovered
A device is a piece of equipment. Signing material is an authorisation capability. Application configuration explains which network, account and policy the software should use. Current off-chain state may contain protocol information not recoverable from a public chain alone.
A service login is another object. Restoring it may let a user request actions from a service without reconstructing any user-held signing secret. Conversely, possessing a signing secret does not necessarily restore a lost service account or its private records.
Recovery can also mean replacing an authority through a previously configured rule, rather than reproducing the old authority. That is a policy transition, with its own participants, conditions and evidence.
Keep the intended outcome explicit. Do we want to view public history, authorise future catalogue changes, safely resume a stateful protocol, regain exclusive control or correct an earlier application record? These are not interchangeable success criteria.
All cases below assume the stated cryptographic mechanisms and checks behave correctly. We do not infer a way to derive a lost private capability merely because its public verification information remains available.
Back to contents · Next section
2. Card A: the device is gone, but the complete recovery capability survives
A fictional curator loses device D, which held the working instance of signing authority K for a catalogue account. The account and accepted public history remain intact.
Before the loss, a recovery package was prepared. The card explicitly supplies that it contains all required signing material and compatible configuration, remains independently accessible, is intact, and can be interpreted by an appropriate trusted recovery environment. Any required unlocking information is also independently available. No unauthorised copy or device compromise is assumed in this card.
Under those conditions, loss of D does not imply loss of K’s recoverability. The surviving package supports restoration of the specified signing capability. The conclusion depends on the supplied completeness, accessibility and compatibility facts; a statement that “a backup exists” would not establish them by itself.
The restored capability still has to be associated with the intended account and current authorisation policy. Restoring an old signer that no longer has the relevant role would not restore the ability to perform that application action.
Likewise, restoring K does not automatically submit a request or change the catalogue. It restores a capability to participate in future authorised actions, subject to the application and chain rules.
Back to contents · Next section
3. Completeness includes the context needed to interpret the material
Deterministic key systems illustrate why recovery context matters. BIP32 defines a tree of derived keys, with derivation depending on the relevant inputs and indices. Reconstructing a root capability and selecting the intended account path are related but distinct tasks. BIP32
BIP39 specifies conversion of a mnemonic and its passphrase input into a seed. A different passphrase input can produce a different valid seed, so a plausible-looking result is not proof that the intended original account context has been recovered. We use this specification to explain input sensitivity, not to give an entry procedure or recommend a backup format. BIP39
These standards do not imply that every wallet uses the same scheme or that one item reconstructs every application state. A recovery claim must identify the actual format, needed inputs, configuration and intended account.
In Card A, those requirements were deliberately supplied as satisfied. In a variant where a required passphrase or configuration is missing, the conclusion must change to “the provided evidence does not establish complete recovery capability”. Do not pretend that an unspecified missing input is automatically available.
A display of an empty or unfamiliar account is not enough to distinguish all possible causes. It could reflect a different context, incomplete discovery or another problem. This lesson does not diagnose a real account from that symptom.
Back to contents · Next section
4. Card B: every usable signing copy is lost
Return to a separate fictional account with one required signing authority. Its device is gone, every usable copy of the signing material is lost, and no preconfigured replacement or alternate-authorisation rule exists. The user still knows the public account identifier and can inspect its history.
The public record helps establish what the account did. It does not supply the missing private authorisation capability under the assumed cryptographic model. The card therefore provides no recovery route for authorising new actions from that account.
A support agent able to reset an unrelated website password would not change this conclusion. That password is not the missing chain-recognised authority, and the card supplies no support-controlled replacement rule.
The careful statement is conditional: no recovery capability is supplied under these assumptions. It is not a claim about every account design, nor a prediction that all real loss reports have exactly these facts. A real system might have an alternate rule, but that rule needs evidence.
This case also separates record survival from access survival. The chain can continue preserving the account’s past while the user lacks the means to authorise its future actions. An intact ledger is not a universal account-recovery service.
Back to contents · Next section
5. Card C: the key returns, but current off-chain state does not
A third fictional case involves a stateful off-chain channel. The signing capability can be recovered, but the available application-state copy is an older record labelled L7. The supplied evidence says a later state L9 was established and L7 was superseded under the channel’s rules.
L7 and L9 are teaching labels, not a claim that a Lightning channel has one shared global state counter. The earlier channel lesson explains why each side can have its own commitment context and why an old signed object can remain cryptographically recognisable after it is no longer safe to use as current state.
Recovering the signing key does not establish which current protocol state should be used, which updates completed or which old commitments are no longer appropriate. The old copy’s existence and valid signatures do not answer those questions.
BOLT2’s channel-reestablishment rules use commitment and revocation context to reconcile peers’ views. They include conditions in which a node must not broadcast its local commitment. That is direct evidence that safe continuation depends on more than possession of signing material. BOLT2: Message Retransmission
Our conclusion is limited: the supplied key recovery and stale state do not establish safe continuation. We do not instruct the reader to broadcast, close a channel or apply one recovery process to every implementation.
Back to contents · Next section
6. Do not turn peer assistance into a universal recovery promise
A system may define a recovery interaction with another participant or retain special backup information. Whether that helps depends on what was retained, the protocol version, the peer’s available state and cooperation, and the exact failure being handled.
The existence of a reestablishment mechanism does not mean that any seed alone can reconstruct every lost off-chain update. Nor does it prove that an arbitrary stale snapshot is safe to activate.
For Card C, ask for the missing evidence: what current state is established, which backup information is applicable, and which supported procedure can reconcile it without violating the protocol’s rules? If those facts are absent, the answer remains unresolved rather than becoming a guessed recovery instruction.
This is different from Card B. In B, the required signing capability itself is unavailable. In C, the signing capability exists, but sufficient current protocol context is missing. The same “I restored the wallet” statement can conceal either distinction if it reports only a successful application launch.
The useful recovery record therefore lists separate results for authority, configuration, application state and supported continuation. Marking all four complete because one secret was reconstructed would erase the central risk in this case.
Back to contents · Next section
7. Card D: authority still works, but someone else has it too
In the fourth case, U retains a working signing capability and a correct backup. An adversary has obtained another usable copy of the same still-valid authority. There is no uncertainty about that premise in the fictional card.
Restoring U’s backup on another device may give U another working instance. It does not remove the adversary’s copy or change the account rule that accepts that authority. Availability has improved for U, but exclusive control has not been restored.
The response question is therefore different from ordinary loss recovery. What authorised mechanism, if any, can change which authority remains accepted, and what evidence would show that the change became effective? The answer depends on the actual account and application design.
A previously configured authority-replacement rule might support future control changes. That does not imply that changing a website password replaces a chain key, that every account supports revocation, or that a new device automatically invalidates old copies.
This is a conceptual distinction, not a live incident procedure. The case provides no permission or instruction to rotate keys, freeze an account or contact third parties. It asks why copying a backup is insufficient evidence of restored exclusivity.
Back to contents · Next section
8. A recovery dependency must survive the loss it is meant to handle
Consider a variant of Card A. A recovery package exists in remote storage, but the only way to unlock it is a secret stored solely on lost device D. No alternate unlocking capability is supplied.
The package’s existence no longer establishes accessible recovery. The design depends on the very object that has been lost. The missing capability must remain visible in the analysis rather than being assumed away because a cloud icon says “backed up”.
Another variant requires a service S to approve recovery, but S is unavailable. That does not necessarily mean the data is destroyed. It means the current recovery path lacks a required participant. If an alternate route exists, its scope and conditions must be established separately.
For a paper dependency test, list the required material, configuration, unlocking capability, participant approvals and current protocol information. Then remove the failed object named in the case. Any remaining requirement that still depends exclusively on that object is a potential circular recovery dependency.
This test is not a general backup prescription. It asks a precise question about one claimed capability: does it remain available under the failure that the recovery arrangement is supposed to tolerate?
Back to contents · Next section
9. Replacement is not reproduction, and neither reverses history automatically
Recall a fictional preconfigured account rule that lets G and S replace a lost user-authority slot after delay D and other conditions. If that route works, the new authority can occupy the slot without reconstructing the old secret.
The recovery evidence must identify the authorised policy transition and its effective state. A service email announcing approval is an earlier stage than a completed on-chain policy change. The old and new authorities’ scopes must be determined from the actual resulting rules.
That future-authority change does not automatically undo a past accepted action. Suppose an earlier mistaken catalogue update set a label to revision 3. The application may permit a later corrective revision 4 while preserving the historical record. Whether it does so is a supplied application rule, not an automatic effect of key recovery.
If the case supplies no correction mechanism, do not invent one. Likewise, a recovered signing capability does not create authority over another party’s account or restore a resource already consumed under the application’s rules.
Recovery should therefore report three separate questions: can the user act again, has exclusive authority been re-established if needed, and what remedy exists for prior effects? Solving one does not silently solve the other two.
Back to contents · Next section
10. Define recovery success without exposing secrets
A recovery assessment can use synthetic fixtures and public expected identifiers to check whether a proposed process reaches the intended account and policy context. Teaching exercises should not require real secrets, screenshots of recovery words or signing of unknown live requests.
For Card A, the success claim concerns the specified capability under the complete-package assumptions. For B, the record should acknowledge the absent capability. For C, it should retain unresolved current-state requirements. For D, it should distinguish user access from removal of unauthorised control.
A real organisation’s recovery validation also needs appropriate authority, protected handling and a defined procedure. This article does not substitute for that procedure. It identifies what a completion claim must demonstrate rather than walking through a restoration interface.
After a synthetic test, record which failure was assumed, which independent resources survived, which capability was restored and which conditions remain unknown. A passed test for device loss should not be advertised as proof that compromise or lost channel state is also handled.
The result should be understandable without revealing the underlying secret. Evidence of correct procedure and expected public context is different from publishing the material that gives someone authority.
Back to contents · Next section
11. Compare the four conclusions directly
Card A supplies an intact, complete, compatible and independently accessible recovery package. It supports restoration of the specified signing capability, with current role and application checks still relevant.
Card B supplies only public account evidence after all private signing material is lost and explicitly excludes replacement rules. It supplies no means to authorise future actions under that model.
Card C restores signing capability but lacks established current off-chain state. Safe continuation is not demonstrated. The remaining question concerns protocol context and the supported recovery design, not merely whether a key can sign.
Card D preserves or restores user access while an adversary retains the same valid authority. Exclusivity remains broken until an applicable authorised control change is established; the backup alone does not provide it.
The common lesson is not that recovery always works or never works. It is that every recovery claim has an object, a surviving capability, a dependency boundary and a limited result. Those details determine whether the claim answers the actual failure.
Back to contents · Next section
12. Exercises and worked answers
Question 1. Card A’s device is lost, but every stated recovery requirement survives independently. Does device loss alone prove the signing capability is unrecoverable?
Answer. No. The supplied complete and accessible package supports recovery of that capability under the case’s assumptions.
Question 2. In Card B, the public address and all historical transactions remain visible. Do they supply the missing signing material?
Answer. No, under the assumed cryptographic model. No alternate authorisation rule is supplied.
Question 3. Card C restores the key and opens the old L7 state. Is safe continuation established?
Answer. No. The case says L7 was superseded by L9. Current protocol context and a supported recovery basis remain necessary.
Question 4. In Card D, U restores the backup successfully. Has the adversary’s authority disappeared?
Answer. No. Restoration of U’s copy does not revoke another still-valid copy.
Question 5. A recovery file can only be unlocked with information on the lost device. Is “the file exists” enough?
Answer. No. The required independent unlocking capability is absent in that variant.
Question 6. A configured rule replaces an authority. Does that automatically erase a previously accepted catalogue update?
Answer. No. Future authority and remedies for past application effects are separate questions.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026:
- BIP32: Hierarchical Deterministic Wallets, status Deployed, assigned 11 February 2012, for deterministic derivation and its context.
- BIP39: Mnemonic code for generating deterministic keys, status Deployed, assigned 10 September 2013, for input-dependent seed derivation only.
- BOLT2: Message Retransmission, moving master specification, for state-sensitive channel reestablishment requirements.
The loss cards and recovery conclusions are original teaching constructions. No real material is generated, collected or restored. The next lesson examines how programmable accounts express authorisation and recovery rules, including the additional dependencies those rules introduce.