LLFourn · March 28, 2023 02:30 · Mar 21, 2023 · Mar 21, 2023 · Mar 13, 2023 · Mar 13, 2023
diff --git a/unifing-frost-and-musig.md b/unifing-frost-and-musig.md
@@ -31,7 +31,7 @@ You could have a fragment like `frusig(X1,X2,X3)` which would define a 3-of-n (n
 1. Check if `X*` is equal to `X1`, `X2`, or `X3`.
 2. If not check whether it's on the polynomial defined by the lagrange interpolation of `X1`, `X2`, and `X3` at the right spot i.e. with x coord `H(X1, X2, X3, aux_id)`
 
-Unforunetly it looks hard to do this without `aux_id`.
+Unforunetly it looks hard to do this without this `aux_id` to uniquely define your share. I guess it would be up to the application to define this or it could just be some counter which is incremented for each auxilliary signer you add to the key.
 
 ## Not proved secure
 

diff --git a/unifing-frost-and-musig.md b/unifing-frost-and-musig.md
@@ -23,14 +23,24 @@ But we know how to turn an `n-of-n` key into an `t-of-n` (where `t` is equal to
 
 I lost the best citation for this but here's one [1]. A simple way to think about it is that you field MPC to generate the share for the new participant.
 
+## Miniscript
+
+I was wondering whether this unification could make a FROST miniscript easier to describe.
+You could have a fragment like `frusig(X1,X2,X3)` which would define a 3-of-n (not `n` is not encoded in the fragment). Via enrollment you could issue more keys and there'd be no need to change the descriptor. If I have a some `aux_id` and key `X*` I can check whether I can sign for this fragment:
+
+1. Check if `X*` is equal to `X1`, `X2`, or `X3`.
+2. If not check whether it's on the polynomial defined by the lagrange interpolation of `X1`, `X2`, and `X3` at the right spot i.e. with x coord `H(X1, X2, X3, aux_id)`
+
+Unforunetly it looks hard to do this without `aux_id`.
+
 ## Not proved secure
 
 This does not imply the above scheme is secure. It just appears to be structurally valid (i.e.
 correct). You would need to prove:
 
 1. the `n-of-n` non-interactively generated FROST key is a secure FROST key (i.e. the non-interactive protocol cannot be
    distinguished from the interactive keygen protocol in terms of the adversarial view in the random oracle model).
-2. Enrolment schemes are secure in combination with FROST are secure.
+2. Enrolment schemes are secure in combination with FROST.
 
 There's quite a bit of work to do there and I think that proving (1) might be hard without some extra tricks or maybe choosing a different benchmark for security.
 

diff --git a/unifing-frost-and-musig.md b/unifing-frost-and-musig.md
@@ -13,8 +13,8 @@ The form of the final key is the sum of `z_i * X_i` for all `i = 1,2, .. n`.
 Interestingly we can take a `n` public keys and generate structurally valid a `n-of-n` FROST key in
 a similar way. Set `X` as the Lagrange interpolation for the first term of a polynomial with points
 `(z_1, X_1), (z_2, X_2), .. (z_n, X_n)`. This leaves us with a formula for `X` as the sum of `L_i(0) * X_i` for `i = 1,2, .. n` and `L_i` is the `i`the Lagrange basis polynomial for the above points.
-`L_i(0)` is a function of `z_i` (and the other `z` values) which should do a good a job as
-of delinearizing as `z_i * X_i`.
+`L_i(0)` is a function of `z_i` (and the other `z` values) so it should do a good
+of delinearizing as `z_i` by itself.
 
 ## Enrolment
 
@@ -28,7 +28,7 @@ I lost the best citation for this but here's one [1]. A simple way to think abou
 This does not imply the above scheme is secure. It just appears to be structurally valid (i.e.
 correct). You would need to prove:
 
-1. the `n-of-n` FROST key is a secure FROST key (i.e. the non-interactive protocol cannot be
+1. the `n-of-n` non-interactively generated FROST key is a secure FROST key (i.e. the non-interactive protocol cannot be
    distinguished from the interactive keygen protocol in terms of the adversarial view in the random oracle model).
 2. Enrolment schemes are secure in combination with FROST are secure.
 

diff --git a/unifing-frost-and-musig.md b/unifing-frost-and-musig.md
@@ -0,0 +1,37 @@
+# Unifing FROST and MuSig
+
+There *might* be a secure scheme that non-interactively generates a `n-of-n` FROST key and from there you can interactively turn it into a `t-of-n` by issuing new shares (i.e. enrolment).
+I don't really know if this is a useful contribution even if it works. There might be some utility in not having multiple schemes but rather a one size fits all approach.
+
+
+## Idea
+
+MuSig takes a "multiset" of `n` public keys and outputs a single aggregated key which takes `n-of-n` secret keys to sign.
+Set `z_i = H(X_1,.. X_i, .. X_n, X_i)` for `i = 1,2, .. n`.
+The form of the final key is the sum of `z_i * X_i` for all `i = 1,2, .. n`.
+
+Interestingly we can take a `n` public keys and generate structurally valid a `n-of-n` FROST key in
+a similar way. Set `X` as the Lagrange interpolation for the first term of a polynomial with points
+`(z_1, X_1), (z_2, X_2), .. (z_n, X_n)`. This leaves us with a formula for `X` as the sum of `L_i(0) * X_i` for `i = 1,2, .. n` and `L_i` is the `i`the Lagrange basis polynomial for the above points.
+`L_i(0)` is a function of `z_i` (and the other `z` values) which should do a good a job as
+of delinearizing as `z_i * X_i`.
+
+## Enrolment
+
+This of course creates an `n-of-n` FROST key which is not all that useful.
+But we know how to turn an `n-of-n` key into an `t-of-n` (where `t` is equal to the old `n`) i.e. turn a `2-of-2` into a `2-of-3` etc.
+
+I lost the best citation for this but here's one [1]. A simple way to think about it is that you field MPC to generate the share for the new participant.
+
+## Not proved secure
+
+This does not imply the above scheme is secure. It just appears to be structurally valid (i.e.
+correct). You would need to prove:
+
+1. the `n-of-n` FROST key is a secure FROST key (i.e. the non-interactive protocol cannot be
+   distinguished from the interactive keygen protocol in terms of the adversarial view in the random oracle model).
+2. Enrolment schemes are secure in combination with FROST are secure.
+
+There's quite a bit of work to do there and I think that proving (1) might be hard without some extra tricks or maybe choosing a different benchmark for security.
+
+[1] https://dl.acm.org/doi/pdf/10.1145/62212.62213