Nakamoto Stacking Burn Ops and Signer Key Allowances

[hstove]

Links:

• stack-stx burn op requires signature
• [Nakamoto] Vote for aggregate public key on Bitcoin
• [Nakamoto] Bug in stack-stx burn op

Issues with requiring a signer-key signature

The big issue with adding the signature to the burn op is that it makes the BTC transaction pretty complicated because we can't simply fit the signature in the OP_RETURN. Some options are discussed in #4285.

We can, however, fit the signer key in the op return (33 bytes). So if we want to omit the signer signature, we need some sort of "allowance" to verify that a signer key can be used in certain stacking situations.

Signer Key Allowance

The signer key signature message hash includes these components:

• pox-addr
• reward-cycle
• topic: 12 bytes
• period

By adding a new function to pox-4 to allow using a signer key ahead of time, we can omit the requirement of needing a signer key signature in burn ops.

Clarity add-signer-key-allowance function

We can add the ability for signers to add an allowance by adding a new add-signer-key-allowance function, which would take the same arguments listed above (pox-addr, reward-cycle, topic, period) along with a signer-key parameter.

The general idea for this function is to:

• Verify the that the pubkey hash of tx-sender is equal to the hash of signer-key
• Insert a map entry where the key is { pox-addr, reward-cycle, topic, signer-key } with the value true.

Burn op for add-signer-key-allowance function

To make this work in a burn op, we can use a p2pkh input with the signer key's pubkey hash.

The specific OP_RETURN format for the signer key allowance op would be:

0     2  3                  7                      29           30
|-----|--|------------------|-----------------------|-----------|
 magic op reward cycle (u64) topic (string-ascii 12) period (u8)

Modifications to other pox-4 functions

Because adding an allowance removes the requirement for including signer-sig as a function argument, we'll need to change the signer-sig parameter in stack-stx, stack-extend, and stack-aggregation-commit from (buff 65) to (optional (buff 65)).

In the (verify-signer-key-sig) function, we would need to change the function to have two validation branches:

• if signer-sig is none, check the allowances map
• otherwise, verify the signature as we do today

If we wanted to preserve the existing function signatures, we could instead check to see if the length of signer-sig is zero and treat that as none if it is.

[jcnelson]

Hey, sorry this is coming a bit late; been busy with the network state machine work.

I think this approach looks good to me. I'd prefer (optional (buff 65)) over checking that the buffer is length zero, since the former more accurately conveys the "absence" of a signature.

I appreciate that you're open to keeping the signature option available, since it reduces the number of transactions that a stacker must send in order to begin stacking. It's particularly useful for users who are both stacking and signing, since they can skip setting up an "allowance." The need for an allowance table mainly helps pooled stackers who stack with a pool that isn't also a signer, since then only the pool operator needs the allowance for the pool's PoX address (and it can be submitted directly by the signer ahead of the pool's stacking transactions).

The only feedback I have would be to use the word "authorization" instead of "allowance," because we don't want to suggest that the signer has any spending authority. Open to pushback.

[hstove]

Happy to use authorization, that makes sense. I have a draft PR at #4377 that uses (optional (buff 65))