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/
ManiMe /
npub1ma…yn9tn
2025-03-15 17:48:31
in reply to nevent1q…q28f
Author Public Key
npub1manlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqvyn9tnPublished at
2025-03-15 17:48:31Event JSON
{
"id": "4eb8dbb4dc719177546a9a9f2f3f0f1739ae14e67fa92e533ac112cbc7c72463",
"pubkey": "df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200",
"created_at": 1742060911,
"kind": 1,
"tags": [
[
"e",
"1bed61c026408f2f9aa748f4c23c4a064e74e90c0fb1799d91cbb7406da4def0",
"",
"root"
],
[
"e",
"dfdd985a18964a7c8c396699c20807829e191b5586c36f86336ebe3203c66cd1",
"",
"reply"
],
[
"p",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200"
],
[
"p",
"8172b9205247ddfe99b783320782d0312fa305a199fb2be8a3e6563e20b4f0e2"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"d30ea98ea65e953f91ab93f6b30ea51eb33c506f87d49f600a139aef00aa9511"
],
[
"client",
"Nostur",
"31990:9be0be0fc079548233231614e4e1efc9f28b0db398011efeecf05fe570e5dd33:1685868693432"
]
],
"content": "Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes : \n\nFROST vs BIP32 … \n\n1: “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?\n\n2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality?\n\n3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not?\n\nOTHERWISE …\n\n- both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey. \n- both require additional implementation by signers and native clients.\n- both require a “connected” signer or native client to request the “main identity” pubkey from some remote service. \n\nForgive my ignorance as I wrap my head around this very real need. Have I missed anything?\nnostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl\nhttps://www.frostr.org/",
"sig": "571a26b498f755b7e463f6b2b3436fd634bc3b5ca2fd74c6a8460cf2184f0f50bae4f10f3ff3e49dd1cb250bb18364faf0f9f4811c0cd7478fd17de465219806"
}