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(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))
After the spending transaction was mined right into a block, I seen the multisig script: bitcoin-cli -regtest decodescript <tapscript>
the place <tapscript>
was the penultimate component of the enter witness stack. I acquired:
{
"asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
"desc": "uncooked(<hex>)#<checksum>",
"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 recuperate the parity info, 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 could possibly be as a result ofbtcdeb
being on the v0.24 nonetheless, nevertheless.