Oddbean new post about | logout
 To be fair, it's not unreasonable to have this primal desire for subkeys and key rotation. The problem is that:

1) it's not possible to do without centralization (or a blockchain) -- Bluesky tried, and the best solution they came up with was a big server that hosts a history of keys for everybody and can censor anyone;
2) doing it by means of Nostr events that declare subkeys or delegation or whatnot, creates insurmountable complexity that turns Nostr into an unusable pile of bloatware and away its most basic feature: the chance of working;
3) it's not the only way to protect your key from rogue computers and apps -- NIP-46 and other methods exist and are much nicer to use, with still many unexplored possibilities;
4) it's not clear that more than 16 people in the entire world want this at all -- when was the last time a normal person thought about rotating their PGP keys? 
  ✅ EtherFi Airdrop Is Live!. 

 👉 https://telegra.ph/EtherFi-06-23 Claim your free $ETHFI. 
 no one cares dude 
 And this is why @fiatjaf is the CEO of nostr
nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqsqqqye9j54rrlck6xk9c584ya67cfwnjw38xzcqa7ar4ce6xqh5ns2mjkv7 
 #subkeys are great! 
 i don't know about CEO but i am the MVP

"most valuable poaster" 
 I guess FROST, such like NIP-95, is likely to be 3). if one of NSECs composing of a NPUB can be replaced. 
 Still don't get how that works or what's even possible with that. 
Can you, for example, have a quorum of keys that control one nsec and switch them out for an entirely different set of keys?  
 It's like creating a public key with multiple private keys, like multisig creates an single address by multiple pubkey, or Shamir creates a single seckey from multiple shares.

I am still studying this, but since it depends on schnorr signature, I think it will be difficult with the current nostr key (though proto NIP-95 exists already). it will have to start from a new key, won't it? 
 can't you do something like musig with schnorr quite easily? 
 About what?  What I mention is whether we can seamlessly verify the signatures attached to the nevent signed with the current private key vs. the new set of keys based on FROST, even if it is the same pubkey. I'm not sure. 
 100% I would much rather have a safe way to remotely sign then have key rotations. 
 > doing it by means of Nostr events that declare subkeys or delegation or whatnot, creates insurmountable complexity that turns Nostr into an unusable pile of bloatware and away its most basic feature: the chance of working;

Really? Yet another event kind is the universal answer to every problem in nostr, or so I've heard. 
 We do have a blockchain we can use and a way to do it in a self-sovereign manner.

I think key rotation completes the spectrum from ephemeral to permanent identities. The edges will always have less traffic, but they matter. 


https://github.com/pubkeychain/pkc-protocol 
 Compromise of keys is a legitimate threat, especially with the difficulty and complexity of avoiding compromised hardware/software. Currently, if your nostr key gets compromised, what are your options? 
 > 2) doing it by means of Nostr events that declare subkeys or delegation or whatnot, creates insurmountable complexity that turns Nostr into an unusable pile of bloatware

This is already happening with different NIPs trying to do everything on nostr. Example: Name System 
 1) do primary key rotation manually.
2) youre not a good barometer for normal 
 4) The better question is how much more often would people rotate their PGP keys if the email ecosystem was designed with robust support for decentralization and user security instead of being designed to help corporations collect data 
 I have a good idea on how to accomplish key rotation but it's difficult to implement to the entire protocol. 
 The point about PGP key rotation is a very good argument. 

But maybe PGP should have key rotation?

nostr:nevent1qqsqqqye9j54rrlck6xk9c584ya67cfwnjw38xzcqa7ar4ce6xqh5nsppemhxue69uhkummn9ekx7mp0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqp262yz9 
 The only people you have to declare your newly rotated key to is: Your followers ∩ The ones you want to keep.

User applications would have the option of caching keys used for historic notes. The local cache might get a bit chunky if users rotate a key for each note, but keys could be locally jettasoned using a stack-height setting for each chain of keys [user].

One of the reasons I don't like Nostr is that there is no reliable way to expunge notes from relays. Without the ability to do this, there doesn't seem to be a way to meet conditions for acceptable levels of privacy.


 
 One method that occurred to me as an alternative (or even a bolt-on) to ordered HD key rotation would be for each new user to generate a (say 128Kb) pad of key pairs instead of a single key pair. Each key pair would be random-entropic.

A user's first note is signed/encrypted using the first key on the pad, but with the note including metadata denoting the next key (from the pad) to be used... or a clue to the next key. The key could be switched every note, every 21 notes etc.

Only those who have been sent the full pad of public keys are then able to stitch-together the full note history. It doesn't feel too computationally expensive to me.

Obviously lots of flaws with this, but perhaps a basis for something...?!? 
 I view it alike to Bitcoin.

With Bitcoin I hold my keys, it makes me immune to being debanked, but I wear the custody risk. 

With Nostr I hold my keys, it makes me immune to being deplatformed, but I wear the custody risk.

Arguments like "What if my keys get compromised? There is no way to fix that. Therefore this protocol sucks" are as banal with Nostr as they are with Bitcoin.

Yes we should try to improve. Also "I've just discovered Bitcoin and I'm here to fix it" was a meme for a reason. 

nostr:nevent1qqsqqqye9j54rrlck6xk9c584ya67cfwnjw38xzcqa7ar4ce6xqh5nspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqsc6aq2u 
 nostr:nevent1qqsqqqye9j54rrlck6xk9c584ya67cfwnjw38xzcqa7ar4ce6xqh5nsppemhxue69uhkummn9ekx7mp0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqp262yz9 
 nostr:nevent1qqsqqqqkn55fuy0w8pj5sfjy76vhaek9r5dah8lp84wl4d3qazu8plgppemhxue69uhkummn9ekx7mp0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqp95e6ya 
 This is not a subkey proposal. 
 He is talking about the problems of it 
 What @ABH3PO meant is that he is not proposing that Nostr users have subkeys for themselves, just encryption keys that they use to encrypt messages in a group. The goals are very different and in this case it doesn't pose any problems to the protocol. 
 🤣🤣🤣 
 nostr:nevent1qqsqqqqkn55fuy0w8pj5sfjy76vhaek9r5dah8lp84wl4d3qazu8plgppemhxue69uhkummn9ekx7mp0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqp95e6ya 
 This is not a subkey proposal. 
 He is talking about the problems of it 
 What @ABH3PO meant is that he is not proposing that Nostr users have subkeys for themselves, just encryption keys that they use to encrypt messages in a group. The goals are very different and in this case it doesn't pose any problems to the protocol. 
 🤣🤣🤣