Signer should control which stackers can delegate to the signer

[friedger]

Is your feature request related to a problem? Please describe.
For legal or other reasons, signers might not want to accept signing duties for some stackers who want to delegate signing to them.

Describe the solution you'd like

Describe alternatives you've considered

Additional context
@MarvinJanssen mentioned the issue first I think

[jcnelson]

Stacking transactions would require a signature over the stacking function's arguments from the signing private key. The stacking function would authenticate the signature in order to validate the signing public key.

[kantai]

There's two possible ways to handle this:

1. Require a signature from the public key. The public key would sign something like a serialization of the tx-sender and the current reward cycle.

2. Require a public key allowance -- i.e., track which public key can be used by a tx-sender in a Clarity Map.

The advantage of (1) is that it simplifies the PoX contract. The advantage of (2) is that it doesn't require the signer to actually use their signing key before the stacking cycle starts.

[jcnelson]

Another advantage of (1) is that you can change your key in the same transaction as you stack, so you don't have to worry about mempool congestion preventing you from rotating your signing key.

[hstove]

@saralab to assign me (hoping I can get added to the repo/org so I can add myself)

[diwakergupta]

@saralab to assign me (hoping I can get added to the repo/org so I can add myself)

igotchu

[friedger]

Currently, Fast pool accepts any stacker as pool member. It is a self-service pool.
With the requirement to provide a signature the pool's self-service feature will break.

[hstove]

@friedger yes, but you should be able to build tooling to automatically generate signatures for anyone who wants to join.

[MarvinJanssen]

Per discussion during one of the engineering calls: does it make sense to an allow/deny mode for pools that are fine accepting anyone? Then if it is set to allow, no signatures are required. To me it really feels like an undue and risky burden to require pool operators to run a service exposed to the internet that produces these signatures.

I also want to challenge the framing of this problem. It is pretty easy for a blocked stacker to create a new address to stack from. How can a signer properly vet this in the end? I feel like forcing these signatures will bring little benefit but a lot of extra infrastructure cost.

Tagging the PR to create a reference to this issue: #4277

[hstove]

@MarvinJanssen, now that the signer key is only provided at stack-aggregation-commit, is this still really an issue? Stackers don't need the key or signature during their transactions, nor do pools need the key/sig for delegate-stack-stx etc. And because the signature is only needed on stack-agg-commit, it can be generated only occasionally and from a secure setup.

[MarvinJanssen]

That's true. It would only remain for solo stacking which is a specific use-case. Nonetheless, the problem would remain there.

[friedger]

How does this work for solo stackers stacking for 12 cycles? Which key do they need to use as the signing key changes every cycle?

[hstove]

@friedger I don't think you need to rotate your signer key every cycle anymore - it only changes with -extend.

[friedger]

If half of the stackers are solo stackers for 12 cycles and the other for 6. Then the first 6 cycles the aggregate public key is the same.
Thereafter, some stackers extend and the new key is created using the data from 6 cycles ago for the other stackers?

[blockstack-devops]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.