zach on Nostr: Great questions, 1. FROST allows for the signature aggregation step to occur without ...
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
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