<pre>
  BIP: ?
  Layer: Applications
  Title: unspendable() Descriptor Key Expression
  Author: Andrew Toth <andrewstoth@gmail.com>
          Kewde <kewde@particl.io>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
  Status: Draft
  Type: Standards Track
  Created: 2024-12-12
  License: BSD-2-Clause
</pre>

==Abstract==
This document specifies a <tt>unspendable()</tt> key expression for output script descriptors. The <tt>unspendable()</tt> expression takes multiple public keys as input and produces an unspendable public key that can be independently verified by anyone with knowledge of all the constituent public keys.

==Copyright==

This BIP is licensed under the BSD 2-clause license.

==Motivation==

This document introduces a mechanism to compute a NUMS (Nothing Up My Sleeve) point for use in the Taproot key path that:
* Allows active participants involved in constructing the output script to independently verify the unspendable key.
* Prevents passive observers from recognizing that the key path is unspendable.
* Enables signers with limited information, such as hardware wallets, to verify unspendability without requiring user interaction.

==Specification==

A new key expression is defined: <tt>unspendable()</tt>.

===<tt>unspendable(KEY, KEY, ..., KEY)</tt>===

The vector of keys is processed in the following sequence: deduplication, compression, sorting, concatenation, and finally, SHA256 hashing to generate a chaincode <tt>r</tt>.
A new unspendable key is constructed by taking the NUMS point <tt>H</tt>, suggested in BIP-0341, and attaching the chaincode <tt>r</tt> we previously computed.
<tt>H + r*G</tt> where <tt>H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)</tt>

Q: should we add a prefix like the "BIPXXXX" before we SHA256 the keys to ensure the preimage was not previously leaked before this BIP?
Q: is it desireable to specify the keys in the expressions or to extract it from the script expression indirectly?
Q: compress first and then sort, or sort and then compress?

==Test Vectors==

TBD Andew

==Rationale==

This proposal ensures:
* Compatibility with existing Taproot functionality by leveraging NUMS points.
* Verifiability of unspendable constructions by participants, without exposing this property to outside observers.
* Security and simplicity for signers with limited information (e.g., hardware wallets).


==Reference Implementation==

TBD

==Acknowledgements==

Thanks to Salvatore Ingala, Pieter Wuille, Antoine Poinsot, Andrew Kozlik and all others who
participated in discussions on this topic.