FROSTR DEMO 2
Showcasing the updates to our two signing clients and turning my personal nsec into a Frostr multisig keyset
SKIN IN THE GAME nostr:npub1gg5uy8cpqx4u8wj9yvlpwm5ht757vudmrzn8y27lwunt5f2ytlusklulq3
https://plebdevs-bucket.nyc3.cdn.digitaloceanspaces.com/videos/random/frostr-demo-2.mp4
Question: Where is the FROSTR polynomial saved? Only on the signer that has the seed? That signer must be online all the time, right?
Meaning, can the FROSTR's main account nsec be airgapped?
Yes, you can run igloo offline and just use it as an airgapped key manager
If Igloo is offline, who is checking if a pubkey is in the most up-to-date polynomial?
to be clear, there is no protocol interaction between the nodes to rotate keys or update the polynomial. you simply use your nsec to generate a new set of shares, then swap out the shares manually
this keeps share rotation simple, and reduces the attack surface available to a compromised share
I do have an example of performing an interactive rotation in the main frost library, that is designed for a group of adversaries:
https://github.com/cmdruid/frost/blob/master/test/example/refresh.ts
That's fine. What I am trying to understand is the role of the online signing component that need to check which keys are signing and the role of the master key that can rotate key shares.
Does the online component have a list of authorized pubkeys or does it just check if the incoming signature comes from any key that is inside the polynomial?
Meaning, can I rotate single device keys while keeping all the others in place, without changing the key set of the online service? Or do I need to update the online signer with a new public key that is authorized?
Ideally those two things would be separate. I load a polynomial on the signing service and then the air-gapped share creation/rotation service can generate new keys for new devices without having to update any of the old ones and the main signer.
yes, that is possible. you could create multiple sets of shares for your nsec, and run them concurrently. generating a new set doesn't invalidate the old set (you have to dispose of shares properly).
the bifrost node will only cooperate with peers who have a pubkey in the same group as them
in the future, igloo will be able to run multiple shares/nodes, which means you can participate in multiple signing groups, even for the same nsec
I don't have a clear use-case for doing this, other than more graceful rotation between sets (phase out the old set after the new set is in place).
If I want to airgap my nsec, how would I set this up? Is Igloo the piece that stays offline? If so, How do I transfer a newly generated share set from the offline application to the main signer that knows the pubkeys of all shares?
What I am trying to do is this:
- no online device has my nsec.
- I use an offline computer to generate 3 shares in 2 of 3.
- 1 share goes into Amethyst.
- 1 share goes into Olas.
- 1 share goes into Amber.
All of them are in the phone.
Amethyst and Olas both need to communicate with Amber to sign.
No single app has the full nsec.
Questions:
- Do I need to pick a coordinator among the 3 signers?
- What do I need to transfer from the offline nsec holder application to each of the app? Just the nsec? or the nsec + the group of other keys authorized to sign on my behalf?
- Do I need to pick a coordinator among the 3 signers?
No, the node requesting the signature is the coordinator.
- What do I need to transfer from the offline nsec holder application to each of the app?
there are two encoded strings that you copy/paste: the group string and the share string. You do not need to transfer the nsec.
You can run igloo offline and air-gapped as a key manager, and another copy of igloo as a desktop signing node.
We have plans for a mobile app that will run as a remote signer using NIP-46. TBD.
also, the full polynomial only exists in memory for the short time you are creating the shares. it is up to you to save those shares elsewhere, either encrypted to disk, or copy/paste.
nostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl how should we go about tracking interoperability of FROST implementations over nostr - what are the criteria etc
Frostr does not require any nostr protocol changes, it can integrate with NIP-07 and NIP-46. What we need to do is finish our reference signing clients (so other signers can understand and implement it themselves) and then after that create a spec for Bifrost the underlying library that powers the implementation into a signing client (if someone wants to reimplement to create their own library)
But none of this changes or requires anything new of the nostr specs
