SIP-032: Improved stacking

[friedger]

This PR adds a SIP specifying

• how to remove the cooldown cycle.
• how to streamline solo stacking and delegated stacking
• how to improve the relationship between signers and stackers

[314159265359879]

Thanks for adding this Friedger! I look forward to the proposed changes going live.

Added some minor comments about typos.

In the SIP I would also like to read how a transition from PoX-4 to PoX-5 would influence the sBTC protocol and how potential risks or other complexities are mitigated and/or dealt with.

[friedger]

There are still a few open design questions. Main discussion so far should happen on https://forum.stacks.org/t/remove-cool-down-cycle-in-stacking/17899/13

[314159265359879]

I just added a couple nits, mostly typos and two suggestion to improve clarity/readability.

[nieldeckx]

Really liking this upgrade!

One ask from StackingDAO: please give plenty of time before the PoX-5 change goes live. We’ll need to update our code and get an audit, which takes a while. A clear schedule for testnet and mainnet would be nice.

[jcnelson]

Instead of removing them, could they instead wrap calls to the delegation functions? For example, stack-stx could be re-implemented to delegate STX to the caller, and have the caller stack and aggregate-commit them.

[jcnelson]

Depending on the order in which this SIP and the Clarity 4 SIP (#218) get ratified, it may be useful for #218 to add an asset guard special form for PoX locking (cc @obycode).

[obycode]

Ah, yes. I had that thought at some point, but then forgot to include it. Thanks! I'll add it.

[jcnelson]

I'm generally fine with renaming things. Would it also be possible to preserve the existing function names and signatures, and have them call the new functions? The reasoning here is that it would keep existing tool and scripts working.

[wileyj]

+1 for backwards compatibility here

[jcnelson]

Is this the function signature?

(define-public (designate
   ;; The amount of uSTX to be locked immediately
   (amount uint)
   ;; Signature of the signer indicating that the signer accepted the delegation of voting power
   (signature (buff 65))
   ;; The Bitcoin block height at which this designation ends, if any.
   ;; N.B. the text says `block-height`, but this is a reserved word.
   ;; I'm using `end-block-height` in its place.
   (end-block-height (optional uint))
   ;; PoX address that the signer must use, to which PoX yield accrues
   (pox-addr (optional { version: (buff 1), hashbytes: (buff 32) }))
   ;; Maximum amount of uSTX that can be locked through future auto-extending
   (max-amount (optional uint))
   
   ;; code goes here
)

[jcnelson]

A few other questions:

• Can you describe the SIP-018 payload that must be signed by the signer?
• How does this method identify the signer public key to use, in order to authenticate signature? Can it be an argument to the function, like it is for stack-aggregation-commit and stack-aggregation-increase?
• How does this method ensure that signatures cannot be reused? The current PoX code uses an auth-id, which must be included in the signature and which cannot be re-used across signatures from the same signer key.

[friedger]

Signatures should be created in the same way as Pox-4 using public key and auth-id, etc. I'll extend the section about signatures.

[hstove]

I think it would be best to include the actual function signature in the SIP. Additionally, we will need signer-key as an argument

[jcnelson]

PoX 4 uses the function's name as the event's name (i.e. in the event tuple's name field). Is this mapping from a PoX 5 event to the old PoX 4 event correct?

• designate --> delegate-stx
• designate-increase --> stacks-aggregation-increase
• designate-decrease --> (this is new, and has no PoX 4 analogue)
• designate-extend --> similar to delegate-stx-extend, but is now automatic?
• signer-accept --> stacks-aggregation-commit

Can you also explain what the event payloads will be?

[jcnelson]

Ah, I see that stacks-aggregate-commit is due to be replaced with signer-register. Is signer-accept a new function in PoX 5? I don't see it defined in this document.

[friedger]

signer-accept is defined in ## Amount of Stacked STX as event name. The function is signer-register.

[friedger]

I understand, I'll change signer-accept to a function name.

[friedger]

The events in Pox 5 are similar (-->) in Pox 4

• designate --> delegate-stx + delegate-stx-stack
• designate-increase --> delegate-stx-increase but by user
• designate-decrease --> (this is new, and has no PoX 4 analogue)
• designate-extend --> similar to delegate-stx-extend, but is now automatic? Correct, however, there is no call from the user
• signer-accept --> stacks-aggregation-commit

Payloads should be similar to pox-4, I'll spend some time to specify them as well.

[jcnelson]

In all likelihood, solo stackers also have separate keys for signing, for cold storage STX, and for Bitcoin rewards.

[jcnelson]

Also, the PoX reward address can be a deposit address for sBTC of a Stacks smart contract.

This is very interesting. Is the taproot address guaranteed to be stable for long enough that it can be used as a PoX address? My understanding of the sBTC minting process is as follows:

• The user creates a taproot address from two scripts -- a deposit script, and a reclaim script
  • The deposit script contains the WSTS aggregate public key's X coordinate, the maximum BTC fee, and the Stacks principal to which to mint the sBTC (it's <[8-byte-max-fee][up-to-159-byte-SIP-005-principal]> OP_DROP <signers-x-public-key> OP_CHECKSIG).
  • The reclaim script, which allows the sender to reclaim the BTC after a timeout (it's <locktime> OP_CSV <user-supplied-reclaim-script>).
• The user creates a Bitcoin transaction which sends BTC to the taproot address
• The user informs the Emily API service of the transaction
• The Emily API service forwards the transaction to the sBTC signers
• The sBTC signers, if possible, will spend the taproot UTXO via the deposit script. If the signers can't do this in time, then the user can spend it with the reclaim script.

The risk to users in supplying an sBTC deposit taproot address is that their maximum fee value and locktime value will need to remain set for at least one stacking cycle. The user would need to change their PoX address each time they want to change the maximum fee or advance the locktime. Can this SIP advise users on how to construct their sBTC deposit addresses for them to be suitable for their desired number of reward cycles?

[friedger]

In all likelihood, solo stackers also have separate keys for signing, for cold storage STX, and for Bitcoin rewards.

I inserted "theoretically".

Also, the PoX reward address can be a deposit address for sBTC of a Stacks smart contract.

My intention was to highlight that this is possible with the new setup. However, explaining details how to implement this, should be part of a different resource, e.g. https://github.com/friedger/clarity-trustless-pool/

[friedger]

@jcnelson I am hesitant to keep the old functions and signatures. It might be confusing to mix the different semantics.

[hstove]

I think it would be best to include the actual function signature in the SIP. Additionally, we will need signer-key as an argument

[hstove]

I totally understand the usage of max-amount here, but this differs from the current usage of max-amount. Currently, max-amount is used for the signer to say "you can't stack any more than this, because I don't want to have too much signing power". In this proposal, max-amount is for the stacker to say "you can only lock at most this much".

These are two different things, so we'll need to reconcile this fact. Either we add a new argument for the stacker's intention, or we remove the current usage of max-amount.

Additionally, from a UX perspective, we need to think about how max-amount is used in signature generation. When referring to the stacker's intention of "you can only lock at most X", we should probably just omit it from signature generation. Otherwise, signers will need to get this information ahead of time for generating signatures.

[hstove]

After further consideration, I think we need to keep both the old param and the new param, meaning we need to figure out what to call these params. My recommendation is:

• max-amount: the same as before. This represents "the max amount a signer will allow a stacker to stack towards their signer key". For most signers, this will remain u128::max
• allowance: the maximum amount that a stacker is allowing the signer to stack.

This would essentially mean replacing "max-amount" with "allowance" in this paragraph.

[hstove]

After further reading, I actually don't understand what max-amount means here. If I call designate with an amount of 1000, and a max-amount of 2000, what happens? It doesn't seem like signer-accept takes an amount or anything, so where does max-amount ever come into play?

[friedger]

I have updated this section to clarify what it means when max-amount is omitted. In this case, amount is used as max-amount.

I also renamed max-amount to amount-allowance to avoid confusion about max-amount used during signature generation.

max-amount/amount-allowance is used during auto-extend where the stacking amount can be increased automatically as well.