Files
bal-electrum-plugin/bal
svatantrya 7c9bbfce58 core+gui+cli: anticipation/rebuild dates, preserve relative settings
Fixes around the delivery/build/check date handling (karen7 regtest):

- build_will (GUI + CLI) re-anchors date_to_check to the CURRENT heirs'
  earliest future delivery before building, so an anticipated rebuild is no
  longer blocked by the stale old-will anchor (NO_FUTURE_DATE). The checks of
  the existing will keep their anchored date_to_check.
- _sync_locktime_to_built_txs now PRESERVES RELATIVE locktime/threshold
  recipes ("2y"/"150d") in WILL_SETTINGS instead of freezing them to absolute
  timestamps: the anchored comparisons (resolve_locktime_against_tx and
  resolve_date_to_check with built_locktime) already prevent the daily
  invalidate prompt. Absolute values still sync on a genuine automatic
  anticipation.
- Will.remove_stale_wallet_history drops stale wallet-LOCAL will placeholders
  before every (re)build in GUI and CLI so their coins are available again.
- check_willexecutors_and_heirs raises HeirNotFoundException outside the
  count_heirs gate: a shortened relative recipe on a signed will now triggers
  a plain rebuild ("no heirs" only when there really are none).
- is_locktime_below_threshold compares the settings on one reference frame
  (resolve_guard_threshold), no longer against the built-will anchor.

Tests: purge unit + call-site, no-heirs, guard, anticipated-rebuild
end-to-end (GUI) + CLI mirror + fixed_percent_lists_amount unit,
relative-preserve sync; conftest restores electrum.constants.net after each
test (cross-file pollution guard).
2026-09-10 17:07:22 -04:00
..
2026-06-30 06:23:44 -04:00

BalPlugin

Bitcoin After Life Electrum Plugin

Free and decentralized Bitcoin inheritance support for Electrum: build time-locked "will" transactions that transfer your funds to your heirs if you stop refreshing them (dead-man's switch), optionally relayed by will-executor servers.

Key behaviours

  • Anticipate / postpone safety: changing the delivery time of an already-signed will is handled safely. Postponing a signed/sent will first asks you to invalidate the old transaction on-chain (so a will-executor can never broadcast the earlier-locktime transaction and execute the inheritance too early), then lets you rebuild and re-send the new one via the Prepare button on the WILL tab.
  • "Server" column: the will transaction list shows whether each transaction is actually stored on the will-executor servers (Confirmed on server, Sent (not checked), Send failed, Not on server, Signed (not sent), Not sent), with a tooltip showing the will-executor URL.

See the top-level README.md for installation and testing.