bitcoinafterlife
254045dc16
Some checks failed
Build and deploy docs / deploy (push) Has been cancelled
47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
# Keeping the will up to date
|
||
|
||
An inheritance transaction spends specific UTXOs. If those UTXOs change, the transaction the Will-Executors are holding becomes invalid — so the will has to be rebuilt.
|
||
|
||
The plugin handles this for you: **every time you close Electrum it checks your balance and UTXO set**, and if something changed it asks you to refresh the will. You confirm the signature; it never signs on your behalf.
|
||
|
||
This is what makes it practical to use an inheritance-ready wallet for everyday transactions.
|
||
|
||
## What triggers a refresh
|
||
|
||
- You receive funds.
|
||
- You spend funds.
|
||
- You add, remove, or edit an heir.
|
||
- You change the delivery date.
|
||
|
||
## Postponing vs anticipating
|
||
|
||
The two directions are not symmetric, and the difference has a real cost:
|
||
|
||
=== "Anticipating (earlier date)"
|
||
|
||
Bringing the delivery date **forward** is cheap. The plugin signs a new inheritance with an earlier locktime and sends it to the Will-Executors. Because it becomes valid sooner, it supersedes the previously distributed transaction — **no on-chain fee**.
|
||
|
||
This is also how balance and heir changes are handled: the will is anticipated by one day and redistributed, without invalidating the old one on-chain.
|
||
|
||
=== "Postponing (later date)"
|
||
|
||
Pushing the delivery date **back** requires invalidating the committed coins **on-chain first**. Otherwise a Will-Executor still holding the old, earlier-locktime transaction could broadcast it and execute the inheritance too early.
|
||
|
||
That invalidation is a real Bitcoin transaction: you sign it and it costs a **miner fee**.
|
||
|
||
!!! tip
|
||
If you expect to adjust the date often, plan for it: a rolling deadline that you re-anticipate is cheaper than repeatedly postponing.
|
||
|
||
## Watch-only copies on other devices
|
||
|
||
If you monitor the same wallet from another device using its public key (Zpub/Xpub), funds arriving there are **not** added to the inheritance automatically. Open the wallet in Electrum with the plugin so it can pick up the new UTXOs and re-send the updated will to the Will-Executors.
|
||
|
||
!!! danger "The same seed on multiple devices invalidates the inheritance"
|
||
Using the same seed on more than one device is strongly discouraged in general. With BAL it has a specific consequence: spending even a single satoshi from the other device changes the wallet's UTXO structure, and the nodes will **discard the inheritance transaction** when the Will-Executors try to broadcast it.
|
||
|
||
## How often to renew
|
||
|
||
Renewing is not strictly required, but it is recommended roughly **every 2–3 years**. A practical approach is a rolling deadline — "always five years from today" — refreshed at regular intervals.
|
||
|
||
Renewing serves two purposes: it lets you include Will-Executors that joined the network in the meantime (and drop the ones that shut down), and it picks up future protocol changes.
|