rust-bitcoin / rust-bitcoin/rust-bitcoin

Provide suggested provably unspendable taproot internal key

Open
#1,322 14 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
2.7k
Forks
1k
Avg merge
4d 39m
Merged PRs (30d)
86

Description

I'm trying to construct a taproot transaction that provably disables the key-path by using a provably unspendable key for the internal key.

BIP-341 suggests using the following internal key if the taproot key-path spend should be provably unspendable:

If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a point with unknown discrete logarithm. One example of such a point is H = lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0) which is constructed by taking the hash of the standard uncompressed encoding of the secp256k1 base point G as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer r in the range 0...n-1 uniformly at random and use H + rG as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to G by revealing r to a verifier who can then reconstruct how the internal key was created.

It would be nice to provide H, perhaps as bitcoin::util::taproot::PROVABLY_UNSPENDABLE_INTERNAL_KEY, or something of the like.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in the bitcoin::util::taproot entry point and review how public taproot constants and documentation are exposed. Add the requested H value as a suggested provably unspendable internal key, following the surrounding API conventions. Done when callers can access the constant and its value is verified by the relevant taproot tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cryptography
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.