Changes for PoX-4

[hstove]

New parameters

The main relevant change with pox-4 is that Stackers are now associated with a "Signer". These signers have the responsibility of signing blocks and other transactions as they're produced on Stacks. Because PoX is the "entry point" for becoming a Signer, Stackers need to include new data for some functions.

Some stacking functions take two new parameters:

• Signer public key: the public key of the signer. The type is (buff 33)
• Signer key signature: A signature that proves that the signer is permitting this Stacker to be associated with the signer. The type is (optional (buff 65))
• Max amount: This is an integer that represent the max amount of uSTX that can be locked in that specific transaction. It's not the same as "max amount that can be locked in total for this user". So for example, with stack-increase, this parameter refers to "the max amount of uSTX that can be used as the increase-amount param.
• Auth ID: this is a random number, kind of like a nonce, to prevent re-using signatures.

At the launch of Nakamoto, we can assume that both of these fields will be generated "out of band". It may be valuable at a later date to provide a UX for signers to generate this signature from the web app.

Both of these fields are buffers. It probably makes sense to support user input via a hex string.

Function changes

✅ = change in function parameters ❌ = no change in function parameters

Delegated stacking (for delegators)

No changes

Solo Stacking

• stack-stx: ✅
• stack-increase: ✅
• stack-extend: ✅

Delegated stacking (for delegates)

• delegate-stack-stx: ❌
• delegate-stack-extend ❌
• delegate-stack-increase ❌
• stack-aggregation-commit: ✅

[markmhendrickson]

Thanks, @hstove.

Both of these fields are buffers. It probably makes sense to support user input via a hex string.

Are you thinking that users need to come with these two values on hand and paste them into the UI? Where do we expect the users to find these values, and will we need to provide guidance for how to procure them from a 3rd party?

Alternatively or additionally, might we want default values that users can apply without having to think about which signer they want to use? I assume that's not possible since the signer key signature is unique to each user.

[hstove]

@markmhendrickson good callout, but I should have been clear that the only users who need to enter these fields are the users running a signer (aka pools and solo stackers). Stackers using a pool will enter the same information they already do. Your assumption comes because this is a pretty recent change, and the previous assumption was that stackers in a pool would need to provide this info.

As for the people running a signer, we'll have docs for how to get their pubkey and a signature. Right now the way they'll generate a signature is via a CLI command (https://github.com/stacks-network/stacks-core/pull/4319). Their pubkey will be something they just store in a note somewhere (it's public anyways). Perhaps the only UI help here could be to automatically pull in their existing signer pubkey if it exists with the option to update it, but I don't think that's critical.

You could add code that validates the signature & pubkey before submitting the transaction. This would also help as an extra check to make sure they're not accidentally inputting their signer private key. I'm happy to provide guidance on that (and it'll probably end up in the @stacks/stacking library).

[hstove]

I've updated the issue description to reflect two new params (max-amount and auth-id), along with the fact that now stack-increase needs to be updated as well.

[hstove]

Other note: the changes to @stacks/stacking are available in https://github.com/hirosystems/stacks.js/pull/1614, which is published as a beta NPM version.