bal-docs/internal/design-choices-DRAFT.md

DRAFT — Design choices and comparison with other approaches

STATUS: NOT PUBLISHED. NOT VALIDATED BY THE DEVELOPERS.

This page contains technical positioning material that must be reviewed before it becomes an official project statement. It is kept here, out of the published site, so it is ready when that review happens.

Source: internal drafts (July 2026), corrected version of 24/07/2026. Tone rule: factual, no disparagement — these are design trade-offs, not mistakes.

Three different approaches

	Liana (Wizardsardine)	Timelock Recovery (Electrum plugin)	BAL
Mechanism	Script-based wallet (Miniscript): the timelock lives in the script locking the UTXOs	Pre-signed transactions: an Alert + Recovery pair	Pre-signed transactions with absolute nLockTime
Timelock type	Relative (CSV / BIP 68), per UTXO	Relative (nSequence / BIP 68) on the second transaction	Absolute (nLockTime)
What the BIP 68 cap limits	Maximum inactivity before the recovery key becomes usable	Only the cancellation window (2–388 days), not the inheritance horizon	— (does not use relative timelocks)
Distribution	None: on-chain	User/heir keeps the plan; monitoring services exist	Decentralized Will-Executor network

Liana: where the ~15 month limit comes from

Liana uses relative timelocks (CSV/BIP 68) inside the script: the countdown starts when each individual UTXO is received. The field is 2 bytes, so it cannot exceed 65,535 — a Bitcoin consensus limit, not a wallet limitation. In blocks: 65,535 blocks ≈ 455 theoretical days (~15 months). In the time variant (512-second units) the cap is equivalent to ~388 days.

Documented consequence, acknowledged by its own developers: the user must periodically "rotate" coins (send them to a new address of their own) to reset the timer — paying fees each time — otherwise the recovery path opens. The project itself notes this fits poorly with cold wallets that are never touched, and that a non-technical heir may struggle, since not all UTXOs unlock at the same block height.

The DCA example (valid for Liana, NOT for Timelock Recovery): someone buying monthly for a year accumulates twelve UTXOs with twelve distinct countdowns. If they die after the last purchase, the heirs do not find a single inheritance but unlocks staggered over more than a year, with several recovery transactions to execute at different moments — unless the user had manually consolidated the UTXOs (which is the same periodic rotation already required).

Timelock Recovery: NOT like Liana — closer to BAL

Timelock Recovery is not a script wallet and does not cap the inheritance horizon at ~1 year. It uses a pair of pre-signed transactions:

1. Alert Transaction — consolidates funds to a new address of the user's own wallet (plus small anchor outputs for CPFP). The heir broadcasts it when needed, and its appearance on-chain acts as an alert to the user.
2. Recovery Transaction — spends the Alert's output to the heirs' wallets, with a relative nSequence imposing a waiting period.

The 388 figure belongs here: it is the maximum cancellation window (whole days, 2 to 388), not the duration of the inheritance. Beyond 388 days you overflow BIP 68's bits. The logic is the opposite of Liana's: that window gives a still-living user time to cancel everything (by spending the funds) if the plan is triggered by mistake or under duress.

Positioning note: the author of Timelock Recovery has filed BIP 128 (draft, assigned 5 February 2026) to standardise the JSON format of such plans, with a reference implementation in the plugin officially included in Electrum's repository. This is a competitor on a standardisation trajectory — to be treated with respect and precision.

BIP 128's critique of BAL's approach — have the answer ready

The Motivation section of BIP 128 explicitly criticises the scheme BAL uses: the single pre-signed transaction with a future nLockTime. The argument: in the "all is well" scenario (user alive, seed not lost), as the date approaches the user must access the wallet and spend a UTXO to revoke the transaction, otherwise it becomes valid and moves the funds with no cancellation period. There is no window for second thoughts: on the date, the transaction is valid and the Will-Executors broadcast it.

This is the most serious technical objection BAL will face from a competent audience. It should be met head-on, not avoided. Elements of a reply (to be validated by the devs):

• The 2–3 year renewal policy with a rolling deadline is precisely the safeguard: someone who renews never gets close to the date.
• The user always retains control: spending a single UTXO invalidates the inheritance. Revocation is always in their hands and requires nobody's permission.
• The plugin allows setting a reminder in the system calendar.
• Declared trade-off: BAL chooses simplicity for the heir (one date, one transaction, nothing to execute) at the price of requiring renewal discipline from the owner. Timelock Recovery chooses the opposite: no looming deadline for the owner, but the heir must execute two transactions in sequence and wait out the cancellation period.
• Possible future improvement (issue for [DEV]): an alert / cancellation-window mechanism in BAL as well.

BAL's real advantage, stated precisely

Not "the others are limited to one year" — that is imprecise and easy to attack. The correct positioning rests on three points:

1. Nothing required of the heirs. With Timelock Recovery someone must broadcast the Alert, wait days or months, then broadcast the Recovery — knowing what they are doing and having kept the plan. With BAL the Will-Executor network broadcasts on its own: the heir may not even know in advance.
2. No consensus-forced rotation (vs Liana), and no problem of UTXOs unlocking at different times: a single date for the whole wallet.
3. Distributed redundancy. The plan does not depend on a file someone must keep and find: one Will-Executor out of N still operating is enough. (The USB file remains as an extra backup.)

Technical points not to get wrong in public

• The 65,535 limit is a Bitcoin consensus limit (BIP 68) and applies only to relative timelocks. Absolute nLockTime has no such cap: in practice it can set dates decades away (with 32-bit Unix timestamps the practical limit is the year 2106).
• Do not say "Timelock Recovery only allows one year of inheritance" — it is false, and anyone familiar with the project would dismantle it instantly. The 388 is the maximum cancellation window.
• Do not say "Liana is limited to 388 days" without qualification: in the block variant it is 65,535 blocks (~455 theoretical days, ~15 months); 388 days is the time variant.
• Remember that transactions with a future nLockTime are not accepted by the mempool until the date is reached — this is why someone (the Will-Executors) must broadcast them at the right moment.
• Balance note: any very long timelock carries a theoretical risk tied to the future evolution of the Bitcoin network — a further argument for periodic renewal.

Editorial rules carried over from the source drafts

• Never use, in any public version: "investment", "return", "yield", "pension", "passive income", or any projection of future sat or fee prices.
• Always keep the risk disclaimer when publishing Will-Executor recruitment material.
• Correct formula for Electrum: "listed in Electrum's third-party plugin directory" — never "approved by Electrum".

Open actions

1. Have the devs validate the technical FAQ answers (what a Will-Executor can actually see, CPFP) and above all the reply to the BIP 128 critique — the most exposed point of BAL's design.
2. Evaluate as a [DEV] issue a possible alert / cancellation mechanism in BAL.
3. Turn the Will-Executor recruitment article into a blog post (the remaining [to complete] fields need dev input: current fee range, minimum system requirements).