NIP-A0: Keychains

[mikedilger]

I think this is the simplest yet effective way to move towards master keys and device keys.

I have yet to compare this to other key management proposals.

[staab]

I like the M tag. I don't know enough about HD keys, but is it possible derived keys could be automatically associated with parent keys without a keychain event?

[mikedilger]

#1647 should preceed this keychains NIP since the keychains NIP breaks encryption.

[mikedilger]

I like the M tag. I don't know enough about HD keys, but is it possible derived keys could be automatically associated with parent keys without a keychain event?

I know bitcoin does that with addresses using 0'/0'/... paths. But I think to prove that a subkey belongs to a master key you have to leak some secret (?) ... in any case while it is cool that it is possible, it isn't needed and I'm not sure it adds value.

[vitorpamplona]

Doesn't this open the possibility of a DoS attack on the followers of the largest users by simply creating millions of events with M tags? Or is the relay checking and rejecting M tags?

[mikedilger]

Doesn't this open the possibility of a DoS attack on the followers of the largest users by simply creating millions of events with M tags? Or is the relay checking and rejecting M tags?

No the relay isn't checking and rejecting M tags. How are normal DoS prevented right now, and why can't those methods be used in this case? For example, if some pubkey is creating spam M tags you ban the pubkey, or if random pubkeys are doing it you require AUTH and some reputation or whatever it is relays do (I don't try to run an open relay).

[vitorpamplona]

Well, right now I cannot create a DoS attack on the followers of a key because we download by pubkey.

I can create other types of DoS attacks, like on the Notification feed by p-tagging users. But those require creating 1M for each user I am targeting.

With the M, I just need to create 1M fake events as Jack and Nostr stops working for everybody.

[mikedilger]

Ok I get your point.

[1l0]

LFG

[mikedilger]

Updated with ideas from @vitorpamplona on other NIPs, without permission ;-) includinng NIP-44 v3 and using derived encryption keys

[mikedilger]

I like the M tag. I don't know enough about HD keys, but is it possible derived keys could be automatically associated with parent keys without a keychain event?

Let me answer this better. Yes you could do this, and events could include a derivation path along with the master key, and anybody could verify that the master pubkey through that derivation path yields the event pubkey without looking anything else up.

But you'd need an Xpub and Xsec, you can't just do it with 32 bit keypairs.

Also it means we cannot use our current nostr keys as subkeys, since we didn't derive them. And I think that is an important migration step.

[ioseph-silva]

To avoid DoS attacks, a client could search for the kind 19000 of the master key, then grab the device keys and make a request for the events of each of them, never making a request with "#M": ["<master-key>"]. However, this would render the master key useless for normal posts. (it is still possible to request "authors": ["<master-key>"])

[mikedilger]

To avoid DoS attacks, a client could search for the kind 19000 of the master key, then grab the device keys and make a request for the events of each of them, never making a request with "#M": ["<master-key>"]. However, this would render the master key useless for normal posts. (it is still possible to request "authors": ["<master-key>"])

Yes. The point of 'M' was to avoid the long lists of keys you are searching for events for. Right now you might follow 100 people and have to put 100 keys in the filter. If each of those people has 3 devices, now you have to search for 300 authors. That's not terrible I guess, but with 'M' you still only have to search for 100.