<ol>
<li><p>Yes, the conversion from descriptor to script converts the keys to x-only form, because that is the only public key format supported inside tapscript. There is no parity information to recover; these are the full public keys as far as the <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="nofollow noreferrer">BIP340</a> signature scheme is concerned.</p>
</li>
<li><p>This script would be nonstandard when placed in a scriptPubKey directly. Inside tapscript, p2wsh, and p2sh, almost any script is permitted by policy.</p>
</li>
<li><p>I am unfamiliar with btcdeb.</p>
</li>
</ol>

CC BY-SA 4.0
2024-07-24T11:39:23.073Z
2024-07-24T13:55:21.453Z
2024-07-24T13:55:21.453Z
Pieter Wuille
<p>With bitcoin-cli, I <a href="https://bitcoin.stackexchange.com/questions/123669/how-to-spend-a-multisig-descriptor-wallet-transaction-with-bitcoin-cli">successfully spent</a> (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.</p>
<p>The spent prevout descriptors were:</p>
<p><code>tr(&lt;unspendable_bip341_key&gt;,multi_a(1,&lt;even-parity-33-byte-key1&gt;,&lt;odd-parity-33-byte-key2&gt;))</code></p>
<p>After the spending transaction was mined into a block, I viewed the multisig script: <code>bitcoin-cli -regtest decodescript &lt;tapscript&gt;</code> where <code>&lt;tapscript&gt;</code> was the penultimate element of the input witness stack. I got:</p>
<pre class="lang-json prettyprint-override"><code>{
  &quot;asm&quot;: &quot;&lt;x-only-32-bytes-of-key1&gt; OP_CHECKSIG &lt;x-only-32-bytes-of-key2&gt; OP_CHECKSIGADD 1 OP_NUMEQUAL&quot;,
  &quot;desc&quot;: &quot;raw(&lt;hex&gt;)#&lt;checksum&gt;&quot;,
  &quot;type&quot;: &quot;nonstandard&quot;
}
</code></pre>
<p>My questions are:</p>
<ol>
<li>Apparently, it's <a href="https://bitcoin.stackexchange.com/a/117520/137810">expected</a> that the parity (first <code>0x02</code> or <code>0x03</code>) 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?</li>
<li>Why does <code>decodescript</code> return <code>nonstandard</code>? My core version is v0.25, and the spent prevout was <a href="https://bitcoin.stackexchange.com/a/123690/137810">created</a> by its bitcon-cli.</li>
<li><code>btcdeb</code> <a href="https://github.com/bitcoin-core/btcdeb/issues/154" rel="nofollow noreferrer">refuses</a> to validate this script. This <a href="https://github.com/bitcoin-core/btcdeb/issues/154#issuecomment-2244081180" rel="nofollow noreferrer">could be due to</a> <code>btcdeb</code> being on the v0.24 still, however.</li>
</ol>

<multi-signature><taproot><p2tr><x-only-pubkeys>
P2TR script-path multisig
Alec Matusis
# P2TR script-path multisig

(Asked by: username_0 on 2024-07-23)

With bitcoin-cli, I [successfully spent](https://bitcoin.stackexchange.com/questions/123669/how-to-spend-a-multisig-descriptor-wallet-transaction-with-bitcoin-cli) (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:

```json
{
  "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](https://bitcoin.stackexchange.com/a/117520/137810) 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](https://bitcoin.stackexchange.com/a/123690/137810) by its bitcon-cli.
3. `btcdeb` [refuses](https://github.com/bitcoin-core/btcdeb/issues/154) to validate this script. This [could be due to](https://github.com/bitcoin-core/btcdeb/issues/154#issuecomment-2244081180) `btcdeb` being on the v0.24 still, however.

**Tags:** multi-signature, taproot, p2tr, x-only-pubkeys


---

## 1 answers

### Answer by username_1 on 2024-07-24. Score: 4 | Accepted answer

1. Yes, the conversion from descriptor to script converts the keys to x-only form, because that is the only public key format supported inside tapscript. There is no parity information to recover; these are the full public keys as far as the [BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) signature scheme is concerned.
2. This script would be nonstandard when placed in a scriptPubKey directly. Inside tapscript, p2wsh, and p2sh, almost any script is permitted by policy.
3. I am unfamiliar with btcdeb.


---

