Guy Swann
· 1w
And on the note of key delegation:
Hyperbee seems the perfect fit and that’s what I’ve been exploring as the append only state for “signed in devices” if you will.
The problem with append only state is that remember:
From the other partie's perspective who only sees your signed event, delegated signing is key rotation.
For your idea to work you must (as you mention) introduce an append only tracker of your key states.
This is the exact point where you introduce a strict ordering burden on Nostr verification since now everyone must take a roundtrip:
"Do I know this key? This could be xyz's subkey/delegated key so let's look up the original to verify the real identity" and this must be done each event.
And if you leak the subkey it's even worse, now you have to introduce even more extra roundtrips and edge cases where a client must look up the history of revocations with each and every event verification process.
So a delegation process producing a different signature will not work practically in my opinion.
The delegated signing process must produce the same signature as the original key.
This is what FROST solves. Your nsec is sharded and you define in the key ceremony what kind of quorum you will use.
Let's say 2/3. Now you keep one on a server, one on your phone and one just in cold storage (for now).
If the server or the phone is compromised you get the 3rd shard and never trust the compromised one again. These tools exist already you can experiment with them.
The burden / complexity is now on you instead of the whole network to make sure that the compromised shard is being handled (you cannot revoke it) but realistically you can drop it, and use the other 2 or even add further keys to the quorum, making it practically 2 of 4 etc.
Note that adapter signatures could be used differently but Frost has additional benefits.
AtProto (Bluesky) solves this by introducing a trusted so called PLC server that tracks key rotations. You cannot practically run your own equivalent because that's hardcoded into each client solving the consistency / roundtrip problem I described above. It's that theoretical thing that doesn't work in practice, and they acknowledge that.
All in all UX can go a long way so a co-signer FROST setup can be quite convenient to use with the right tooling, and services.
And if all breaks we always fall back to meatspace, there will never be a perfect solution, that's alright I think. Bitcoin can be hardforked even with overwhelming consensus.
Note that key rotation is essentially just that:
You want the whole world to overwhelmingly accept that the state of your identity changed. That is an oracle problem and Bitcoin handles it the same way:
Leaves it open.
That's why altcoins exist.
You fork an identity that's your alt identity. I don't have to accept but I cannot exclude others to accept it and enforce it practically.
The difference is that rotation of your identity will not affects global trade so it will be alright.
❤️1