With bitcoin-cli, I efficiently spent (broadcast, was accepted by the regtest node after which mined) a tx spending two 1-of-2 script-path multisig outputs.
The spent prevout descriptors had been:
tr(
After the spending transaction was mined right into a block, I seen the multisig script: bitcoin-cli -regtest decodescript
the place
was the penultimate ingredient of the enter witness stack. I obtained:
{
"asm": " OP_CHECKSIG OP_CHECKSIGADD 1 OP_NUMEQUAL",
"desc": "uncooked()#",
"kind": "nonstandard"
}
My questions are:
- Apparently, it is anticipated that the parity (first
0x02
or0x03
) byte is dropped from the 33 byte keys that I put within the descriptors, once I created the output. The keys grow to be 32-byte x-only keys. When spending and verifying this, how does it get better the parity data, it seems to be misplaced within the decoded tapscript? - Why does
decodescript
returnnonstandard
? My core model is v0.25, and the spent prevout was created by its bitcon-cli. btcdeb
refuses to validate this script. This might be because ofbtcdeb
being on the v0.24 nonetheless, nevertheless.