Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add signer-key to *-increase pox events #4417

Closed
zone117x opened this issue Feb 23, 2024 · 6 comments · Fixed by #4461
Closed

Add signer-key to *-increase pox events #4417

zone117x opened this issue Feb 23, 2024 · 6 comments · Fixed by #4461

Comments

@zone117x
Copy link
Member

The signer-key has effectively become the “primary key” for all signer data. So if I’m trying to lookup information about stackers based on signer-key, it gets pretty difficult when important events like stack-increase and associated events don’t include it.

Based on discussion with @kantai, it doesn't sound possible to add a map that could be used to lookup the signer-key during synthetic event generation for these functions. Another approach would be to just add the signer key and signature args to the functions. It sounds like this might be a good idea to do anyway -- from Aaron:

functions like stack-increase do not take a signing key argument because they are updating an existing entry.
maybe they should, because I could certainly see an argument that those functions actually also need signer-key authorization.
like, imagine a signer authorizes a stacker to use their signing key to stack 100 STX, and then later on that stacker invokes stacks-increase to increase from 100 STX to 10000 STX.

@github-project-automation github-project-automation bot moved this to Status: 🆕 New in Stacks Core Eng Feb 23, 2024
@zone117x zone117x changed the title Add signer-key to *-increase` pox events Add signer-key to *-increase pox events Feb 23, 2024
@setzeus setzeus self-assigned this Feb 23, 2024
@hstove
Copy link
Contributor

hstove commented Feb 23, 2024

After looking at stack-increase, during part of the function it iterates over reward-cycle-pox-address-list, which includes signer-key in each entry. So it's possible to do the same thing when making synthetic events, but it would need to return a list of signer keys (one for each updated cycle).

@hstove
Copy link
Contributor

hstove commented Feb 23, 2024

Linking discussion: #4424

@hstove hstove moved this from Status: 🆕 New to Status: 💻 In Progress in Stacks Core Eng Feb 28, 2024
@hstove hstove added the PoX-4 label Feb 29, 2024
@setzeus
Copy link
Collaborator

setzeus commented Mar 1, 2024

Discussing w/ ClarityWG it seems like the best / most practical solution here is to limit 'stack-increase' to users that are not straddling two signer-keys between upcoming cycles (aka they did not 'stack-extend' recently).

That way every check is straight-forward with every iteration just checking that the existing signer-key is equal to the signer-key in the param.

@hstove
Copy link
Contributor

hstove commented Mar 1, 2024

Yep, I think that's the right approach and aligns with @kantai 's comments on expected behavior

@setzeus
Copy link
Collaborator

setzeus commented Mar 4, 2024

Did work over the weekend on this that can be found here: feat/signer-key-amount-auth...feat/signer-key-amount-auth-stack-increase

Reviewed with @hstove who'll 'git cherry-pick' commits into his main PR found here: #4461

I'll close issue once the PR linked above is merged-in.

@hstove hstove linked a pull request Mar 4, 2024 that will close this issue
@hstove hstove moved this from Status: 💻 In Progress to Status: In Review in Stacks Core Eng Mar 5, 2024
@saralab saralab moved this from Status: In Review to Status: ✅ Done in Stacks Core Eng Mar 6, 2024
@saralab saralab closed this as completed Mar 6, 2024
@blockstack-devops
Copy link
Contributor

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.

@stacks-network stacks-network locked as resolved and limited conversation to collaborators Oct 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants