Your wallet, your keys, and your bitcoin: what lives where?

The phone is not a box of coins

Noor’s phone breaks. Does that destroy her bitcoin? The answer depends on what the phone controlled and what recovery information survives. The coins are not little files trapped inside the screen.

A Bitcoin wallet can discover relevant transactions, track outputs, estimate a balance, prepare payments, and arrange signing. The chain records outputs and their spending conditions. Secret signing material enables authorized spending when the conditions are satisfied.

These responsibilities can live in different places. A desktop app may construct a transaction while a hardware device signs it. A watch-only app may display funds without being able to spend them. A custodial service may show an account balance while holding the relevant keys itself.

Four places to look

For Noor’s noncustodial example, put the app in the interface box, the signing material in the authority box, relevant outputs in the public record box, and recovery information in the backup box.

The boxes can overlap physically, but their jobs differ. Reinstalling the app is not the same as restoring authority. Knowing an address is not the same as controlling the keys. Seeing a balance is not evidence that the current device can sign.

Conversely, losing a displayed transaction list does not necessarily lose the underlying outputs. Appropriate wallet software can rediscover history from the network if it has the required recovery information and knows what to look for.

Backups must match the wallet’s actual design

Hierarchical deterministic wallets can derive many keys from a root according to specified paths. That lets a compact backup support a much larger key tree. It does not mean every string called a recovery phrase reconstructs every wallet feature in every implementation.

A wallet may also depend on a passphrase, script type, derivation information, descriptors, multisignature cosigner configuration, or device-specific recovery procedures. Lightning adds changing channel state and its own backup requirements; an on-chain key recovery explanation must not be silently extended to channels.

For a custodial service, the recovery process may be an account recovery process with the provider. That is a different trust arrangement from independently controlling the keys. Calling both products “wallets” can hide this difference.

The right question is not “Which brand looks secure?” It is “What capability would remain if this device, app, or provider became unavailable?” This lesson maps the question; actual backup procedures must come from the specific wallet’s current documentation.

Run a paper recovery exercise

Use fictional labels, never real secrets. Make four cards:

Phone app       Signing device
Public outputs  Recovery material

Remove the phone-app card. Describe what would be needed to recover the ability to discover and spend the outputs. Then remove the signing-device and recovery-material cards together. Explain why a visible public record does not replace missing signing capability.

Expected result: recovery is about restoring the right authority and metadata, not downloading coins into a new container. Finally, add a “provider account” card and redo the exercise for a custodial product. The provider’s recovery and withdrawal rules now matter.

If you later practice with software, use a local test environment and the wallet’s documented recovery procedure. The conceptual exercise does not validate any particular real backup.