Oddbean

The vision for this is that you have a dedicated "Client Key" that you can paste into whichever clients you enjoy using. You also have 1 or many "Bunker Keys" that are stored on servers listening for events from your client key. Only when both the client and bunker keys contribute their signatures will the signature for the event be valid, and a valid signature will be indistinguishable from one produced by your root key in cold storage somewhere. What this allows for is even if a client or bunker attempts to rug you, you can just rotate to new key shares and "kick out" the dishonest party. And the best part is that you still have the same npub! Rotating keys doesn't mean you lose your identity. This is somewhat flexible as well, in the demo I show a 2-of-2 setup. But you can easily increase the participants and threshold needed to produce a valid signature, thus further decreasing the trust assumptions. I could imagine having multiple bunkers with distinct key shares so you'd need all of them to conspire against you in order to get rugged.

I'm unclear on why there is a need for an nsec bunker at all? Why would someone want to multisig with a custodian? How is this better than using a nostr key signing extension, for example? Not criticism just curious. nsec bunkers aren't something I'm familiar with.

Sure, extensions are great, but there are a lot of users that aren't going to go through the steps to install a browser extension to use a website. Also, an extension is good for my laptop but it doesn't help me out much on mobile. With this setup, you are able to have the convenience of a custodial solution, but, you aren't able to get rugged if they act dishonestly. Now you can effectively rotate your keys without comprimising your npub

Very neat. A few noob questions: - Why didn't you use musig2 or some other non-threshold method? Is it necessary to use FROST? - Since it's frost, can we do 2 of 3 or other confiscations as well? - How do you generate the keys? Is it possible to start off with an npub and then generate the signing keys or do you need to start a new npub? - Do you recommend any technical articles or papers to read? I did read the frost paper a while ago but I feel like re-reading it now. Any other recommendations? Thanks, this is very exciting!

I suspect using FROST is what allows rotating keys without changing your npub. You can do the same for on-chain multisig… rotate a cosigner out without needing to do an on-chain transaction to a new wallet.

Great questions, 1. FROST allows for the signature aggregation step to occur without a trusted 3rd party. With something like vanilla shamir secret sharing, you'd need a trusted aggregator to bring together the partial key shares to re-create the root key and sign the message. Here, all share holders can operate independently and never expose their share to anyone else. This also allows us to rotate key shares should some n<T number of share holders become dishonest. 2. Absolutely, I was thinking something like a 3-of-4 set up could be quite cool where you have 1 client key and 3 bunker keys. Whenever you need an event signed, the client creates it and requests signatures from the bunkers, and once at least 2 of them respond, the client can add the client key signature and publish the event. You can keep chaining bunkers indefinitely and continue to improve the trust assumptions, as well as the complexity of the signing coordination. 3. I'm not sure if you can seed this with and existing pubkey and then generate the shares from there. I reckon it should be possible, but going to need to look into that. 4. There are not too many great technical explanations on FROST yet, unfortunately. I would recommend listening to: - https://www.youtube.com/watch?v=8nuFt-1SWRI - https://www.youtube.com/watch?v=ReN0kMzDFro and check out the read me of https://github.com/jesseposner/FROST-BIP340

Still wrapping my head around this. I love that this makes scanning QR codes between devices a loooot less of an issue. Will try to explore that UX specifically. Ideally, you'd be able to avoid copy-pasting all together for new apps, and I think that with this (or even just subkeys) you can.

You totally could replicate the nsecbunker "google-like" auth flow on the clients where rather than whitelisting a delegate key, this additional bunker just sends over the encrypted client secret. The important thing is that you aren't trusting a single entity with >= the threshold shares necessary to craft a valid signature. As long as that remains true, you can still safety rotate keys and know that any single malicious entity could not rug you.