The cleanest way to explain Bitcoin inheritance via pre-signed transactions is also the source of the only operational mistake you can really make.

The mechanic: when you sign the inheritance transaction, you’re committing to specific UTXOs as inputs — particular chunks of Bitcoin sitting in your wallet at specific outpoints (txid:vout). The signed transaction says “spend these exact coins to my heir’s address at block N.”

If you later spend any of those coins for something else — paying a merchant, consolidating, sweeping to a new wallet — Bitcoin’s network sees the inheritance transaction’s inputs as “already spent” when the heir broadcasts later. The network rejects it. The inheritance is invalid.

This is simultaneously:

  • A feature: it’s how you cancel an inheritance plan. Spend any committed UTXO and the plan is dead, no permission needed, no third party involved. You don’t need our app, you don’t need to call a lawyer — you just transact normally and the plan auto-cancels.

  • A footgun: you can accidentally cancel by not thinking about which coins are committed. Consolidate your wallet to clean up dust → cancel. Pay a merchant from your only wallet → cancel. Sweep to a new wallet for any reason → cancel.

The footgun side is the one that matters operationally. Let’s talk about how to think about it and the two practical mitigations.

The double-spend mechanic, exactly

Bitcoin transactions consume UTXOs as inputs and produce new UTXOs as outputs. A UTXO can only be spent once — that’s the whole anti-double-spend property the protocol exists to enforce.

When you build an inheritance plan:

  1. We list your current UTXOs (we sync your wallet via a watch-only descriptor)
  2. You pick which to commit — say 2 BTC across 3 specific UTXOs
  3. The wizard helps you build + sign a transaction that spends those 3 UTXOs to your heir’s address
  4. The signed transaction sits idle until the unlock block

If, three months later, you spend any one of those 3 UTXOs in a normal transaction:

  1. The normal transaction is broadcast, mined, confirmed
  2. That UTXO is now consumed — it doesn’t exist anymore
  3. Your inheritance transaction’s input list references a UTXO that no longer exists
  4. When the heir tries to broadcast at the unlock block, the network rejects: “missing inputs” / “bad-txns-inputs-missingorspent”

The signed transaction itself is still valid as a cryptographic object — your signature still verifies. But it can’t be spent on a chain where those UTXOs don’t exist.

Why this is the right design

A naive observer might say “why not let the inheritance transaction track the wallet’s balance, like a sweep?” — and the answer is: because we’d need ongoing access to your private keys to re-sign whenever you transact. That’s the world we’re explicitly trying to avoid. The whole non-custodial value prop comes from “sign once, network handles the rest.”

Committing to specific UTXOs is the price of true non-custodial. The alternative is custodial inheritance, which we have several flavors of in the market and which fail in different (worse) ways.

So: how do you live with it?

Mitigation 1: dedicated fresh wallet

The cleanest answer. Create a new wallet (fresh seed or fresh account on your hardware wallet — both work) that you use only for the inheritance amount. Send the BTC you want to set aside from your primary wallet to this dedicated one. Build the inheritance from the dedicated wallet’s UTXOs. Then don’t touch the dedicated wallet until the unlock block.

Why it’s clean:

  • Zero chance of accidental invalidation — you literally never transact from this wallet
  • Clear mental model — “this wallet is for my heir; my main wallet is for me”
  • Easy to update — if you want to change the inheritance, send more BTC to the dedicated wallet OR build a new plan from a new dedicated wallet
  • Survives wallet software changes — your daily-driver wallet can be upgraded / migrated independently

The trade-offs:

  • One extra wallet to remember + secure (extra seed phrase, extra hardware-wallet account, etc.)
  • An on-chain transaction to fund it, which costs a small fee and creates a trace
  • If you DO accidentally lose the dedicated wallet’s keys, the inheritance still works (the recipient address is the heir’s, not yours) — but you’ve lost the ability to cancel

This is what we recommend for most users. The setup overhead is small; the operational simplicity downstream is large.

Mitigation 2: cold UTXOs from an existing wallet

If you don’t want another wallet, you can use UTXOs from your existing wallet that you mentally treat as “savings” — long-held coins you have no intention of spending.

Examples of good candidates:

  • Long-held purchases from years ago that you’ve been HODL-ing
  • Mining rewards from your own miner that you’ve never touched
  • Specific UTXOs you’ve consciously labeled “cold storage” in your wallet’s UTXO management
  • The output of a recent consolidation that grouped your savings together

Examples of bad candidates:

  • Recently-received UTXOs that mix with spending money
  • UTXOs at addresses near the front of your wallet’s derivation path (your wallet will auto-select these for outgoing payments)
  • Anything that overlaps with how you normally select coins when spending

The technique requires real attention to your wallet’s coin-selection behavior. Most wallets default to “smart selection” that picks UTXOs to minimize change or fees — which means they’ll happily pick a UTXO you’d mentally labeled “for the inheritance.” You need to either:

  • Use a wallet with explicit coin control (Sparrow, Electrum, Bitcoin Core CLI all support it) and manually exclude your committed UTXOs from every outgoing transaction
  • Or use the dedicated-wallet mitigation instead, which removes the cognitive load

Cold UTXOs are workable for very disciplined users. They’re a sharp tool. The dedicated-wallet approach is duller and safer.

What Bitheritance does to surface this

We have the Pro Tip callout at the top of every build step:

Use a wallet (or address) you won’t touch until unlock. The inheritance plan commits the specific UTXOs you spend in this transaction. If you later spend any of those same coins from the source wallet, Bitcoin treats your timelocked tx as a double-spend — it becomes invalid, and the heir is left with nothing.

And on the saved-plans page, we run a UTXO-conflict check across all your saved plans — if two plans share UTXOs (which means broadcasting one invalidates the other), we surface a “shares UTXOs” badge so you can see the dependency at a glance.

Neither catches all accidental invalidations — only chain monitoring (which we offer as a Pro feature) can tell you definitively when your plan has actually been invalidated by a chain event. The combination of careful build-time setup + chain monitoring + occasional manual review is what makes this approach robust over multi-year horizons.

What to do if you’ve already invalidated a plan

You spent a UTXO that was committed; your plan is now invalid. What now?

  1. Confirm the invalidation — open the plan in Bitheritance, the chain-status check tells you definitively whether the inputs are still available
  2. Decide whether to rebuild — if you still want the inheritance set up, build a new plan from your current UTXOs. The OLD plan stays cryptographically signed but is just useless data now; it can’t accidentally fire later.
  3. Re-share with the heir — if you’d already given the old plan to your heir, make sure they know about the replacement. The handoff kit PDF should be re-printed. The share URL changes.
  4. Bump any associated alerts — if you’d set up monitoring on the old plan, monitor the new plan instead.

Invalidation isn’t a disaster; it’s a cancel-and-rebuild. The cost is the time to re-do the wizard + re-share with the heir. The savings, if your circumstances genuinely changed and you wanted to cancel, is “you got cancellation for free as a side effect of spending normally.”

This is the operational thing every user of a pre-signed-transaction inheritance product has to internalize. The pre-signed model has lots of elegance, but it’s not maintenance-free. Treat your committed UTXOs like cold storage — fresh wallet ideally, cold UTXOs with discipline if you must — and you’ve removed the only footgun in the architecture.