Yeah, agreed in all those points. The alternative I proposed in the other note doesn't require the subsequent pubkeys being children of the same master pubkey, just that the next-in-line pubkey is disclosed upfront, which would make it work for existing, non-HD, pubkeys.
Pregenrated/Masterkey/HD schemes are not good for several reasons:
- Cannot be used for keys already in use
- Can be used for newly created profiles, but only if created with a supporting client
- If two-level key protection is not done by the user/clients (ie. master key is in client), there is a chance for the master key being compromised, for which case the scheme is ineffective
- Basically works only if the user considers the key compromise risk explicitly upfront, which is not the case for most users.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's proposed NIP41 scheme is a clever scheme to ease proving the relationship between subsequent keys, but still has the above issues (pr #158, since abandoned).
Discussion
I think the details of key relation doesn't really matter, be it HD-derived from a master key, be it derived in a chain from each other, or just a set of predefined keys, they all have in common:
- you have to create some state upfront, with secret and public part
- you have to safeguard the secret part separately from your 'day-to'day' nsec
These two points make pregenerated/HD schemes weaker.
What if someone steals your key and proposes a new next-in-line pubkey as their own?