manime on Nostr: On second thought … maybe Vítor actually knows better … ...

On second thought … maybe Vítor actually knows better …

quoting nevent1q…yskg

Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes :

FROST vs BIP32 …

1: “sub key” derivation via FROST (called “shares”) can be initialized (once or multiple times) from a users EXISTING npub, providing forward compatibility for existing pubkeys to act as “main identities”. BIP32 (afaikt) must generate a fresh xpub as the “main identity”, excluding existing npubs from reaping the benefits?

2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality?

3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not?

OTHERWISE …

- both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey.
- both require additional implementation by signers and native clients.
- both require a “connected” signer or native client to request the “main identity” pubkey from some remote service.

Forgive my ignorance as I wrap my head around this very real need. Have I missed anything?
bitcoinplebdev (npub1s9e…lxzl)
https://www.frostr.org/