Subnostr

what if we just start with kind:1521 with opentimestampped events; this seems like such a trivial get and doesn't open the door of crypto/HD bikeshedding.

Regardless, if we do HD keys we'd still need to do kind:1521 stuff as described in https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md

what do you think nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ?

optout 2y ago

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).

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

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.

fiatjaf 2y ago

What if someone steals your key and proposes a new next-in-line pubkey as their own?