Monday, September 16, 2024

multi signature – P2TR script-path multisig

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:

  1. Apparently, it is anticipated that the parity (first 0x02 or 0x03) 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?
  2. Why does decodescript return nonstandard? My core model is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could possibly be as a result of btcdeb being on the v0.24 nonetheless, nevertheless.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles