Signing Key Requirements <> PoX-4

[setzeus]

Might've missed it in the SIP but I couldn't find requirements on how often a new signing key is needed - I recall hearing that a new signing key mandatory per cycle? If yes, that leads to a few unanswered design questions that likely effect core stacking functions:

1. Are users still stacking for more than 1 cycle at a time?
2. If so, then how are these signing keys updated for each user-case:

A. Solo stacker, solo signing -> if they stack for multiple cycles, do they need a setter to update the signing key per cycle?
B. Solo stacker, delegated signing -> if they delegate their signing for multiple cycles, what happens when that signer rotates to another key?
C. Delegated stacker, operator signing -> since delegated, no signing key is provided by stacker so operator can set signing-key whenever; however, this again asks if the operator needs a setter to update the signing key per cycle?
D. Delegated stacker, delegated signing -> if they delegate their signing for multiple cycles, what happens when that signer rotates to another key?

Opening this discussion for a better understanding of PoX-4 requirements if indeed signers are required to participate with a new signing key every reward cycle.

The solution will would likely involve an explicit "update-signing-key" function not currently accounted for in the designs.

[jcnelson]

Might've missed it in the SIP but I couldn't find requirements on how often a new signing key is needed - I recall hearing that a new signing key mandatory per cycle?

A new signing key is required on each call to stack-stx, stack-aggregation-commit-indexed, and stack-extend. The SIP requires that the aggregate public key be unique each time it is instantiated. They do not need to change their signing key across reward cycles if they stack for multiple cycles.

[MarvinJanssen]

@jcnelson we require a new signer key to be submitted to each call to stack-stx etc.. However, you can have the same signer key for multiple cycles if they Stack for multiple cycles at once. From that it follows that it is possible to have the same aggregate public key for multiple cycles. Is that fine? In the case that the signer set is exactly the same due to a multi-cycle lockup, do signers skip DKG and simple vote for the same key? (Technically a vote would not even be necessary as the node would know.) Or do they go through DKG for good form and then calculate and vote for the same key as the last cycle?

[setzeus]

Follow up design question here @jcnelson . Now that I've done some preliminary work on registering & updating signing keys in #4092, I have a general thought on when a pool operator submits the signing-key for all empty delegates.

In the SIP draft & Clarity design doc it's mentioned that this should happen when the pool operator calls 'stack-aggregation-commit-indexed.' There's also another way to do this which I've done in the PR linked (using 'delegate-stack-stx'). They both have a few trade-offs & I'm curious to get your feedback/thoughts:

1. Using 'stack-aggregation-commit-indexed'
Wouldn't this require us to fold/map through a list of all delegated-stackers with an empty/none signing-key slot? In short, this requires us to create/maintain a list of all delegate-stackers stacking with no signing-keys to the same pox-reward address; when stack-aggregation-commit-indexed is successfully called, we'd need to loop through this list.

If we go this route, we'd need to define this list per cycle per pox-reward which would mean an upper-limit on stackers per delegate. We'd also need to include a new map that we don't currently have (something like 'empty-key-delegates-per-pox-per-cycle').

2. Using 'delegate-stack-stx'
Reviewing both Friedger & Xverse pool, both contracts call 'delegate-stack-stx' on behalf of a tx-sender. Couldn't we leverage this function & include the signing-key parameter there? This way pool operators always pass in their signing-key when calling this on behalf of delegates - if the delegate already provided a signing key, nothing happens, if the delegate didn't provide a signing key, the signing key provided in the parameter.

This second route we don't need a loop within 'stack-aggregation-commit-indexed' & can work without existing data structures. But this might assume that a pool operator knows which signing key they'll be using earlier than the other route?

[setzeus]

Doesn't this assume that the user knows the delegator signing-key ahead of time? What advantages does this parameter offer if:

A. User has to now know the signing-key ahead of time
B. User providing anything but A. means the delegator can't lock the user's stx

Why the option if it only leads to the user possibly not being delegated if it's the incorrect key?

[friedger]

Similar to pox-addr, it gives the user the power to ensure that the signing key promised by the delegator (communicated earlier) is used and the the delegator does use the promised signing service or does sign with their own key.

Alternatively, we can remove pox-addr from delegate-stx.

[jcnelson]

I think the consequences to users if the delegator provides a different signing key than expected are (1) less dire to users, and (2) far less controllable by users, as compared to providing a different pox-addr. The fundamental reason for this is that the user potentially knows some or all of the private state for pox-addr, but not for signing-key.

The fact that pox-addr may correspond to some private state held by users (e.g. private keys, private key shares) means that the ability for users to set pox-addr when delegate-stacking empowers them to collectively disburse accumulated BTC without the delegator's help. But today, no similar guarantee exists for signing-key -- the software does not exist yet for users to collectively control a signing private key (but this could be added in a subsequent hard fork). Therefore, unlike pox-addr, users have no way whatsoever to detect or mitigate bad delegator behavior here. This calls into question the need for users to force a delegator to use a particular signing key. How does this improve things? How does the user even know that the signing key they want to use corresponds to an honest, online signer? How can the user possibly know that the signer will stay honest and online for the duration of the reward cycle? The user doesn't control any private key state, and the user can't foresee a signer's future behavior, so the usefulness of mandating a particular signing key here is much more limited.

[friedger]

Thank you for sharing your inside. Then we should remove the parameter for now.

[MarvinJanssen]

Good, that line of reasoning makes sense.

[friedger]

Question about delegating signing responsibilities : currently, there is no way for a signer to accept or reject when a stacker delegates signing to the signer.

Does it matter for signers? And for the blockchain? Is there a risk signing centralization?

Furthermore, there are no economic incentives for signers to sign for more stackers than their own stacked stx.

At the same time, stackers can easily delegate signing to any signer that published their signing key already.

Are there (for example regulatory) constraints for a signer to only sign for the amount of locked stx that they control tbemself?

[MarvinJanssen]

Stackers can also quasi-delegate by solo stacking to their own POX address but passing the signer key of a different signer to stack-stx.