Skip to main content
edited body
Source Link

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>key2>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key2>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.
added 37 characters in body
Source Link

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.
added 28 characters in body
Source Link

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack and. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity bit(first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. When spending and verifying this, how does it recover the parity bit, the information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refusesrefuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack and got

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity bit is dropped from the 33 byte keys that I put in the descriptors, when I created the output. When spending and verifying this, how does it recover the parity bit, the information appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.

With bitcoin-cli, I successfully spent (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))

After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript <tapscript> where <tapscript> was the penultimate element of the input witness stack. I got:

{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}

My questions are:

  1. Apparently, it's expected that the parity (first 0x02 or 0x03) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
  2. Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
  3. btcdeb refuses to validate this script. This could be due to btcdeb being on the v0.24 still, however.
Source Link
Loading