From c7f7ca67162bd61f322efc1a6ffde752130adfc3 Mon Sep 17 00:00:00 2001 From: dergigi Date: Wed, 17 Jun 2026 04:07:37 +0200 Subject: [PATCH] docs(topics): add OP_INTERNALKEY topic page --- data/topics/op-internalkey.mdx | 19 +++++++++++++++++++ data/topics/output-descriptors.mdx | 13 +++++++++++-- 2 files changed, 30 insertions(+), 2 deletions(-) create mode 100644 data/topics/op-internalkey.mdx diff --git a/data/topics/op-internalkey.mdx b/data/topics/op-internalkey.mdx new file mode 100644 index 000000000..c25d722f9 --- /dev/null +++ b/data/topics/op-internalkey.mdx @@ -0,0 +1,19 @@ +--- +title: 'OP_INTERNALKEY' +summary: "A proposed tapscript opcode that pushes a taproot output's internal key onto the stack so scripts can reuse it directly." +category: 'Bitcoin' +aliases: ['BIP 349', 'OP_SUCCESS203', 'taproot internal key'] +--- + +`OP_INTERNALKEY` is a proposed tapscript opcode described in BIP 349. During a [Taproot](/topics/taproot) script-path spend, it would push the taproot output's internal key onto the stack in x-only form. A script could then refer to that key directly instead of hardcoding the same 32-byte value inside the leaf. + +That matters because many taproot constructions already depend on the internal key. Reusing it inside script can save block space, keep key-path and script-path logic aligned, and make some constructions easier to update when the internal key changes. The BIP highlights aggregate-key policies, hash-locked scripts, and re-keyable covenant-style trees as concrete examples. + +`OP_INTERNALKEY` remains a draft proposal. If activated, it would replace one of tapscript's reserved `OP_SUCCESS` opcodes in a soft fork, so older nodes would continue to treat the upgraded opcode space safely until they validate the new rule set. + +## References + +- [BIP 349: `OP_INTERNALKEY`](https://github.com/bitcoin/bips/blob/master/bip-0349.md) +- [bips.dev: `OP_INTERNALKEY`](https://bips.dev/349/) +- [BIP 341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) +- [Bitcoin Core PR #29269: reference implementation](https://github.com/bitcoin/bitcoin/pull/29269) diff --git a/data/topics/output-descriptors.mdx b/data/topics/output-descriptors.mdx index 92ffe733a..ff86a25ba 100644 --- a/data/topics/output-descriptors.mdx +++ b/data/topics/output-descriptors.mdx @@ -2,14 +2,23 @@ title: 'Output descriptors' summary: 'A compact text format that describes exactly how a wallet derives its addresses and scripts from its keys, so any compatible wallet can import it.' category: 'Bitcoin' -aliases: ['output descriptor', 'descriptor', 'descriptors', 'BIP 380', 'wpkh', 'wsh', 'tr()'] +aliases: + [ + 'output descriptor', + 'descriptor', + 'descriptors', + 'BIP 380', + 'wpkh', + 'wsh', + 'tr()', + ] --- An output descriptor is a notation for the scripts a wallet produces. A descriptor like `wpkh([d34db33f/84h/0h/0h]xpub.../0/*)` reads as: derive native [SegWit](/topics/segwit) P2WPKH addresses from this extended public key, at derivation path `0/i`, starting at `i=0`, and remember that the key originated from fingerprint `d34db33f` at path `m/84h/0h/0h`. Imported into any descriptor-aware wallet, that one string scans and spends the same UTXOs as the wallet that exported it, with no ambiguity about script type or derivation. Before descriptors, sharing a wallet across tools required out-of-band conventions. Two wallets could agree on the same master seed and then disagree on which derivation path to scan or which script type to expect. Descriptors fold every piece of that information into one string. A checksum at the end catches accidental edits, and the key-origin fields (`[fingerprint/path]`) tell a hardware signer which of its child keys should sign a given input. -Descriptors compose. `sh(wpkh(...))` wraps a SegWit key inside a P2SH output for legacy compatibility. `wsh(multi(2,key1,key2,key3))` produces a 2-of-3 multisig under a native SegWit output. `tr(internal,{script1,script2})` produces a [Taproot](/topics/taproot) output with an internal key and a script tree. The fragments nest the same way the underlying Bitcoin scripts do, which makes descriptors a clean pair with [Miniscript](/topics/miniscript) for spending policies that go beyond single-key wallets. +Descriptors compose. `sh(wpkh(...))` wraps a SegWit key inside a P2SH output for legacy compatibility. `wsh(multi(2,key1,key2,key3))` produces a 2-of-3 multisig under a native SegWit output. `tr(internal,{script1,script2})` produces a [Taproot](/topics/taproot) output with an internal key and a script tree. Proposals such as [OP_INTERNALKEY](/topics/op-internalkey) would let tapscript access that same key directly. The fragments nest the same way the underlying Bitcoin scripts do, which makes descriptors a clean pair with [Miniscript](/topics/miniscript) for spending policies that go beyond single-key wallets. Descriptors are standardized across [BIPs 380 to 386](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki). Bitcoin Core adopted them for its wallet format, and they are now the default for newly created wallets. [BDK](/projects/bdk), `rust-bitcoin`, and descriptor-based wallets such as Bitcoin Safe, Liana, and Sparrow use them as the primary wallet format, and hardware signers increasingly accept descriptors for multisig coordination.