<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 (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(,multi_a(1,,))
After the spending transaction was mined into a block, I viewed the multisig script: bitcoin-cli -regtest decodescript  where  was the penultimate element of the input witness stack. I got:
{
  "asm": " OP_CHECKSIG  OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw()#",
  "type": "nonstandard"
}

My questions are:

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?
Why does decodescript return nonstandard? My core version is v0.25, and the spent prevout was created by its bitcon-cli.
btcdeb refuses to validate this script. This could be due to 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.


---

