[Nakamoto] Bug in `stack-stx` burn op
The StackStx burn op no longer works, it was not updated to handle the new signer-key arg.
Error log:
INFO [1706104120.562869] [stackslib/src/chainstate/stacks/db/blocks.rs:4274] [chains-coordinator-0.0.0.0:20443] StackStx burn op processing error., error: Interpreter(Unchecked(IncorrectArgumentCount(5, 4))), txid: 97d6e0b983cdc6b46cc2f6537f7081621dbf0a48204656eac2648138dbc00de6, burn_block: 27aca254478e8cbd2f0c777820f8e8e3b1b5163cfa68a037bf03f50d9bff6830
Relavent code: https://github.com/stacks-network/stacks-core/blob/2684ce5adb6692592a5b19963987441905acf759/stackslib/src/chainstate/stacks/db/blocks.rs#L4220-L4230
There don't appear to be any tests covering these paths.
Just want to confirm that this does show up for delegate-stx? Because, the arguments to delegate-stx should not have changed between master and next.
Regarding stack-stx, this is tricky because stack-stx requires both a signing key and a signature as arguments (per https://github.com/stacks-network/stacks-core/pull/4277). This no longer fits into an OP_RETURN. We can fit the public key in, but not the signature. I've opened an issue for addressing this here: https://github.com/stacks-network/stacks-core/issues/4285
Just want to confirm that this does show up for delegate-stx?
Ah yes you're right, I mixed that up with delegate-stack-stx. The bug is only with stack-stx.
This is essentially a duplicate of #4285
Feel free to close this one
Closing, duplicate of https://github.com/stacks-network/stacks-core/issues/4285