decision: a defective xprv wallet is told to use other software, but we hold the only key and will not export it #255

New Issue

clawbot · 2026-08-12T10:42:54+02:00

clawbot commented

2026-08-12 10:42:54 +02:00

#247 has landed. It tells the user of a non-master-xprv wallet, accurately, that their addresses "are still reachable by software that repeats the same non-standard derivation" — and in the same change it blocks Export Private Key for that wallet.

So the app names the recovery route and then withholds the only thing needed to take it. The user's key is sitting encrypted in our storage; no other copy exists unless they kept the original xprv.

Raised by the independent review of that PR. Blocking export is defensible and consistent with disabling signing — a defective wallet should not be handing out key material through a path whose error handling was written for a different case. But the combination is a dead end for the user, and this is a wallet, so a dead end means funds nobody can reach.

Options

(a) Offer the extended private key on this screen specifically, behind the password and behind copy that says what it is for. The user can then repeat the derivation elsewhere, which is exactly what the copy already tells them to do. Costs: an export path that exists only for a broken state, and a screen showing key material for a wallet we have declared defective.
(b) Offer the derived per-address private keys rather than the xprv. Narrower blast radius — one address at a time, no tree — and it is what the user actually needs to sweep funds. Costs more work: the derivation for these wallets is the non-standard one, so the export path has to reproduce the old broken derivation deliberately.
(c) Leave it blocked and change the copy to stop implying a recovery route we do not enable — say plainly that the addresses are reachable only if they still hold the original extended private key from elsewhere.
(d) Leave both as they are. The copy is technically true; a user who imported an xprv plausibly still has it.

Recommendation

(b), with (c) as the honest cheap option. Per-address keys are what someone recovering funds actually uses, and exporting them does not require trusting our broken tree — we derive, show, and the user sweeps. (a) hands over more than is needed. (d) leaves the app pointing at a door it locked.

Note this is only reachable by users who imported a non-master xprv before #210 landed, which may be nobody. If you believe that population is empty, (c) is clearly right and cheap.

Not blocking anything; #247 is merged and the current state is safe, just possibly a dead end.

https://git.eeqj.de/sneak/AutistMask/pulls/247 has landed. It tells the user of a non-master-`xprv` wallet, accurately, that their addresses "are still reachable by software that repeats the same non-standard derivation" — and in the same change it blocks Export Private Key for that wallet. So the app names the recovery route and then withholds the only thing needed to take it. The user's key is sitting encrypted in our storage; no other copy exists unless they kept the original xprv. Raised by the independent review of that PR. Blocking export is defensible and consistent with disabling signing — a defective wallet should not be handing out key material through a path whose error handling was written for a different case. But the combination is a dead end for the user, and this is a wallet, so a dead end means funds nobody can reach. ## Options - **(a) Offer the extended private key on this screen specifically**, behind the password and behind copy that says what it is for. The user can then repeat the derivation elsewhere, which is exactly what the copy already tells them to do. Costs: an export path that exists only for a broken state, and a screen showing key material for a wallet we have declared defective. - **(b) Offer the derived per-address private keys** rather than the xprv. Narrower blast radius — one address at a time, no tree — and it is what the user actually needs to sweep funds. Costs more work: the derivation for these wallets is the non-standard one, so the export path has to reproduce the old broken derivation deliberately. - **(c) Leave it blocked and change the copy** to stop implying a recovery route we do not enable — say plainly that the addresses are reachable only if they still hold the original extended private key from elsewhere. - **(d) Leave both as they are.** The copy is technically true; a user who imported an xprv plausibly still has it. ## Recommendation **(b)**, with **(c)** as the honest cheap option. Per-address keys are what someone recovering funds actually uses, and exporting them does not require trusting our broken tree — we derive, show, and the user sweeps. (a) hands over more than is needed. (d) leaves the app pointing at a door it locked. Note this is only reachable by users who imported a non-master xprv before https://git.eeqj.de/sneak/AutistMask/issues/210 landed, which may be nobody. If you believe that population is empty, **(c)** is clearly right and cheap. Not blocking anything; https://git.eeqj.de/sneak/AutistMask/pulls/247 is merged and the current state is safe, just possibly a dead end.

sneak was assigned by clawbot

2026-08-12 10:42:58 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#255