[Feature]: Realign on usage of distributed key generation outputs

[djordon]

Feature - Realign on usage of distributed key generation outputs

1. Description

The signers use "keys" for multiple actions that need to take place. This includes

1. For identifying themselves over the p2p network.
2. For signing WSTS messages (this is in addition to the signing that gets done on the networking layer).
3. For signing Stacks transactions. Here we use a multi-sig ECDSA signature.
4. For signing Bitcoin transactions. Here we use a single Schnorr signature that is created using a threshold signature scheme.

The issue is that there are multiple keys, with some of them rotating, and it's not clear which keys should get used in which places. There is a private key that is supplied by the signer operator, and the private key that gets generated as part of distributed key generation (DKG). The question is where should each of these keys get used.

This ticket proposes a particular usage: use the operator supplied private key for (1-3), and in (4) force the private key in WSTS to be the same operator private key as in (1-3). The outcome of this is that each signer only has one public key under their control and it is used for signing all transactions and all identification. Currently, things are setup to use the operator's signing key for (1-2), with new keys generated during DKG used for (4) (and (3) is not implemented yet).

Edit: I think a better alternative is to use the operator supplied private key for (1-2) and use the same WSTS private keys for (3-4). This is pretty appealing, and doesn't require too much of a change to the signer binary (and no modifications to the WSTS library).

1.1 Context & Purpose

This would reduce the complexity of the system and make it clear what keys are used and where. We retain the benefits of our weighted threshold signature scheme at the cost of some potential complexity when using WSTS. Unfortunately, right now it doesn't seem possible to achieve the desired goal, but I have it on good authority that we can and will change that fact.

2. Technical Details:

Change our usage of WSTS to keep the personal private and public keys even after DKG. This requires an update to WSTS.

2.1 Acceptance Criteria:

• The aggregate key can be figured out using only the signing set public keys after DKG.

3. Related Issues and Pull Requests (optional):

This would also allow us to solve #511.

[djordon]

A PR is up in WSTS to enable us to specify the private key during DKG if we want: Trust-Machines/wsts#92

[xoloki]

A PR is up in WSTS to enable us to specify the private key during DKG if we want: Trust-Machines/wsts#92

To be clear, what the wsts PR allows is to keep the same aggregate group key when re-running DKG. This happens at a high level by specifying keep_constant: true in the DkgBegin packet, and at a low level by passing the same argument to traits::Signer::reset_polys. Doing so causes the Party::f polynomial to use the same constant parameter, which is that party's contribution to the aggregate group key.

This constant parameter is not what v1/v2 Party calls a private_key, which is rather the interpolation points on the group private polynomial, which are sometimes called secret shares. These are what is used to construct signature shares, not the polynomial constant parameters. And the secret shares will in fact change during DKG, even when the constant parameters (and aggregate group key) remain the same.

[djordon]

Yup, understood. I just didn't want to write all of that out, 🙏🏽 thank you for doing so.

[djordon]

I no longer think we need to change anything around DKG outputs, since what is in the signer code base is fine. A little confusing, but fine. It would be nice if the proposed change would lead to a stable aggregate public key for the sBTC signers, but that won't be the case when we allow for the signing set to grow and shrink.