Files
bal-electrum-plugin/bal
bitcoinafterlife 05002dc0a5 core+gui: name the real cause of a failed build instead of guessing
The Building Will report showed a fixed list of three "possible reasons"
whenever a build produced nothing, regardless of what actually happened; in a
case reproduced from the owner log all three were false and the real cause was
not even listed. The "Checking your will" row had the same flaw, showing one
sentence ("Found CHANGES to the DATE or the HEIRS") for five situations,
including one where it is plainly wrong (funds received).

core/heirs.py: record WHY buildTransactions gave up in a new last_build_error
attribute (8 reason codes), set at each path that previously returned empty
with no explanation, plus a processed_willexecutors counter to tell "every
will-executor was skipped" apart from "we tried and failed". Also fix a latent
crash in the prepare_transactions handler, which read a no-longer-existing
e.heirname attribute and re-raised the resulting AttributeError, masking the
real error.

gui/qt/dialogs.py: add msg_alert() (amber warning sign, body text in the theme
colour, readable in both themes), _build_failure_message() and
_check_failure_message() to turn those causes into one precise sentence each,
with an honest "cause could not be determined" fallback. Catch
BalanceTooLowException, which already carried the figures but fell through to
the generic red technical error.

No new exception classes were introduced (owner request): the plain
NotCompleteWillException cases are told apart structurally, not by text.
2026-09-04 11:52:21 +02: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.