Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions data/topics/op-internalkey.mdx
Original file line number Diff line number Diff line change
@@ -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)
13 changes: 11 additions & 2 deletions data/topics/output-descriptors.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
Loading