FROST Tooling

Technical Support
1

@conradoplg I have a two questions about integrating FROST crates to build out a FROST-native wallet. I’m not sure if these are protocol limitations or cryptographic limitations in the way that FROST was created (trying to read up and learn), but figured I might ask the question to you.

  1. If I have a wallet linked to an address that is managed through a FROST scheme and I need to have a multi-note send (ie the wallet wants to send 4 ZEC to an address, but I have 3 notes in the wallet, each note has only 1.5 ZEC associated with it so I’d need to include all three notes for the transaction to work) it looks like I would need to do a round of signing for each note, is that correct?

  2. If I have a group defined as a 3 of 5 signature scheme, as the coordinator I would need to define the individual 3 signers to construct the signing session. Even if I defined all 5 eligible signers, then it would essentially become a 5 of 5 scheme. There is no way to have a setup where all are eligible signers, but the first m of n to sign meets the threshold to complete the signature. Is that a correct assumption?

TIA and am trying to read the FROST paper right now to see if I can figure it out myself.

3 Likes
2

pinging @nsheep if you can help answer the questions above. Thanks!

1 Like
3

I forwarded this. Please be aware that the engs focus is currently on the ironwood upgrade and they will reply as soon as they are able.

1 Like
4
  1. You need to sign them all. It could be done in parallel.
  2. The coordinator doesn’t need to get input from all 5 signers. I don’t see why it would be 5/5
1 Like
5

I think for the multi-note one, you’d need to build it out either as a change in the way that the out of the box setup is done. I think it’s doable but will need to stew on it a bit

For the m of n threshold if it’s a 3 of 5 as the coordinator you specify in the cli coordinator command who the 3 signers are so it’s not a first come first serve basis and the shared signatures generate the combined key. At least from what I’ve seen in testing and playing with it.

6

It may be the case for their tool but it doesn’t have to be that way.

7
  1. Yes, you need to sign each action. For efficiency you can do the signing in parallel as Hanh mentioned.
  2. That’s correct, you need to determine the set of signers beforehand, and the signing will only finish when all the selected signers do their part. In practice this is not much of a problem. You can write your own logic that waits for e.g. 3 signers to show up and then do the signing with only them.
2 Likes
8

Hey @conradoplg a quick question, I think the answer is no impact based on what I have seen, but FROST is fully compatible with Ironwood pools? I know it was designed not backwards compatible for pools prior to Orchard, but going through some upgrade/optimizations on the wallet that I’ve been building that is FROST-based. Thanks.

9

It is compatible, yes. Ironwood is basically a separate instantiation of Orchard, so its signatures have the exact same format as Orchard.

2 Likes