# MPSEE

## Problem

Today's [collaborative custodians have a few glaring issues](https://www.thebitcoinway.com/articles/the-hidden-risks-of-bitcoin) - they can monitor everything you do, and may even hold you hostage under certain situations by censoring your transactions.

## Solution

Using [FROST](https://eprint.iacr.org/2020/852.pdf), a collaborative custodian can hold a key to a multisig while remaining unaware of the public key (and wallet) which they help control, and can [sign messages **blindly**](https://en.wikipedia.org/wiki/Blind_signature).

Our project implements:
- A working POC version of FROST,
- A tweak to the protocol to allow for blind signing by one of the parties designated as the 'collaborative custodian'

## Questions

After studying and implementing the scheme, our group discussed how/why certain modifications were made:

1. If blinding the collaborator's signature rely on the coordinator, wouldn't it be better to let every signer sign blindly?

Yes and no. A case where you still might want to not blind sign would be if you held 2 out of 3 keys and the 3rd key belonged to the collaborator custodian. You want the custodian to blind sign, but you want to be able to see what you sign on the 2 secret keys you have control of.

2. If coordinator is the one computing the challenge, why do we need the collaborator to send us the nonce?

The nonce still needs to be calculated using the collaborator's private key.

## Insights

The important unlock here seems to be the option to be able to swap out compromised collaborative custodians via re-sharing of secret keys either by enrolment or sharing fragments. This was not implemented in our project, but should be implemented for actual use cases. The options are covered in the [appendix](#Appendix).

## Appendix

### 1. Enrolment

There are two ways to do enrolment: via MPC or sharing fragments. ([source](https://github.com/nickfarrow/secp256kfun/commit/67c8d4f99d3506a29238c7240f15e8897cf40516))

#### 1.1 MPC

**Enrolling** involves using their secret keyshare point to evaluate the joint polynomial at some new index. Each party contributes evaluation shares from their basis polynomial, and weighs them using the appropriate [lagrange factor](https://en.wikipedia.org/wiki/Lagrange_polynomial) to ensure the sum of these pieces will lie on the joint polynomial. By securely sharing these with the new party, the new party sums them to form a secret keyshare and can now participate in FROST signing.

#### 1.2 Sharing fragments

We shamir secret share the secret shares. ([source](https://gist.github.com/nickfarrow/64c2e65191cde6a1a47bbd4572bf8cf8/#sharing-fragments-shamir-secret-sharing-extra-shares))

1. Each party evaluates their scalar polynomial at K extra indexes, creating K extra secret shares.
2. Each party then takes these K scalars and uses shamir-secret-sharing to fragment them up into `N` pieces with recovery threshold `T`. This gives a K by N array of fragments.
3. As each party P_i goes to send share `j` to party `j`, they additionally send the `j`th column of their fragment array for storage.