Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unspendable Miniscript key #558

Open
uncomputable opened this issue Jun 28, 2023 · 3 comments
Open

Unspendable Miniscript key #558

uncomputable opened this issue Jun 28, 2023 · 3 comments

Comments

@uncomputable
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants