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.

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!

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.

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: - - and check out the read me of

GitHub

GitHub - jesseposner/FROST-BIP340: BIP340 compatible implementation of Flexible Round-Optimized Schnorr Threshold Signatures (FROST). This work is made possible with the support of Brink.

BIP340 compatible implementation of Flexible Round-Optimized Schnorr Threshold Signatures (FROST). This work is made possible with the support of B...

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.

Here is a flow diagram

If you have a single client key that would defeat the value in remote signing of revocation, no?

Also if you need to be online to assist the bunker, why not just self host? Not clear what is additive to this

How do I set up a bunker?