Oddbean new post about | logout
▲ ▼
fiatjaf | 1 months ago (raw) | root | parent | reply | flag +1 
 This is an idea that basically already exists in NIP form, from @PABLOF7z. It hadn't seen much (or any) implementation efforts yet though.
▲ ▼
miketwenty1 | 1 months ago (raw) | root | parent | reply | flag +1 
 that pablo guy is likable, i’ll include him in my web of trust, which nip is it?
▲ ▼
fiatjaf | 1 months ago (raw) | root | parent | reply | flag +2 
 https://github.com/nostr-protocol/nips/pull/829 this one, I think.
▲ ▼
miketwenty1 | 1 months ago (raw) | root | parent | reply | flag +4 
 the idea I pitched is using a threshold of signatures from whitelist group (including potentially some of your own backup keys), and then the new key is flexible and defined when needed.

this idea from @PABLOF7z and ( you and @NVK are authors?) 

this idea of y'all's doesn't require a web of trust or multsig threshold idea, you just lock in ahead of time a new key pair using ots timestamps as a source of truth to migrate away from a compromised account and used in case of migration attackers with earliest timestamp winning.

I think instead of relying on timestamps, it would be interesting to use real connections + backups as part of the recovery protocol where you have said "these threshold of keys can vouch for me" and then there is no time delay for the migration itself. it seems nip47 has a migration delay in case an attacker gets access to your account, you'd still need to wait or the time where people think your account is really you. 

instead you can have better uX by punting the time delay of the change and using ots on the whitelist of the new threshold script. then if an attacker wants to change your script you can just migrate instantly to your new keypair of your choice and you don't need to lock in ahead of time.

let me know your thoughts. maybe I'll draft a nip or something if you think it's a good idea.
▲ ▼
miketwenty1 | 1 months ago (raw) | root | parent | reply | flag 
 also note, you could flexible choose your security model and do 1/1 threshold with your own back up.. but then you still get the better uX of timeliness in case you need to migrate.
▲ ▼
PABLOF7z | 1 months ago (raw) | root | parent | reply | flag 
 You’d still need to OTS it though since an attacker could do exactly the same with establishing the threshold.

I don’t think you can get around requiring ordering if the source of truth is the key in question.

That said, we have a pretty secure source of time ordering and OTSing is quite simple, cheap, and you only need to verify it under a very rare circumstance 🤷‍♂️
▲ ▼
miketwenty1 | 1 months ago (raw) | root | parent | reply | flag 
 I'm not sure if you understand what I'm saying, it's just moving the ots proof and creating an additional layer of abstraction so that uX would be better imo. right now I believe your proposal means if someone gets compromised they have a minimum of x amount of time before you could migrate. 

The suggestion I'm saying is to bake that in ahead of time and make migration fast if compromised.

also in the case your new key were to get compromised before migraine, this would help with that, since you aren't pegged to a specific new keypair