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. 

 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.  

 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 🤷‍♂️