LibraryPrivacy2020Design paperCorpus record
BIP 341: Taproot: SegWit version 1 spending rules
Taproot. Pieter Wuille, Jonas Nick and Anthony Towns.
A Bitcoin spend that can look like a single key, while still hiding a tree of alternative scripts until one of them is used. Schnorr signatures and the key-path spend are the mechanism. Amounts stay public. This is not a privacy coin.
Taproot is a Bitcoin spending rule. A key-path spend is a single Schnorr signature and reveals no script. A script-path spend reveals only the leaf that was used. Complex contracts can therefore look like ordinary payments until they do not. Amounts and the transaction graph stay public.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 18
Code
Source, repository, and what is actually hosted
- BIP 341https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
- bitcoin/bipsRepository taken from the source URL. 97 other studies in this library cite the same repository. This is not an audit.
- Full upstream textMirrored 2026-10-10 under BSD-3-Clause. The desk study is not part of that licence.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
The tweak commits to the tree
The on-chain key is the internal key tweaked by the Merkle root of the scripts. A key-path signature is valid only for the party who knows that key. The scripts stay off-chain unless needed.
Claim 02 · Paper model
One leaf, not the whole contract
The script path publishes one leaf and a Merkle proof. Unused branches are not revealed. That is the privacy gain, and its limit.
Claim 03 · Paper model
Three BIPs
BIP 340 is Schnorr. BIP 341 is this spending rule. BIP 342 is the small script upgrade used inside leaves. A wallet can implement one badly and still say Taproot.
Claim 04 · Paper model
The anonymity set is social
Key-path spends resemble each other only if people actually use them. A network where every interesting contract takes the script path immediately does not get the set the BIP describes.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The tweak commits to the tree
Observation
What the study says
The on-chain key is the internal key tweaked by the Merkle root of the scripts. A key-path signature is valid only for the party who knows that key. The scripts stay off-chain unless needed.
Model
What has to hold
Key-path keys are aggregated properly when more than one party must sign. That is MuSig2 or FROST, not BIP 341 alone.
Falsifier
What would retire it
If several parties hold the key, which multi-signature scheme produced it?
02 One leaf, not the whole contract
Observation
What the study says
The script path publishes one leaf and a Merkle proof. Unused branches are not revealed. That is the privacy gain, and its limit.
Model
What has to hold
Unused script leaves remain private only if they are not published elsewhere.
Falsifier
What would retire it
Was the spend key path or script path?
03 Three BIPs
Observation
What the study says
BIP 340 is Schnorr. BIP 341 is this spending rule. BIP 342 is the small script upgrade used inside leaves. A wallet can implement one badly and still say Taproot.
Model
What has to hold
Unused script leaves remain private only if they are not published elsewhere.
Falsifier
What would retire it
Was the spend key path or script path?
04 The anonymity set is social
Observation
What the study says
Key-path spends resemble each other only if people actually use them. A network where every interesting contract takes the script path immediately does not get the set the BIP describes.
Model
What has to hold
Outputs use this witness version. A wrapped older script is not in the anonymity set.
Falsifier
What would retire it
Was the spend key path or script path?
03 Sequence
One action, as an operating tape
- 01A wallet constructs an internal key and an optional script tree.
- 02It publishes the tweaked key as the output.
- 03To take the key path, it produces a Schnorr signature.
- 04To take a script path, it reveals the leaf, the proof, and whatever that leaf's script requires.
- 05Nodes apply BIP 341's weight and validation rules. They do not learn the unused leaves.
04 Load-bearing
The argument, and where a pitch drops it
Not a privacy coin
The cut
Nothing in the BIP hides amounts or breaks the transaction graph. A reader who needs those properties is in the wrong paper. CryptoNote and Zerocash are about different designs.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Amounts, the graph of transactions, and a revealed script are still visible.
Not a new execution engine
The cut
Taproot does not make Bitcoin script Turing-complete. BitVM is a later attempt to dispute general computation using Taproot trees, and it is a different document.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Amounts, the graph of transactions, and a revealed script are still visible.
05 Register
What has to be true
Model · Not re-measured
Outputs use this witness version. A wrapped older script is not in the anonymity set.
Cryptography · Not re-measured
Key-path keys are aggregated properly when more than one party must sign. That is MuSig2 or FROST, not BIP 341 alone.
Data · Not re-measured
Unused script leaves remain private only if they are not published elsewhere.
Model · Not re-measured
Consensus rules are the BIPs as deployed. Draft text and activated text should not be mixed silently.
06 Divergence
What happened after the paper
Taproot activated on Bitcoin and became the assumed output type for new Lightning and for MuSig2 wallets. The BIP is still the right document for what a spend reveals. It is the wrong document for a claim that Bitcoin transactions became private.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
Complex Bitcoin scripts announce themselves. A multisig, a lightning channel and a simple payment should not have to look different when they take the ordinary path. Taproot makes the ordinary path a key spend.
What the design proposes
- A public key tweaked by the Merkle root of a script tree.
- The key path spends with a Schnorr signature and reveals no script.
- The script path reveals only the leaf that was used, plus a proof it sat in the tree.
How the mechanism is specified
- Unspent outputs that share this pattern are indistinguishable from each other on the key path.
- Taking the script path publishes that leaf. The privacy claim is about the path not taken.
- BIP 341 is the spending rule. BIP 340 is the signature. BIP 342 is the script opcode change. They travel together in deployment and they are not the same document.
What this page does not treat as proven
- Amounts, the graph of transactions, and a revealed script are still visible.
- If most users do not use the key path, the anonymity set the BIP hopes for does not arise.
- The BIP does not create covenants, a virtual machine, or a bridge.
Why the desk still reads it
A wallet that says Taproot should be able to say whether a given spend was key path or script path. If every spend reveals a custom script, the BIP's privacy argument is not in use.
09 Lexicon
Terms, opened into the record
- Key path
- A spend that is just a signature under the tweaked key, with no script revealed.
- Script path
- A spend that reveals one committed script leaf and a Merkle proof of its place in the tree.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Upstream
The file, in full
Licence recorded on the mirror: BSD-3-Clause. Canonical file: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki. Numbers and web addresses in the file open a study or the address itself.
Loading the mirrored file.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.
