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 considered the multisig script: bitcoin-cli -regtest decodescript <tapscript>
the place <tapscript>
was the penultimate aspect 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>",
"sort": "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, after I created the output. The keys turn out to be 32-byte x-only keys. When spending and verifying this, how does it get well 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 may very well be as a consequence ofbtcdeb
being on the v0.24 nonetheless, nevertheless.