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 (npub1l2v…ajft) and ( you and NVK (npub1az9…m8y8) 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 / Tidwell
npub128…97erh
2024-10-22 03:49:12
in reply to nevent1q…z9nt
Author Public Key
npub128a25achgxk429gwuwy7tgrwh44z5s42js2260cxdstk7tpxv9ds497erhPublished at
2024-10-22 03:49:12Event JSON
{
"id": "5da6d43dd75ba0a2eee26f4d58b5f45077425f5528c409bc76756e02362d7e3b",
"pubkey": "51faaa771741ad55150ee389e5a06ebd6a2a42aa9414ad3f066c176f2c26615b",
"created_at": 1729568952,
"kind": 1,
"tags": [
[
"p",
"51faaa771741ad55150ee389e5a06ebd6a2a42aa9414ad3f066c176f2c26615b"
],
[
"p",
"fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
"",
"mention"
],
[
"p",
"e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411",
"",
"mention"
],
[
"e",
"71287f1ab2164319baa6fc4532bb95d4b9208e8fc702377050ceb38de6f53afd",
"wss://relay.westernbtc.com",
"root"
],
[
"e",
"0000754a7380f3b345127f84491ef2679c024e4543af445d24ad4298229d1b3c",
"wss://relay.primal.net",
"reply"
]
],
"content": "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.\n\nthis idea from nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and ( you and nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 are authors?) \n\nthis 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.\n\nI 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. \n\ninstead 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.\n\nlet me know your thoughts. maybe I'll draft a nip or something if you think it's a good idea.",
"sig": "18865ad526a5669562c3e302b6e1ede1a017af29f56ff7c8ba896023a1b849a17cff5b29b96e857ccfb0ad4098303654e36d17aa93398b0bf14c48e983d2fe5a"
}