Unspendable Miniscript key

rust-bitcoin / rust-miniscript

Support for Miniscript and Output Descriptors for rust-bitcoin

Creative Commons Zero v1.0 Universal

343 stars 135 forks source link

Unspendable Miniscript key #558

Open uncomputable opened 1 year ago

uncomputable commented 1 year ago

For testing purposes and for an unused Taproot internal key, it can be useful to have a key that is provably unspendable. For instance, there is lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0) from BIP 341. This should work in generic contexts.

We could add a sub trait of MiniscriptKey that returns a constant unspendable key. In rust-simplicity we recently added this. Randomized or iterative unspendable keys probably go a bit too far.

Any ideas?

apoelstra commented 1 year ago

No ideas, but I have a few thoughts:

In general, for taporot keys we may want the top-level key to be a fixed unspendable key, while internal keys are a generic Pk which might be a String or something. Do we want the top-level key and internal keys to have different types?
Maybe we want to add an unspendable constructor to all MiniscriptKey types. For strings we could reserve a fixed string "<unspendable>" or something like this. Less clear what users of custom key types ought to do.
Maybe the constructor could return a Result and we add a default implementation that always errors?
Do we have a standard unspendable xpub?
For private-key-containing descriptors how should we handle this?

sanket1729 commented 1 year ago

I am not sure how I feel about this. Because a lot of times, the values of other Pk when Pk = String or when other types don't necessarily make sense.

I would not want to add this to MiniscriptKey, but adding as an extension trait seems okay. In rust-miniscript taproot compiler, we ended up going with a optional argument where necessary.

See: https://github.com/rust-bitcoin/rust-miniscript/blob/a3327ba73111e586246889242745e7774f5b994e/src/policy/concrete.rs#L328C26-L328C38

apoelstra commented 1 year ago

The compiler API has the same problems we're having -- if the user needs an unspendable key but their Pk type doesn't naturally have one then they're screwed.

Could we add another taproot descriptor variant which had an unspendable key? Or maybe make the taproot internal key be an Option<Pk> which serializes as unspendable when it's not provided?