e477c5aa5b
When postponing the delivery time of an already signed/sent will, the user was asked to sign the on-chain invalidation transaction twice before the new (postponed) will could be built. Root cause: after the invalidation tx was broadcast, on_success_invalidate restarted task_phase1 to rebuild the will, but the old will items were still marked COMPLETE/PUSHED with their original tx.locktime (the on-chain invalidation did not update the in-memory status). The postpone check therefore fired WillPostponedException a second time, requesting another invalidation. Fix: - Add Will.mark_invalidated_by_tx(will, tx): marks INVALIDATED every valid will item that spends a prevout consumed by the just-broadcast invalidation tx. Setting INVALIDATED clears the VALID flag, removing those items from only_valid_list so the postpone/expire check no longer fires. - Call it from loop_broadcast_invalidating after a successful broadcast (txid obtained) and persist via save_willitems. On the phase-1 restart the old will is no longer VALID, so the will is rebuilt directly: a single invalidation signature followed by the new will. Tests: add test_will_mark_invalidated_by_tx and test_will_mark_invalidated_by_tx_no_match plus the WillPostponedException hierarchy assertion. 184 tests pass; smoke and external-zip OK; ruff clean. Bump version to 0.3.1.
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 Tools → Prepare.
- "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.