pox-4 signer key authorizations for amount of STX

[hstove]

In discussions relating to #4417, it came up that we should add an authorization check to the amount of STX being stacked in addition to the other existing checks (period, reward cycle, method, and PoX address). That issue is being tracked in #4422

I'm outlining a potential approach here before we work on the code for these two issues.

Action 1: validate amount based on the amount of STX being stacked in each transaction

Because there is no way to easily validate the "new total" stacked during a particular transaction, we'll validate that the amount being stacked is less than or equal to a max-amount property in the authorization.

This max-amount is compared against:

• amount-ustx in stack-stx
• increase-by in stack-increase
• stacked-amount in the partial-stacked tuple during stack-aggregation-commit
• u0 in stack-extend

"Infinite amount" authorizations can be done by using u128::max.

Action 2: add a nonce field to the authorization

Because this change makes it so that we are authorizing an amount of STX being stacked, we'll need to also add a nonce to authorizations. To allow for out-of-order transactions, this nonce doesn't need to be monotonically increasing, it just needs to be unique.

This is needed because, without a nonce, a stacker can simply stacking transactions multiple times with less than the maximum allow STX, thus violating the intent of this new "max amount" authorization field.

When an authorization is used (either via signatures or a previously added authorization), a map entry is inserted based on the (reward-cycle, period, topic, pox-addr, nonce, max-amount) tuple. If this entry already exists, the authorization fails.

Summary of code changes

• Add an max-amount and nonce field to the authorization tuple (both via signature message and via authorizations map)
• Add a used-authorizations map to track already used (reward-cycle, period, topic, nonce, pox-addr, max-amount) authorizations
• Modify verify-signer-key-sig:
  • Add amount , nonce, and max-amount arguments
  • Verify that amount <= max-amount
  • Use max-amount in the authorization message hash and in the signer-key-authorizations map
  • Verify that the authorization hasn't been used (and store it otherwise)
• Modify set-signer-key-authorization to include a nonce and max-amount field
• Modify stacking methods:
  • include nonce and max-amount arguments
  • pass these args, along with an amount, to verify-signer-key-sig
• Modify all tests that use these methods
• Write new tests for these new behaviors
• Modify rust code that relates to creating and signing authorization hashes
  • Add stack-inc as a valid topic
• When updating the stack-stx burn op, include nonce and max-amount in the data

stack-increase changes

In relation to #4417, the changes needed would be:

• Add signer-key and signer-sig args (to solve for 4417)
• Add nonce, max-amount args for 4422
• Validate authorization with verify-signer-key-sig
  • Calculate period as the number of cycles being updated
• Update the signer-key buffer in reward-cycle-pox-address-list with this new signer-key argument

Questions

• Even with a nonce, I think an authorization can be griefed by sniping an authorization before the "intended" one confirms. For example, if Alice has an authorization for 1mm STX, Bob can snipe it and stack 100k STX, thus "using" Alice's authorization.
  • I think this is ok, because it would require Bob stacking his STX to Alice's burn address, thus incurring significant cost in lost rewards.
  • If we want to avoid this, it would require adding a sender principal to authorizations, which would be validated against tx-sender.
• When adding signer-key to stack-increase, should this update each map entry with the newly provided signer-key argument?
• Given that a high-level goal of limiting the amount of STX is to prevent a signer from gaining more signing power than they want to, validating a "nominal" amount of STX is tangential to the total signing power that they'll have. However, validating that a signer is not above a certain threshold is likely not possible, because we don't have a way of mapping signer-key -> total-stacked-for-this-key. Given that tradeoff, is this the right decision?

[kantai]

This plan makes sense to me!

[jcnelson]

Overall looks good. A few questions:

This max-amount is compared against:
increase-by in stack-increase

I think you mean, max-amount is compared against the new total stacked in stack-increase?

Action 2: add a nonce field to the authorization

Can we call it something besides nonce? That's already an overloaded term, and I don't want people to get confused. What about just calling it an auth-id or something more specific?

Even with a nonce, I think an authorization can be griefed by sniping an authorization before the "intended" one confirms.

I think sniping is a real problem because it could be used to instigate a chain liveness failure for a relatively cheap cost. I think requiring that only tx-sender can claim the authorization is probably the best way forward, but we'd better ask @friedger and @yknl what they think.

What if the authorization imposed a minimum STX amount as well?

When adding signer-key to stack-increase, should this update each map entry with the newly provided signer-key argument?

No, I don't think we want stack-increase to change the signing key since that'd constitute feature creep. Instead, if we want to be able to change the signing key while the STX are stacked, I think we should consider adding a dedicated function for doing so.

[hstove]

No, I don't think we want stack-increase to change the signing key since that'd constitute feature creep. Instead, if we want to be able to change the signing key while the STX are stacked, I think we should consider adding a dedicated function for doing so.

Interesting, so in relation to #4417 (and disregarding #4422), we should add the signer-key as an arg but not do anything with it? We can't use it to validate that each cycle uses that key, because it can change with stack-extend.

This brings up a different challenge I hadn't considered. A Stacker can have signer key A for cycles N..N+X, and then a different signer key for cycle N+X..M. In fact, the stacker can have used 12 different signer keys across 12 cycles. So, if we only have one signer key & signature as an argument to stack-increase, we cannot authorize each cycle.

I think you mean, max-amount is compared against the new total stacked in stack-increase?

I follow the reasoning here, but I think I'd argue that "nominal increase" is better than "new total" for two reasons:

• The signer can already easily reason about what the current total stacked towards their key is. Authorizing the amount they're willing to increase by in a single action leads to the same result.
• Suppose Alice has 1mm stacked and Bob 100k stacked, both to the same signer key. If we validate "new total can be max 1.1mm" (on an individual stacker basis), then Bob can increase by 1mm and Alice can increase by 100k. If a signer cares about the total stacked to their key, validating "new total" is worse for this reason. And we can't validate "new total stacked to the signer key globally" because we don't track this anywhere, at least not without a big refactor. Authorizing tx-sender is how we would have to do this.

I think sniping is a real problem because it could be used to instigate a chain liveness failure for a relatively cheap cost.

Can you elaborate? I'm not following at first read. Is this because a signer might say "I don't like Bob, I'm not going to sign if his STX are delegated/stacked to my signer key?"

What about just calling it an auth-id or something more specific

No problem, I'm on board 👍

[setzeus]

Re: the 'stacks-increase' implementation

Something I worry about here, especially compounded w/ the context @hstove brought up of having multiple signer keys for upcoming, is the ERR UX.

IE - say Alice wants to 'stacks-increase' by 60k STX for the next 6 cycles. In this scenario, she's using a single signer-key for all 6 cycles. Due to the max amount the signer wants to sign (assuming we're using global/weight checks instead of nominal), is there a chance that some reward cycles have allocation left for the additional 60k while other reward cycles have already reached the signers max amount?

If so, Alice would see a failed transaction that at best returns a list of the reward cycles that weren't approved? This means Alice would have a sub-optimal experience calling 'stacks-increase' multiple times until she calls it with a low enough amount that would stay under the signer max-amount for all 6 cycles no?

[setzeus]

Rethinking & rereading comments here I don't think we have consensus on whether it's critical to track the max-amount by a nominal amount vs. relative to the global amount.

When discussed w/ @hstove & per the comments above it's clear that assigning/tracking a max amount per individual stacker is easier to implement; but I'm not entirely convinced that this way would attain the desired behavior?

As a signer, would I care about a nominal amount of STX assigned to me? Or do I care more about the signing weight assigned to me?

My understanding is that signers care more about the latter - especially if they'd like to stay under a weight threshold.

I do see how per individual stacker basis does at least create ballpark that the signer can keep track of but it won't guarantee that in any given reward cycle they stay below an intended threshold (say if a signer wants to stay below 50% of the signing weight for that cycle).

[friedger]

As a signer, I am probably not too worried about the stacking weight the stackers bring because I have an off-chain agreement with them via the signature. As a pool operator, I can manage the total amount of stacked STX via aggregate commit and ensuring that the amount is below the agreed amount with the signer.
Signers have probably agreements only with a small number of stackers, while pool operators have agreements with many stx holders.
For solo stackers, I don't know.. looks complicated.