Since each secret share of a FROST key is a point (index, secret share) that belongs to a polynomial with some interpolation threshold. A threshold number of parties can each evaluate their share of this joint polynomial at a new participant index.
Parties securely communicate these evaluations to the new party using a repairable threshold scheme, and the new party sums them to receive their secret share. This secret share belongs to the same polynomial and key as the other parties, can sign etc.
Removing a signer involves parties recreating their secret shares and a new polynomial, only this new polynomial retains the same joint-secret (x=0) and thus the same public key.
The removed signer never loses their secret share, only they will now be incompatible with every honest signer who has moved to a new polynomial.
@utxoclub answered the "how" in his comment (the google-able term is "rpoactive secret sharing)
For "how can it be secure" question, you need a quorum of signers to add/remove a signer. So if you have a 3/5 and you want to add a new signer, you need to have 3 of the existing signers. Those three could move all the money anyway.
It's a cool feature - but doesn't this also create a new attack vector?
For example, some parties might be tricked into generating a new quorum/new shares, whereas other parties are still using the old quorum/old shares.
3-of-5 becomes 3-of-4, where 2 shares are stale/invalid:
Party A: share A1
Party B: share B1
Party C: share C2 (tricked)
Party D: share D2 (tricked)
Party E: removed
To mitigate this, I suppose you might want a secure communication channel and a protocol to ensure that either everybody moves to a new set of shares, or no one moves. That and keeping old shares on the devices, just in case. Keeping states is something that you might have to do anyway for the nonces.
Doesn't this have the same downside as Shamir's secret sharing in that you need to bring all the keys together to construct a "full" bitcoin key. THEN you can sign the transaction.
Using regular multi-sig the keys are actually separate.
n: The total number of parties or participants.
k: The interpolation threshold, i.e., the minimum number of parties required to evaluate the polynomial.
x: The index or participant number.
P(x): The polynomial function that each secret share belongs to.
S(x): The secret share of a party at index x.
P_j(x): The joint polynomial used by the parties after removing a signer.
K: The public key derived from the polynomial.
E(x): The evaluation of the joint polynomial P_j(x) at a new participant index x.
S'(x): The secret share of the new party at index x after adding them to the system.
Each secret share of a FROST key belongs to a polynomial with the interpolation threshold k:
S(x) = P(x) for all x = 1 to n
A threshold number of parties can each evaluate their share of this joint polynomial at a new participant index x:
E(x) = P_j(x) for at least 'k' parties
The new party's secret share S'(x) is obtained by summing up the evaluations communicated by the other parties:
S'(x) = Ξ£ E(x) for at least 'k' parties
The joint polynomial P_j(x) has the same joint-secret (x=0) as the original polynomial:
P_j(0) = P(0)
The public key K is derived from the joint polynomial:
K = P_j(0)
When a signer is removed, parties recreate their secret shares and a new polynomial, but the joint-secret remains the same:
P_j(x) = P(x) for all x = 1 to n, except the removed signer
The removed signer's secret share remains the same, but they become incompatible with honest signers on the new polynomial:
Does FROST require additional rounds of communication for signing similar to MuSig/MuSig2, or can a transaction just simply be passed along to signers until the threshold is reached?
FROST requires each signing party to share a nonce, and the signing parties sign under the same agreed upon set of nonces.
You can share a whole bunch of these nonces upfront, storing them on the coordinator wallet ready for use. This way, signing can still be done in a single round.
A difference with FROST however is that you need to select the subset of signers (signer_2, signer_3, signer_5) that will be signing, from the beginning of the signing session. If this was a big deal then you could use tricks like combinations of concurrent signing sessions.
partial signatureswhich are signed independently, and then combined to form a final signature.(signer_2, signer_3, signer_5)that will be signing, from the beginning of the signing session. If this was a big deal then you could use tricks like combinations of concurrent signing sessions.