This document specifies a <tt>unspendable()</tt> key expression for output script descriptors. The <tt>unspendable()</tt> expression operates on the root <tt>TREE</tt> expression and produces an unspendable public key that can be independently verified by anyone with knowledge of all the constituent public keys.
When creating a multi-party Taproot transaction spending only from the script path, it is useful to be able to prove to all cosigners that they keypath is unspendable. Otherwise a malicious participant could use an internal key which they have the private key for and spend the transaction out from the rest of the participants.
The <tt>unspendable</tt> expression can only be used as the first argument of a BIP386 <tt>tr(KEY, TREE)</tt> expression. All other <tt>KEY</tt> expressions in the descriptor must be <tt>xpub</tt> encoded extended public keys with exactly 2 unhardened derivation steps. The derivation steps may include <tt>/*</tt> or a BIP389 multipath expression, but still must have only unhardened steps. BIP390 <tt>musig(KEY, KEY, ..., KEY)</tt> expressions are allowed, but the variant with derivation after the expression <tt>musig(KEY, KEY, ..., KEY)/NUM/.../*</tt> is forbidden.
The <tt>unspendable</tt> expression resolves to an extended public key, which is then further derived. As there is no private key for an unspendable key, only unhardened derivation is allowed.
The extended public key is computed by first collecting the public key from all the extended public keys in all the <tt>KEY</tt> expressions. The collection of public keys then has all duplicates removed and the remaining public keys are sorted lexicographically.
The vector of keys is processed in the following sequence: deduplication, compression, sorting, concatenation, and finally, SHA256 hashing to generate a chaincode <tt>c</tt>.
The unspendable BIP32 extended key is constructed by using the NUMS point <tt>H</tt>, suggested in BIP341, as the public key, and the chaincode <tt>c</tt> is computed as follows:
* The public keys are collected from all extended public keys in all <tt>KEY</tt> expressions.
* All duplicate public keys are removed from the collection and the public keys are sorted lexicographically.
* Let ''P<sub>0</sub> ... P<sub>n</sub>'' be the sorted and deduplicated public keys. Using the notation from BIP340, ''c = hash<sub>BIP0???/chaincode</sub>(bytes(P<sub>0</sub>) || ... || bytes(P<sub>n</sub>))''.
Valid descriptors containing the <tt>unspendable</tt> expression followed by the chaincode of the unspendable extended public key they expand to and then the scripts they produce.
Todo: These will be filled in when the BIP number is assigned for the tagged hash.
The following produce identical extended public keys and scripts:
The following has two identical public keys which are deduplicated, and then the remaining two public keys are sorted:xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
The restrictions on <tt>KEY</tt> expressions is necessary to not allow multiple <tt>TREE</tt> expressions which would all produce the same merkle root to produce different internal keys.
* Using different lengths of derivation paths would allow a descriptor using a child xpub to generate a different key, while the merkle root would be identical.
* Not sorting the public keys would allow <tt>sortedmulti</tt> expressions to generate different keys depending on the order specified in the descriptor, while the merkle roots would be identical.
This is backwards compatible with BIP386 by computing the unspendable key as a BIP380 <tt>KEY</tt> expression and replacing the <tt>unspendable</tt> expression as the first argument of the <tt>tr()</tt> expression.
This is backwards compatible with BIP388, since the public keys are deduplicated. The key information vector will contain all the necessary public keys.
