rust-bitcoin / rust-bitcoin/rust-bitcoin
Provide suggested provably unspendable taproot internal key
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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