Skip to content

01a0eeb2 - Specify social recovery of the seed - #339

Merged
TaprootFreak merged 2 commits into
developfrom
docs/01a0eeb2-social-recovery
Sep 30, 2026
Merged

TaprootFreak merged 2 commits into
developfrom
docs/01a0eeb2-social-recovery

Conversation

@TaprootFreakAI

Copy link
Copy Markdown
Collaborator

EN:
This specifies how friends can hold shares of the same 128-bit seed a passkey already derives, so a lost phone can be replaced without a paper copy.
Daily login stays a passkey. Friends act only together, after a 48-hour delay, and only toward a new device.
Nothing here is implemented: no routes, no schema, and no screens.

DE:
Das beschreibt, wie Freunde Anteile desselben 128-Bit-Seeds halten, den ein Passkey schon ableitet, damit ein verlorenes Telefon ohne Papierzettel ersetzbar ist.
Der tägliche Login bleibt ein Passkey. Freunde handeln nur gemeinsam, nach 48 Stunden Wartezeit und nur in Richtung eines neuen Geräts.
Umgesetzt ist nichts: keine Routen, kein Schema und keine Oberflächen.

Details

The specification is docs/social-recovery.md. CONCEPT.md adds it as recovery path 3 and a decisions-log row. README.md links the document. SPEC.md lists it under out of scope for v1 and reserves no path.

Friends replace the paper copy of the seed, not the phone and not the passkey. The split secret is the frozen 16-byte mnemonic-v1 entropy, packaged as one SLIP-39 group with an empty passphrase and iteration exponent 0. Reconstruction stops at those 16 bytes and then uses the existing BIP-39 and NIP-06 path. SLIP-39's own conversion into a BIP-32 seed is not used, because that would change the npub.

Each share is NIP-44 encrypted to a secp256k1 key the guardian proves by scanning a nonce from the owner's device. On recovery, guardians encrypt only to an ephemeral key the new device shows. The api stores ciphertext and must never be the source of the recipient key. A local copy on the guardian's device is the copy that still works if this service disappears.

The default offer is 2 of 3, with a threshold of at least 2. Binding a new passkey waits 48 hours even when a session is already signed in, and an existing passkey can cancel immediately. After recovery the seed is stored wrapped under the new passkey (seed-wrap-v1); the new passkey's own PRF is not a second seed. Replacing a phrase stays refused.

This applies only after the account holds its own Nostr key. The custodial nsec is not split. Open Question #9 is unchanged. Wallet of Satoshi funds are not recovered, because 21.gifts does not hold them.

Document the guardian backup of the user-held seed. No runtime change.
Check the reconstructed npub before a share leaves the device, and draw cancellation from a pending session as well as a ready one.
@TaprootFreakAI

Copy link
Copy Markdown
Collaborator Author

EN:
Ready after 2 review passes.
Specifies social recovery of the user-held seed and changes no runtime behavior.

DE:
Bereit nach 2 Review-Durchläufen.
Beschreibt die soziale Wiederherstellung des selbst gehaltenen Seeds und ändert kein Laufzeitverhalten.

Details

Pass 1 found two contradictions in docs/social-recovery.md. Enrollment uploaded the shares before the check that was supposed to stop with no upload. The state diagram cancelled only a ready session, while the text also cancels a pending one. Both were fixed in e09c846c4b7581cf834ecf64ab90a2bbc8881afa.

Pass 2 found no defects.

The operator waived the second review lane for this pull request only. That waiver is not a passed second review.

No issue comments, pull-request reviews, inline comments, or review threads were open. mergeable is MERGEABLE. The CI check on e09c846c4b7581cf834ecf64ab90a2bbc8881afa succeeded. No status check is required on develop.

@TaprootFreakAI
TaprootFreakAI marked this pull request as ready for review September 30, 2026 06:24
@TaprootFreak
TaprootFreak merged commit aee383e into develop Sep 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants