From dcefd6ffddf67b1394259955e94c32b9215cdb60 Mon Sep 17 00:00:00 2001 From: Alain Brenzikofer Date: Mon, 14 Sep 2026 10:35:47 +0000 Subject: [PATCH] docs: state the hidden profile case, do not argue it Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Rvc3HbiWBTqbAvRT45G5oX --- docs/rfcs/2026-09-10-wallet-keys.md | 40 +++++++---------------------- 1 file changed, 9 insertions(+), 31 deletions(-) diff --git a/docs/rfcs/2026-09-10-wallet-keys.md b/docs/rfcs/2026-09-10-wallet-keys.md index 65084a31be..a9b05b77a5 100644 --- a/docs/rfcs/2026-09-10-wallet-keys.md +++ b/docs/rfcs/2026-09-10-wallet-keys.md @@ -132,41 +132,19 @@ signed record edit, not a rebinding of keys. ## Hidden profiles -Nothing about profiles is encoded in the derivation, so the wallet holds nothing -that would disclose a hidden profile, unless one of the registered names gives -away the existence of the hidden profile claiming it. Two channels would, and -each needs its own answer. - -A reader holding the seed can run the recovery scan: derive the enumerable paths -and ask the registry which names each address owns. That returns every name the -device holds whether or not anything was recorded locally, so keeping no record -does not help. A name that must not surface this way has to sit at a path the -scan cannot enumerate, derived from a secret the device does not store. - -A reader holding a list of names comes from the other side: resolve each one and -check whether what it resolves to is a contact address on this device. The path -never enters that check. Only a name resolving to something not identifiable as -one of the device's profiles closes it. - -Such a subtree needs no local state. Given the secret the client scans it exactly -as a reader would scan the public one, so the names, their indexes and the path -are recoverable from the secret and stored nowhere, which matters because a -stored index counter would betray that the subtree is in use. The secret must not -be the profile's own passphrase: changing that means unhiding and re-hiding, -which would move the subtree and orphan the names. The cost is that such a name -is not recoverable from the phrase alone, with no checksum and no scan behind it. - -The commands would take the secret where they take an index today: +A hidden profile can own a name, and registering it must not give away that the +profile exists. Scanning a seed for the names it owns must not surface such a +name, so it is not derived at the enumerable path but from a secret the user +supplies and the device does not store. The same secret reaches the name again +to manage it. ``` -/_wallet secret= the next addresses in that subtree -/_wallet export name secret= one name key's secret in it +/_wallet secret= the next addresses in that subtree +/_wallet export name secret= one name key's secret in it ``` -Neither is implemented here, and a named parameter can be added without breaking -the existing form, so what has to be settled before the first such name is bought -is the derivation rather than the signature: how a secret maps to path -components, and whether the subtree hangs under purpose `44'` or its own. +Not implemented here. The parameter can be added at any time; the derivation has +to be settled before the first such name is bought. ## Scope