DEV Community: aaron.recompile

Why V3 Matters: Bitcoin’s Relay Layer Was Rewritten, and Most People Didn’t Notice

aaron.recompile — Fri, 03 Jul 2026 02:48:03 +0000

Bitcoin is not a state machine.
It is a verifiable sequence of events.

"Event Machine Letters — Protocol Thoughts on Bitcoin’s Architecture" begins here.

1. What triggered this article

On November 20, t-bast quietly announced something that should not have been possible in 2019:

Two fully compatible implementations of 0-fee channels (Eclair + LDK), and the spec is final.

To many, this looks like an incremental Lightning update.

In reality, it is the public surface area of a multi-year restructuring of Bitcoin Core’s relay layer — work led by developers such as Gloria Zhao, instagibbs, fanquake, Suhas Daftuar, Pieter Wuille, and others.

Matt Corallo summarized it perfectly:

“People underestimate how insanely much work went into restructuring the way Bitcoin Core relays transactions so that protocols like Lightning, Ark, and Spark can be radically simpler.”

This article explains what actually changed, why it matters, and how V3 transforms Bitcoin’s fee and security model.

2. The real problem Lightning could not fix

Lightning’s limitations were never just:

routing
liquidity
HTLC abstraction
channel factories

Lightning’s biggest unsolved problem was simple:

Bitcoin could not reliably propagate multi-transaction packages under real fee pressure.

This created three critical weaknesses:

(1) Unpredictable fee bumping

CPFP only worked in “clean” mempools.

(2) Replacement pinning

Attackers could attach massive children (10,000+ bytes) to inflate absolute fee required for replacement.

(3) Unsafe HTLC resolution under congestion

Because commitment + HTLC-success/timeout would not reliably relay as a unit.

The root cause was in Bitcoin Core’s relay policy, not Lightning.

Lightning could never fix this alone.

3. A concrete example: replacement pinning in the old model

Imagine:

Carol → Bob → Alice (0.5 BTC HTLC)

Bob receives 0.5 BTC from Carol. Bob now tries to cheat Alice by publishing an old commitment transaction.

Alice must publish a penalty transaction before Bob’s timelock expires.

But Bob can pin her:

Bob’s attack (pre-V3)

Broadcasts the old commitment (≈300 bytes)
Immediately attaches a huge CPFP transaction
e.g. 10,000 bytes at 5 sat/vB → 50,000 sats

Now miners see:

commitment (300 bytes)
+ child (10,000 bytes)
= 10,300-byte package

Bitcoin Core’s rules require:

Alice must pay a higher absolute fee than Bob’s entire package.

So if fee rates spike to 50 sat/vB:

10,300 bytes × 50 sat/vB = 515,000 sats

Alice evaluates:

Save 0.5 BTC? Yes.
But Alice’s wallet may only have 0.001 BTC in liquid funds.
Bob can escalate the attack by attaching 50,000-byte children (→ 0.025 BTC cost).
And watchtowers cannot pre-commit to unbounded fee liabilities.

The real problem

The issue is not that “0.00515 BTC is too expensive for 0.5 BTC.”

The problem is that the required fee is unpredictable and potentially unlimited.

A small node with limited liquid capital can be priced out by a richer attacker. even if the channel’s nominal value is large.

Result:

A rich attacker can price a poor user out of security.

This is why Lightning disputes were not reliably safe.

4. Anchors: the missing context most people skip

Lightning attempted to fix fee bumping in 2020 with BIP 330: anchored commitment transactions.

But BIP330 anchors had two major problems:

(1) Anchors were 330 sats in value

They required locking value upfront, and the value was too small during fee spikes.

(2) Anchors still depended on unconstrained child transactions

So attackers could still attach giant CPFP transactions and restore the same old problem.

This is why “anchored commitments” did not deliver fully reliable fee bumping.

5. What actually changed: V3 + Package Relay + Ephemeral Anchors

Here is the structural shift, summarized clearly:

Feature comparison

These are not mempool tweaks.

These are protocol-level invariants.

6. The core guarantee V3 introduces

Now we can state V3’s contribution precisely:

V3 establishes a hard upper bound on the cost of fee-bumping any package containing a V3 transaction.

Mathematically:

max package size = parent_size + 1,000 bytes

This directly eliminates the attacker’s ability to magnify absolute fee requirements.

Before V3:

cost_to_replace = attacker_decides()
(10k, 20k, 50k bytes... unlimited)

After V3:

cost_to_replace = bounded_and_predictable()

This transforms Lightning, Ark, Spark, vaults, and all future L2 protocols from:

“Best effort under good fee conditions”
→
“Deterministically secure even under fee spikes”

This is not an optimization.

It is a semantic correction to Bitcoin’s relay layer.

7. Why Package Relay and P2A are needed together

V3 alone sets size constraints.

But:

Package Relay ensures parent+child propagate together
Ephemeral Anchors ensure fee bumping is always possible without UTXO pollution

The three combine into:

Bitcoin’s first dependency-aware fee and relay model.

This is what enables:

0-fee channel opens
safe HTLC resolution
covenant-based vaults
off-chain contract rollups
Ark withdrawal reliability
safe parallel contract trees
multi-party protocols with guaranteed escape hatches

This did not exist before 2024–2025.

8. Why this work is invisible

When V3, Package Relay, and P2A landed, some people asked:

“Why change RBF rules?”
“Why add a new transaction version?”
“Is this just mempool churn?”
“Why is this needed at all?”

These reactions are understandable — Bitcoin Core’s relay layer is complex, and the benefits appear only indirectly.

But the context is:

These changes remove entire attack classes, not just adjust parameters.

They give L2 protocols clear invariants for the first time.

Without them:

watchtowers cannot price risk
protocols cannot promise safety
channels cannot open without fees
HTLCs fail during congestion
covenants cannot guarantee exit safety

This is infrastructure work — often unnoticed, always essential.

9. Real-world impact

Lightning

0-fee channel opens
safe HTLC resolution during fee spikes
predictable penalty enforcement
simplified implementations (Eclair + LDK now interoperable)

Ark

reliable vtxo expiry
safe connector exits
predictable mass-exit fee models

Future protocols

covenant vaults
channel factories
state channels
rollup-style constructions
ANY protocol needing deterministic fee bumping

The second layer is now operating on a far stronger foundation.

10. Conclusion: why V3 truly matters

The story is not:

“Lightning finally gets 0-fee channels.”

The real story is:

Bitcoin Core finally provides the fee guarantees and relay invariants that Lightning, Ark, Spark, vaults, and future L2 protocols always needed.

V3, Package Relay, and Ephemeral Anchors are not mempool tweaks.

They are a structural repair to Bitcoin’s relay architecture.

Most people didn’t notice.

But every serious protocol will benefit from it for the next decade.

By Aaron Recompile on November 22, 2025.

Canonical link

Exported from Medium on July 3, 2026.

Why Counterparty’s Fake-Pubkey Grinding Reveals the Real Boundary Between Bitcoin Consensus and…

aaron.recompile — Fri, 03 Jul 2026 02:48:01 +0000

Bitcoin is not a state machine.
It is a verifiable sequence of events.

"Event Machine Letters - Protocol Thoughts on Bitcoin's Architecture" begins here.

Introduction

While writing Chapter 5 of my book How People Tried to Push Non-Transaction Data into Bitcoin, I fell into a technical rabbit hole: How did Counterparty manage to store structured payloads inside bare multisig outputs?

The answer turned out to be more interesting than expected — not because of multisig itself, but because Counterparty’s “fake-pubkey grinding” exposes a deep and often misunderstood distinction in Bitcoin:

Consensus guarantees possibility.
Policy guarantees sanity.

Most debates around Bitcoin protocol behavior (including recent ones) come from mixing these two layers together. Counterparty provides a perfect historical case study for why this distinction matters.

1. Counterparty’s Hack: Multisig as a Data Container

Counterparty (2014) was the first protocol to systematically embed arbitrary data in Bitcoin by encoding payloads inside fake public keys placed in a 1-of-3 bare multisig output:

OP_1 <fake_pubkey1> <fake_pubkey2> <real_pubkey> OP_3 OP_CHECKMULTISIG

The fake pubkeys contained 64 bytes of payload
The real pubkey ensured the output was theoretically spendable
OP_RETURN carried only the instruction header
Multisig carried the full structured payload

This design allowed Counterparty to break through the ~80-byte OP_RETURN limit and support more complex protocol messages.

But it also forced Counterparty to confront Bitcoin’s deepest rules.

2. Why Fake Pubkeys Must Be Valid EC Points

At first glance, one might think:

“If Counterparty never plans to spend these outputs, who cares if the pubkeys are valid?”

Bitcoin cares — a lot.

Before a transaction can enter the mempool, Bitcoin Core performs a full consensus-level script validity check. This check ensures:

The script is syntactically valid
No opcode triggers immediate failure
Every pubkey is a valid secp256k1 point
CHECKMULTISIG would not immediately error

Bitcoin does not allow an output that is provably unspendable due to script error. That would violate consensus rules, not policy.

Thus:

Even if no one will ever spend the output, fake pubkeys still must be on the secp256k1 curve.

This is why Counterparty clients had to grind fake pubkeys:

Grinding =

Search for an x-coordinate that:

Encodes the payload (high bits), and
Produces a valid curve point (low bits adjusted until valid)

Only such points can be accepted into the mempool and relayed across the network.

Without a valid EC point, the transaction never broadcasts — it fails before policy even enters the picture.

3. Consensus vs. Policy: What Counterparty Accidentally Taught Us

Counterparty’s architecture forces us to confront the difference between two layers often confused in Bitcoin debates.

Consensus Layer: Strict Logic, Wide Permission

Consensus rules guarantee:

Every output is theoretically spendable
Script execution will not immediately error
Public keys are valid
CHECKMULTISIG would not produce ScriptError
Script semantics are self-consistent

Consensus does not care:

whether an output will ever be spent
whether the pubkey is used as a data container
whether the protocol “abuses” Bitcoin
whether it’s storing JPEGs or metadata
whether users are burning dust forever

Bitcoin consensus is maximalist in a very precise way:

If your pubkey is valid and your script is internally consistent, consensus says “Yes.”

It is rule-bound but not value-judging — almost Confucian in spirit.

Policy Layer: Pragmatic, Local, Protective

Policy rules — Bitcoin Core’s mempool rules — are not consensus. They exist only to prevent node DoS and spam.

Policy restricts:

bare multisig relay
multisig N ranges
dust thresholds
OP_RETURN sizes
nonstandard script forms

These rules:

vary between node implementations
do not affect the blockchain
do not define Bitcoin’s consensus
only determine whether the transaction is relayed and mined easily

This is why Counterparty eventually became marginalized:

Consensus allowed it
Policy discouraged it

Bare multisig became a disfavored pattern, even though it remains fully valid at the consensus layer.

4. The Real Insight: Bitcoin Allows Abuse at Consensus, Discourages It at Policy

Counterparty sits precisely at the intersection of the two:

Consensus:

“That fake pubkey is a valid secp256k1 point? Then this multisig output is fine.”

Policy:

“Don’t fill the UTXO set with garbage. We may choose not to relay this.”

Users:

“These outputs are dust. We’re never spending them anyway.”

Thus, Counterparty becomes:

Consensus permissiveness ×
Policy defensiveness ×
User economic behavior

It’s far more than a curiosity of early NFT history. It’s a case study in how Bitcoin’s layered design produces emergent behavior.

5. Why This Distinction Matters Today

A surprising number of recent Bitcoin debates — OP_RETURN policy changes, Ordinals arguments, BitVM anchoring, and even knothole discussions — stem from the same misunderstanding:

People mix up consensus rules (what is allowed) with policy rules (what is relayed or encouraged).

Counterparty’s fake-pubkey grinding is the earliest and clearest reminder of this separation.

Understanding it is essential for understanding Bitcoin’s evolution — and the fights that continue around it.

Conclusion

Counterparty wasn’t just a creative hack for storing data in Bitcoin. It was the first protocol to unintentionally illuminate the boundary between can and should, between consensus and policy.

And many misunderstandings in today’s discussions remain unsolved simply because this boundary is still not widely understood.

If we want to reason clearly about Bitcoin’s future, this distinction is the place to start.

By Aaron Recompile on November 24, 2025.

Canonical link

Exported from Medium on July 3, 2026.

The Missing Developer Stack of Taproot

aaron.recompile — Fri, 03 Jul 2026 02:48:00 +0000

Why Taproot still lacks the infrastructure developers need

Introduction — Taproot is deployed, but underused

Taproot activated in 2021 and introduced one of the most powerful upgrades in Bitcoin’s scripting history.

It enabled Schnorr signatures, key aggregation, script trees, and meaningfully improved privacy for complex spending conditions. From a protocol perspective, Taproot is complete.

However, four years after activation, most Taproot outputs on chain are still spent via key-path spends, while script-path usage remains relatively rare.

This raises an obvious question: if Taproot is so powerful, why are complex script constructions still uncommon?

The answer is not a limitation of the protocol. It is a limitation of the developer infrastructure around it.

Taproot currently lacks a coherent developer stack.

Layer 1 — Debugging and Measurement Tools

One of the biggest obstacles developers face when working with Taproot is visibility.

A Taproot script-path spend contains multiple layers of cryptographic commitments:

TapLeaf hash
  → Merkle path
    → Control block
      → TapTweak
        → Tweaked output key

Understanding or verifying these steps manually is difficult. Today, most tools provide only basic transaction decoding. Bitcoin Core’s decoderawtransaction, for example, does not reconstruct TapLeaf hashes, Merkle path structure, control block interpretation, or tweak verification.

As a result, developers often fall back to ad-hoc scripts or manual calculations. This friction discourages experimentation.

What is missing are Taproot inspection tools: witness analyzers, control block inspectors, commitment reconstruction tools, and chain-level measurement frameworks for understanding how Taproot is being used in practice. Without these, debugging Taproot scripts is unnecessarily opaque — even for developers who understand the protocol.

Layer 2 — Script Engineering Knowledge

Even when developers understand the protocol rules, there is a second, more subtle gap: engineering patterns.

The Taproot BIPs define the system precisely:

BIP340 — Schnorr signatures
BIP341 — Taproot construction
BIP342 — Tapscript

But these documents do not answer the practical questions that arise when building real systems:

How should a complex script tree be structured?
How should leaf ordering be chosen?
What privacy trade-offs emerge from different tree designs?
How should multiple spending conditions be composed efficiently?

These are engineering questions, not protocol questions — and the gap is more concrete than it might sound.

Take leaf ordering as one example. In a Taproot tree with multiple spending conditions, placing the most likely-to-be-used leaf at a lower depth reduces the control block size required at spend time. But leaf position also has privacy implications: a shallow leaf reveals less of the tree than a deep one, and an analyst observing script-path spends over time can make probabilistic inferences about tree structure. How a developer balances these trade-offs is not specified anywhere in the BIPs.

Or take control block size itself. In a balanced binary tree of depth d, the control block grows by 32 bytes per level (one hash per Merkle path step). A tree with 8 leaves at depth 3 requires a 3-hash control block; a pathological linear tree of the same 8 leaves can require up to 7 hashes for the deepest leaf. The choice of tree topology is therefore an engineering decision with real on-chain cost and privacy consequences — but there is no reference material telling developers how to think about it.

In other ecosystems, these answers emerge as design patterns, reference implementations, and cookbook-style documentation. For Taproot, this material is still scarce. As a result, many developers treat Taproot scripts as theoretical capabilities rather than practical building blocks.

Layer 3 — Playground Infrastructure

The final missing piece is experimentation infrastructure.

Developers working in other scripting environments typically have access to purpose-built tooling: local deployment environments, transaction simulators, interactive debuggers. Bitcoin development is different by design — Bitcoin Script is not a general-purpose computation system, and the comparison has real limits. But the underlying need is similar: a low-friction way to construct, test, and iterate on script logic before committing to mainnet.

The typical Taproot development workflow today still looks like:

bitcoind → regtest → RPC calls → manual transaction construction

This workflow is fully capable, but it requires assembling many pieces by hand, and there is no dedicated tooling for Taproot-specific tasks. A focused Taproot development environment could provide script tree construction tools, transaction simulation with witness inspection, reproducible test cases, and interactive control block debugging. The goal is not to replicate Ethereum’s tooling philosophy — it is to give Bitcoin developers the same ability to move quickly and verify their understanding that regtest alone does not provide.

Such infrastructure would significantly lower the barrier to experimentation and reduce the time between “I have an idea” and “I have a working transaction.”

Why This Matters

Taproot was designed to enable a wide range of advanced protocols: vault constructions, DLCs, covenant-like structures, and future contract systems. But protocols do not emerge automatically. They require tools, examples, and experiments.

The current situation is not a failure of the protocol — it is a gap in the surrounding ecosystem. Developers who might otherwise explore Taproot’s capabilities are slowed down at each layer: they cannot see what is happening inside their transactions, they have no engineering patterns to reason from, and they have no low-friction environment in which to iterate.

Each of these is a solvable problem.

Conclusion

Taproot itself is not missing any functionality. What is missing is the developer stack around it.

Three layers remain underdeveloped:

Debugging and measurement tools — witness analyzers, control block inspectors, commitment reconstruction tools, and chain-level measurement frameworks
Script engineering knowledge — concrete patterns for tree design, leaf ordering, privacy trade-offs, and spending condition composition
Playground infrastructure — a focused environment for Taproot experimentation that reduces the gap between understanding the protocol and building with it

Building this stack is likely one of the most important steps for unlocking the full potential of Taproot.

The protocol is already here. Now the ecosystem needs the tools that allow developers to truly use it.

By Aaron Recompile on March 11, 2026.

Canonical link

Exported from Medium on July 3, 2026.

The Anatomy of Bitcoin Scripts: From P2PKH to Taproot

aaron.recompile — Fri, 03 Jul 2026 02:47:58 +0000

Companion notes to my book Mastering Taproot.

HODLing is the beginning.
But Bitcoin was meant to be programmed.

"Not Just HODLing: Real Bitcoin Script Engineering" starts here.

The Universal Truth

Every Bitcoin address — from the genesis block to the latest Taproot output — follows one fundamental pattern:

Lock:   Commit to a condition
Unlock: Reveal proof that you satisfy it

This isn’t a feature of SegWit or Taproot. It’s the DNA of Bitcoin itself.

Evolution of Commit-Reveal

The abstraction deepens. The privacy improves. The core logic remains unchanged.

Locking Script Formats

P2PKH

OP_DUP OP_HASH160 <20-byte pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

P2SH

OP_HASH160 <20-byte script_hash> OP_EQUAL

P2WPKH

OP_0 <20-byte pubkey_hash>

P2WSH

OP_0 <32-byte script_hash>

P2TR

OP_1 <32-byte output_pubkey>

How nodes differentiate SegWit types:

OP_0 + 20 bytes → P2WPKH
OP_0 + 32 bytes → P2WSH
OP_1 + 32 bytes → P2TR

The Verification Flow

Universal Pattern

Step 1: Verify Commit — Does the revealed content match what was promised?
Step 2: Execute Script — Do the conditions evaluate to true?

P2SH Verification

HASH160(redeem_script) == hash in locking script?
Match → Execute redeem_script

P2WSH Verification

SHA256(witness_script) == hash in locking script?
Match → Execute witness_script

P2TR Script Path Verification

1. Extract internal_pubkey from control block
2. Compute tapleaf_hash from script
3. Calculate merkle_root using Merkle path
4. tweak = TaggedHash("TapTweak", internal_pubkey || merkle_root)
5. computed_pubkey = internal_pubkey + tweak × G
6. computed_pubkey == output_pubkey in locking script?
7. Match → Execute tapscript

Stack Execution Visualized

Example 1: P2PKH

Locking Script: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

Unlock Data: <signature> <pubkey>

Initial Stack      OP_DUP         OP_HASH160      PUSH hash
┌─────────┐       ┌─────────┐    ┌─────────┐     ┌─────────┐
│ pubkey  │       │ pubkey  │    │ pk_hash │     │ pk_hash │ ← expected
├─────────┤       ├─────────┤    ├─────────┤     ├─────────┤
│ sig     │       │ pubkey  │    │ pubkey  │     │ pk_hash │ ← computed
└─────────┘       ├─────────┤    ├─────────┤     ├─────────┤
                  │ sig     │    │ sig     │     │ pubkey  │
                  └─────────┘    └─────────┘     ├─────────┤
                                                 │ sig     │
                                                 └─────────┘

OP_EQUALVERIFY     OP_CHECKSIG      Final
┌─────────┐        ┌─────────┐      ┌─────────┐
│ pubkey  │        │ 1(true) │      │ 1(true) │ ✓
├─────────┤        └─────────┘      └─────────┘
│ sig     │
└─────────┘

Example 2: P2SH with Timelock

Redeem Script: OP_3 OP_CSV OP_DROP OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG

Unlock Data: <signature> <pubkey>

Initial Stack      PUSH 3         OP_CSV          OP_DROP
┌─────────┐       ┌─────────┐    ┌─────────┐     ┌─────────┐
│ pubkey  │       │ 3       │    │ 3       │     │ pubkey  │
├─────────┤       ├─────────┤    ├─────────┤     ├─────────┤
│ sig     │       │ pubkey  │    │ pubkey  │     │ sig     │
└─────────┘       ├─────────┤    ├─────────┤     └─────────┘
                  │ sig     │    │ sig     │
                  └─────────┘    └─────────┘
                                 Check nSeq ≥ 3

Continues with standard P2PKH logic...

Example 3: P2WPKH

Locking Script: OP_0 <20-byte pubkey_hash>

Witness: <signature> <pubkey>

Node sees OP_0 + 20 bytes, implicitly executes P2PKH logic:

Verification: HASH160(pubkey) == hash in locking script? Match → Continue


Execution (implicit P2PKH logic):

Initial Stack      OP_DUP         OP_HASH160      PUSH hash
┌─────────┐       ┌─────────┐    ┌─────────┐     ┌─────────┐
│ pubkey  │       │ pubkey  │    │ pk_hash │     │ pk_hash │ ← expected
├─────────┤       ├─────────┤    ├─────────┤     ├─────────┤
│ sig     │       │ pubkey  │    │ pubkey  │     │ pk_hash │ ← computed
└─────────┘       ├─────────┤    ├─────────┤     ├─────────┤
                  │ sig     │    │ sig     │     │ pubkey  │
                  └─────────┘    └─────────┘     ├─────────┤
                                                 │ sig     │
                                                 └─────────┘
OP_EQUALVERIFY     OP_CHECKSIG      Final
┌─────────┐        ┌─────────┐      ┌─────────┐
│ pubkey  │        │ 1(true) │      │ 1(true) │ ✓
├─────────┤        └─────────┘      └─────────┘
│ sig     │
└─────────┘

Difference from P2PKH: Identical logic, unlock data moved from scriptSig to witness.

Example 4: P2WSH (2-of-3 Multisig)

Locking Script: OP_0 <32-byte script_hash>

Witness Script: OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

Witness: OP_0 <sig1> <sig2> <witness_script>

Verification: SHA256(witness_script) == hash? Match → Execute witness_script


Execution:
Initial Stack (witness data excluding witness_script)
┌─────────┐
│ sig2    │
├─────────┤
│ sig1    │
├─────────┤
│ 0       │ ← CHECKMULTISIG bug placeholder
└─────────┘
PUSH 2         PUSH pk1       PUSH pk2       PUSH pk3
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 2       │    │ pk1     │    │ pk2     │    │ pk3     │
├─────────┤    ├─────────┤    ├─────────┤    ├─────────┤
│ sig2    │    │ 2       │    │ pk1     │    │ pk2     │
├─────────┤    ├─────────┤    ├─────────┤    ├─────────┤
│ sig1    │    │ sig2    │    │ 2       │    │ pk1     │
├─────────┤    ├─────────┤    ├─────────┤    ├─────────┤
│ 0       │    │ sig1    │    │ sig2    │    │ 2       │
└─────────┘    ├─────────┤    ├─────────┤    ├─────────┤
               │ 0       │    │ sig1    │    │ sig2    │
               └─────────┘    ├─────────┤    ├─────────┤
                              │ 0       │    │ sig1    │
                              └─────────┘    ├─────────┤
                                             │ 0       │
                                             └─────────┘



PUSH 3                    OP_CHECKMULTISIG           Final
┌─────────┐               ┌─────────┐                ┌─────────┐
│ 3       │               │ 1(true) │                │ 1(true) │ ✓
├─────────┤               └─────────┘                └─────────┘
│ pk3     │
├─────────┤               Verify: at least 2 of 3
│ pk2     │               signatures are valid
├─────────┤
│ pk1     │
├─────────┤
│ 2       │
├─────────┤
│ sig2    │
├─────────┤
│ sig1    │
├─────────┤
│ 0       │ ← consumed (legacy bug)
└─────────┘

The CHECKMULTISIG bug: Due to an off-by-one error in the original implementation, an extra stack element is consumed. Hence the dummy OP_0 at the start of witness.

Example 5: Taproot Script Path

Tapscript: OP_2 OP_CSV OP_DROP <pubkey> OP_CHECKSIG

Witness: <signature> <script> <control_block>

Verification: control_block + script → reconstruct output_pubkey → match locking script

Execution:
Initial Stack      PUSH 2         OP_CSV          OP_DROP
┌─────────┐       ┌─────────┐    ┌─────────┐     ┌─────────┐
│ sig     │       │ 2       │    │ 2       │     │ sig     │
└─────────┘       ├─────────┤    ├─────────┤     └─────────┘
                  │ sig     │    │ sig     │
                  └─────────┘    └─────────┘
                                 Check nSeq ≥ 2



PUSH pubkey        OP_CHECKSIG        Final
┌─────────┐        ┌─────────┐        ┌─────────┐
│ pubkey  │        │ 1(true) │        │ 1(true) │ ✓
├─────────┤        └─────────┘        └─────────┘
│ sig     │
└─────────┘

What SegWit Actually Changed

SegWit wasn’t a revolution. It was a relocation:

What Taproot Actually Changed

Taproot optimized the commit-reveal paradigm:

Control Block Structure:

[1 byte: leaf_version + parity] [32 bytes: internal_pubkey] [32 bytes × N: Merkle path]

Verification Formula:

output_pubkey = internal_pubkey + TaggedHash("TapTweak", internal_pubkey || merkle_root) × G

Key Takeaways

Every address type is commit-reveal — Lock with a hash/pubkey commitment, unlock by revealing the preimage
Locking scripts are routing labels — Nodes use the format to determine validation rules; they don’t execute on stack
Verification precedes execution — First prove “you have the right to run this script”, then verify “does the script pass”
Stack execution is universal — Regardless of address type, it’s all push, pop, verify signatures, check timelocks
The trajectory is clear:

Commitments grow more abstract (pubkey → hash → tweak)
Privacy improves (expose everything → expose only what’s used)
Efficiency increases (fee optimization, verification optimization)

Understanding these primitives is the foundation for everything that follows — Lightning channels, covenant proposals, and whatever comes next.

By Aaron Recompile on November 28, 2025.

Canonical link

Exported from Medium on July 3, 2026.

Taproot Control Block Deep Analysis & Stack Execution Visualization | Part 2

aaron.recompile — Fri, 03 Jul 2026 02:47:56 +0000

HODLing is the beginning.
But Bitcoin was meant to be programmed.

"Not Just HODLing: Real Bitcoin Script Engineering" starts here.

In Part 1, we implemented a complete 4-leaf Taproot tree and successfully executed all spending paths on testnet. But Taproot’s core charm lies not only in implementation, but also in its sophisticated cryptographic mechanisms — how Control Blocks provide Merkle proofs, and how Tapscript executes in the Bitcoin virtual machine.

This article will deeply analyze Control Block construction principles, progressively verify Merkle paths through real on-chain data, and finally demonstrate stack execution processes through animations. This is not just a technical interpretation, but a cryptographic journey.

Article Navigation

Merkle Tree Construction Principles
Control Block Deep Analysis
Merkle Path Reconstruction Verification
Tweak Mechanism Detailed Explanation
Stack Execution Visualization

Review of Our 4-Leaf Taproot Tree Structure

Let’s review the balanced Merkle tree we constructed:

               Root Hash
               /         \
         Branch0         Branch1
        /      \        /       \
  Script0   Script1  Script2  Script3
  (Hash)    (Multi)   (CSV)    (Sig)

Functions of the Four Scripts:

Script0: SHA256 hash lock — spendable by anyone knowing “helloworld”
Script1: 2-of-2 multisig — requires both Alice and Bob signatures
Script2: CSV timelock — Bob can spend after waiting 2 blocks
Script3: Simple signature — Bob can spend directly with signature

Key Address Information:

Taproot Address: tb1pjfdm902y2adr08qnn4tahxjvp6x5selgmvzx63yfqk2hdey02yvqjcr29q
Internal Public Key: 50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3
All transactions successfully confirmed on Bitcoin testnet

Merkle Tree Construction Principles: From TapLeaf to Root

TaggedHash: Bitcoin’s Hash Standard

Taproot uses TaggedHash to prevent hash collision attacks between different protocols:

TaggedHash(tag, data) = SHA256(SHA256(tag) || SHA256(tag) || data)

This dual tagging mechanism ensures that Taproot hashes don’t accidentally collide with hashes from other Bitcoin protocols.

TapLeaf Hash Calculation

Each script is first converted to a TapLeaf hash:

TapLeaf_Hash = TaggedHash("TapLeaf", version || script_length || script_data)

Actual calculation using Script1 (multisig) as an example:

// Script1 raw data (71 bytes)
script1_data = 002050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3ba2084b5951609b76619a1ce7f48977b4312ebe226987166ef044bfb374ceef63af5ba5287

// TapLeaf calculation
Script1_Hash = TaggedHash("TapLeaf", 0xC0 || 0x47 || script1_data)
             = 63cb9e4776a1cbb195c5cf0cbdbb3110d308969353680e38ec5f446336b60def

Where:

0xC0: Tapscript version identifier
0x47: Script length (71 bytes in hexadecimal)
script1_data: The actual script bytecode

TapBranch Hash Calculation

Adjacent TapLeaf hashes are combined into TapBranch:

TapBranch_Hash = TaggedHash("TapBranch", left_hash || right_hash)

Branch0 calculation (Script0 + Script1):

Script0_Hash = fe78d8523ce9603014b28739a51ef826f791aa17511e617af6dc96a8f10f659e
Script1_Hash = 63cb9e4776a1cbb195c5cf0cbdbb3110d308969353680e38ec5f446336b60def

Branch0 = TaggedHash("TapBranch", Script0_Hash || Script1_Hash)
        = 2faaa677cb6ad6a74bf7025e4cd03d2a82c7fb8e3c277916d7751078105cf9df

Branch1 calculation (Script2 + Script3):

First calculate Script2 and Script3 TapLeaf hashes:

// Script2 (CSV timelock) - 20 bytes
script2_data = 52b2752084b5951609b76619a1ce7f48977b4312ebe226987166ef044bfb374ceef63af5ac
Script2_Hash = TaggedHash("TapLeaf", 0xC0 || 0x14 || script2_data)
             = 593d543a01c2c3c16c950ed97dfb3f3a1025b4b66323ed6b2814a1fb61d8e4b9
// Script3 (simple signature) - 34 bytes  
script3_data = 2084b5951609b76619a1ce7f48977b4312ebe226987166ef044bfb374ceef63af5ac
Script3_Hash = TaggedHash("TapLeaf", 0xC0 || 0x22 || script3_data)
             = d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

Then calculate Branch1:

Branch1 = TaggedHash("TapBranch", Script2_Hash || Script3_Hash)
        = TaggedHash("TapBranch", 593d543a... || d6ac4c01...)
        = da55197526f26fa309563b7a3551ca945c046e5b7ada957e59160d4d27f299e3

Final Root Calculation

Root = TaggedHash("TapBranch", Branch0 || Branch1)
     = d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

This Root will be used together with the internal public key to generate the final Taproot address.

Control Block Deep Analysis: Core of Cryptographic Proof

Control Block is the core of Taproot script path spending — it provides cryptographic proof that a specific script is indeed included in the Taproot address commitment.

Using Script1 Multisig Transaction as Example

Transaction ID: 1951a3be0f05df377b1789223f6da66ed39c781aaf39ace0bf98c3beb7e604a1

Control Block Raw Data Deconstruction

Control Block Original Data:

c050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3fe78d8523ce9603014b28739a51ef826f791aa17511e617af6dc96a8f10f659eda55197526f26fa309563b7a3551ca945c046e5b7ada957e59160d4d27f299e3

Field Breakdown Visualization

🔴 Version + Parity (1 byte)

Bytes: c0
Position: [0]

Analysis:

c0 = 11000000 (binary)
First 7 bits: 1100000 → Tapscript version identifier
Last 1 bit: 0 → y-coordinate is even

Purpose: Specify script interpretation version and elliptic curve point y-coordinate parity

🔵 Internal PubKey (32 bytes)

Bytes: 50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3
Position: [1-32]

Analysis: Alice’s internal public key, using x-only format (x-coordinate only)

Purpose:

Key commitment binding
Used for final Taproot address Tweak calculation
Proves Control Block corresponds to specific internal key

🟡 Sibling Hash (32 bytes)

Bytes: fe78d8523ce9603014b28739a51ef826f791aa17511e617af6dc96a8f10f659e
Position: [33-64]

Analysis: Script0 (hash lock script) TapLeaf hash

Merkle Proof Role:

Branch0
   ┌─────┴─────┐
Script0     Script1 ← Current script to prove
   ↑           
   └─ Provide sibling node hash for Branch0 reconstruction

Purpose: Provide Script1’s sibling node hash for Branch0 reconstruction

🟢 Branch Hash (32 bytes)

Bytes: da55197526f26fa309563b7a3551ca945c046e5b7ada957e59160d4d27f299e3
Position: [65-96]

Analysis: Complete Branch1 hash (Script2+Script3 combination)

Merkle Proof Role:

      Root
    ┌───┴───┐
Branch0   Branch1 ← Provide entire opposite branch
  ↑         
  └─ Just reconstructed branch

Purpose: Provide opposite branch hash for final Root reconstruction

Proof Path Overview

Script1 Proof Path: Script1 → Branch0 → Root

Required Data:
✓ Script1 content (obtained from witness)
✓ Script0 hash (🟡 Sibling Hash)
✓ Branch1 hash (🟢 Branch Hash)
✓ Internal public key (🔵 Internal PubKey)

Reconstruction Process:
1. Script1 + Script0 hash → Branch0
2. Branch0 + Branch1 hash → Root
3. Root + Internal public key → Verify Taproot address

Minimal Disclosure Principle

Control Block design embodies the minimal disclosure cryptographic principle:

Hidden Information:

❌ Script0 specific content (only provides hash)
❌ Script2 and Script3 specific content (only provides combined hash)
❌ Complete structure of entire script tree

Exposed Information:

✅ Script1 content (required for execution)
✅ Minimal Merkle proof path
✅ Necessary key commitment

This design ensures only the executed script path is exposed, while all other possible spending conditions remain completely hidden, achieving Taproot’s privacy protection goals.

Reconstructing Merkle Path: Complete Proof from Script1 to Root

Now we will demonstrate step by step how to reconstruct the complete Merkle Root from Control Block information, thereby proving Script1 is indeed included in this Taproot address.

Step 1: Reconstruct Branch0

Known Information:

Script1 content (obtained from witness)
Script0 hash (obtained from Control Block’s 🟡Sibling Hash field)

Calculation Process:

Script0_Hash = fe78d8523ce9603014b28739a51ef826f791aa17511e617af6dc96a8f10f659e
Script1_Hash = TaggedHash("TapLeaf", 0xC0 || 0x47 || script1_data)
             = 63cb9e4776a1cbb195c5cf0cbdbb3110d308969353680e38ec5f446336b60def
Branch0 = TaggedHash("TapBranch", fe78d852... || 63cb9e47...)
        = 2faaa677cb6ad6a74bf7025e4cd03d2a82c7fb8e3c277916d7751078105cf9df

Key Insight: We don’t need to know Script0’s specific content, only its hash value to reconstruct Branch0. This is exactly how MAST privacy works — unused script paths remain completely hidden.

Step 2: Reconstruct Root

Known Information:

Branch0 (just calculated)
Branch1 hash (obtained from Control Block’s 🟢Branch Hash field)

Calculation Process:

Branch1 = da55197526f26fa309563b7a3551ca945c046e5b7ada957e59160d4d27f299e3

Root = TaggedHash("TapBranch", 2faaa677... || da551975...)
     = d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

Verification Result: This calculated Root must be completely identical to the Root used during address generation, otherwise verification fails.

Mathematical Principles of Merkle Path

Control Block essentially provides a Merkle inclusion proof:

Proof Path: Script1 → Branch0 → Root
Required Data: Script1 itself + Script0 hash + Branch1 hash

The elegance of this design lies in:

Minimal Disclosure: Only exposes necessary information on execution path
Efficient Verification: O(log n) complexity proof verification
Privacy Protection: Unused scripts completely hidden

From Root to Taproot Address: Complete Tweak Verification Process

Now that we have reconstructed the Root, we need to verify this Root indeed corresponds to our Taproot address. This is achieved through Taproot’s Tweak mechanism.

Tweak Mechanism Principles

Taproot addresses are generated by “tweaking” the internal public key, with the formula:

tweak = TaggedHash("TapTweak", internal_pubkey || merkle_root)
taproot_pubkey = internal_pubkey + tweak × G (elliptic curve point addition)

This design ensures:

Commitment Binding: Address uniquely corresponds to a specific script tree
Key Derivation: Those with internal private key can derive tweaked private key
Verification Transparency: Anyone can verify correspondence between address and script tree

Step 1: Calculate Tweak Value

Input Parameters:

Internal Public Key: 50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3
Merkle Root: d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

Calculation Process:

tweak_input = 50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3 || 
              d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

tweak = TaggedHash("TapTweak", tweak_input)
      = SHA256(SHA256("TapTweak") || SHA256("TapTweak") || tweak_input)
      = 41e4a46b999a3afcc3f3c7a6e5bf5f96e950c7be3a22cd0b4a4c1e5fdd027788

Step 2: Elliptic Curve Point Operations

Internal Public Key Point:

internal_point = secp256k1_point(50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3)

Tweak Point:

tweak_scalar = 41e4a46b999a3afcc3f3c7a6e5bf5f96e950c7be3a22cd0b4a4c1e5fdd027788
tweak_point = tweak_scalar × G  (G is secp256k1 generator point)

Taproot Public Key:

taproot_point = internal_point + tweak_point
taproot_pubkey = x_coordinate(taproot_point)  // Take x-coordinate as x-only public key

Step 3: Final Verification

Calculation Result:

taproot_pubkey = 925bb2bd44575a379c139d57db9a4c0e8d4867e8db046d4489059576e48f5118

Address Conversion:

// Bech32m encoding
taproot_address = bech32m_encode("tb", 1, taproot_pubkey)
                = tb1pjfdm902y2adr08qnn4tahxjvp6x5selgmvzx63yfqk2hdey02yvqjcr29q

✅ Verification Successful: This result completely matches our used Taproot address!

This mathematical verification proves:

Script1 is indeed committed in the Merkle tree
Merkle Root correctly corresponds to our Taproot address
Control Block provides valid cryptographic proofComparative Analysis of Other Script Paths’ Control Blocks

Let’s quickly compare the Control Block structures of the other three scripts, observing differences in Merkle proof paths:

Script0 (Hash Lock) — Complete TXID

TXID: 1ba4835fca1c94e7eb0016ce37c6de2545d07d84a97436f8db999f33a6fd6845

c050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d363cb9e4776a1cbb195c5cf0cbdbb3110d308969353680e38ec5f446336b60defda55197526f26fa309563b7a3551ca945c046e5b7ada957e59160d4d27f299e3

Key Fields:

🟡 Sibling Hash: 63cb9e47... (Script1's hash, because Script0 needs Script1 as sibling)
🟢 Branch Hash: da551975... (Branch1 hash, same as Script1)

Script2 (CSV Timelock) — Complete TXID

TXID: 98361ab2c19aa0063f7572cfd0f66cb890b403d2dd12029426613b40d17f41ee

c050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d32faaa677cb6ad6a74bf7025e4cd03d2a82c7fb8e3c277916d7751078105cf9dfd6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

Field Breakdown:

🟡 Sibling Hash: 593d543a...1fb61d8e4b9 (Script3's hash!)
🟢 Branch Hash: d6ac4c01...779960d1210 (Branch0 hash!)

Script2’s Proof Path: Script2 → Branch1 → Root

Needs Script3 hash as sibling to reconstruct Branch1
Needs Branch0 hash to reconstruct Root

Script3 (Simple Signature) — Complete TXID

TXID: 1af46d4c71e121783c3c7195f4b45025a1f38b73fc8898d2546fc33b4c6c71b9

c050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3593d543a01c2c3c16c950ed97dfb3f3a1025b4b66323ed6b2814a1fb61d8e4b9d6ac4c0133faaf95feb8e5656367d882f250e23b3295cafcbc465779960d1210

Field Breakdown:

🟡 Sibling Hash: 593d543a...1fb61d8e4b9 (Script2's hash)
🟢 Branch Hash: d6ac4c01...779960d1210 (Branch0 hash)

Script3’s Proof Path: Script3 → Branch1 → Root

Needs Script2 hash as sibling to reconstruct Branch1
Needs Branch0 hash to reconstruct Root

Control Block Pattern Summary

Script Tree Position Sibling Hash Branch Hash Proof Path Script0 Branch0 left Script1 hash Branch1 hash Script0→Branch0→Root Script1 Branch0 right Script0 hash Branch1 hash Script1→Branch0→Root Script2 Branch1 left Script3 hash Branch0 hash Script2→Branch1→Root Script3 Branch1 right Script2 hash Branch0 hash Script3→Branch1→Root

Key Insights:

Same-branch scripts: Are sibling nodes to each other (Script0↔Script1, Script2↔Script3)
Cross-branch proof: Requires hash of entire opposite branch
Proof minimization: Each Control Block contains only minimum information needed to reconstruct Root

Script1 Multisig Stack Execution Deep Analysis

Since we have cryptographically verified that Script1 is indeed in this Taproot address, now let’s deeply analyze its execution process in the Bitcoin virtual machine.

Complete Script1 Bytecode Analysis

Raw Bytecode (71 bytes):

002050be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3ba2084b5951609b76619a1ce7f48977b4312ebe226987166ef044bfb374ceef63af5ba5287

Byte-level Breakdown:

00                    OP_0 (initialize counter)
20                    OP_PUSHBYTES_32 (push 32 bytes)
50be5fc4...26bb4d3   Alice's x-only public key (32 bytes)
ba                    OP_CHECKSIGADD (verify signature and increment counter)
20                    OP_PUSHBYTES_32 (push 32 bytes)  
84b59516...eef63af5  Bob's x-only public key (32 bytes)
ba                    OP_CHECKSIGADD (verify signature and increment counter)
52                    OP_2 (push number 2)
87                    OP_EQUAL (check equality)

This is the standard Tapscript 2-of-2 multisig pattern, using the efficient OP_CHECKSIGADD opcode introduced in BIP 342.

Witness Data Structure and Consumption Order

Transaction ID: 1951a3be0f05df377b1789223f6da66ed39c781aaf39ace0bf98c3beb7e604a1

Pre-execution Preparation

Control Block Verification: Script1 is indeed in Merkle Root ✅

Stage 0: Witness Data Pushed onto Execution Stack

Bob signature enters stack first:

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │         Bob Signature       │ │ ← Stack bottom
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Alice signature enters stack second:

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │        Alice Signature      │ │ ← Stack top
│ ├─────────────────────────────┤ │
│ │         Bob Signature       │ │ ← Stack bottom
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

witness[0] = Bob signature (enters stack first)
witness[1] = Alice signature (enters stack second)

Detailed Witness Data:

[0] Bob Signature (64 bytes):
    31fa0ca7929dac01b908349326183dd7a0f752475d42f11dc2cd0075110ca2a4c
    255f3e310dfc0800e69609c872254241dcf827847e5b64821cefa6c6db575bc

[1] Alice Signature (64 bytes):
    22272de665b998668ae9e97cb72d9814d362ae101ee878caee04da0d2a7efb14
    e8bcdd7eb8082fad30864ec7f22bce6fb2d2178764a0b2f5427346e4b5821fa0

Script1 Execution Process

Script1 Bytecode Breakdown:

OP_0 → OP_PUSHBYTES_32(Alice pubkey) → OP_CHECKSIGADD → 
OP_PUSHBYTES_32(Bob pubkey) → OP_CHECKSIGADD → OP_2 → OP_EQUAL

Step 1: OP_0

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │             0               │ │ ← Newly pushed
│ ├─────────────────────────────┤ │
│ │        Alice Signature      │ │
│ ├─────────────────────────────┤ │
│ │         Bob Signature       │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 2: OP_PUSHBYTES_32 (Alice Public Key)

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │        Alice_PubKey         │ │ ← Newly pushed
│ │    50be5fc4...126bb4d3       │ │
│ ├─────────────────────────────┤ │
│ │             0               │ │
│ ├─────────────────────────────┤ │
│ │        Alice Signature      │ │
│ ├─────────────────────────────┤ │
│ │         Bob Signature       │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 3: OP_CHECKSIGADD (Verify Alice)

Pop Alice public key, consume Alice signature, push 1 after verification

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │             1               │ │ ← Verification successful
│ ├─────────────────────────────┤ │
│ │   ❌Alice Signature(consumed)│ │
│ ├─────────────────────────────┤ │
│ │         Bob Signature       │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 4: OP_PUSHBYTES_32 (Bob Public Key)

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │         Bob_PubKey          │ │ ← Newly pushed
│ │    84b59516...eef63af5       │ │
│ ├─────────────────────────────┤ │
│ │             1               │ │
│ ├─────────────────────────────┤ │
│ │   ❌Alice Signature(consumed)│ │
│ ├─────────────────────────────┤ │
│ │         Bob Signature       │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 5: OP_CHECKSIGADD (Verify Bob)

Pop Bob public key, consume Bob signature, push 2 after verification

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │             2               │ │ ← Verification successful
│ ├─────────────────────────────┤ │
│ │   ❌Alice Signature(consumed)│ │
│ ├─────────────────────────────┤ │
│ │   ❌Bob Signature(consumed)  │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 6: OP_2

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │             2               │ │ ← Newly pushed (required count)
│ ├─────────────────────────────┤ │
│ │             2               │ │ ← Actual count
│ ├─────────────────────────────┤ │
│ │   ❌Alice Signature(consumed)│ │
│ ├─────────────────────────────┤ │
│ │   ❌Bob Signature(consumed)  │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Step 7: OP_EQUAL

Pop both 2s for comparison, push TRUE

┌─────────────────────────────────┐
│         Execution Stack          │
├─────────────────────────────────┤
│ ┌─────────────────────────────┐ │
│ │            TRUE             │ │ ← Comparison result
│ ├─────────────────────────────┤ │
│ │   ❌Alice Signature(consumed)│ │
│ ├─────────────────────────────┤ │
│ │   ❌Bob Signature(consumed)  │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Key Insights

Execution Order:

Bob signature enters stack first (witness[0])
Alice signature enters stack second (witness[1])
Script processes in Alice→Bob order, but Alice signature at stack top is consumed first
This perfectly explains the witness array index relationship

LIFO Consumption Logic:

Stack entry order: Bob → Alice
Consumption order: Alice → Bob (last in, first out)
Script execution order: Alice pubkey → Alice signature consumption → Bob pubkey → Bob signature consumption

Summary: Complete Cryptographic Loop of Taproot Mechanism

Through this in-depth analysis, we have completely verified Taproot’s cryptographic mechanisms:

1. Merkle Tree Construction

Use TaggedHash to build collision-resistant hash trees
TapLeaf hashes commit individual scripts
TapBranch hashes combine subtrees
Final Root commits the entire script set

2. Control Block Interpretation

🔴 Version Field: Specifies script version and coordinate parity
🔵 Internal Public Key: Provides key commitment
🟡🟢 Merkle Proof: Provides minimized inclusion proof path

3. Real Data Verification

Reconstruct complete Merkle Root from Control Block
Verify Root’s correspondence to address through Tweak mechanism
Prove specific script is indeed committed in Taproot address

4. Script Stack Execution

LIFO consumption mechanism of witness data
Efficient signature verification in Tapscript
Stack state changes of multisig logic

This is Taproot’s complete cryptographic loop — from script commitment to Merkle proof, from address generation to stack execution, every step embodies sophisticated cryptographic design.

Looking Forward to Part 3

In Part 3, we will build an interactive visualization tool that allows readers to:

Adjust script content in real-time and observe Merkle tree changes
Simulate different Control Block constructions
Compare costs and privacy characteristics of various spending paths
Explore unbalanced trees and optimization strategies

Stay tuned for this visual feast of Taproot technology!

This article is part of the “Not Just HODLing: Real Bitcoin Script Engineering” series. Previous articles covered [*CSV timelocks with P2SH](https://medium.com/@aaron.recompile/how-i-built-a-time-locked-bitcoin-script-with-csv-and-p2sh-c48c0389709d) and [*basic Taproot implementation](https://medium.com/@aaron.recompile/a-guide-to-creating-taproot-scripts-with-python-bitcoinutils-e088633bc2a7)*.*

By Aaron Recompile on July 7, 2025.

Canonical link

Exported from Medium on July 3, 2026.

SIGHASH_ANYPREVOUT on Signet: When Signatures Stop Binding to UTXOs

aaron.recompile — Fri, 03 Jul 2026 02:47:54 +0000

Standard CHECKSIG asks: did you sign for *this UTXO*?

ANYPREVOUT asks: did you sign for *this kind of UTXO*?

A signature normally says: “I authorize spending this exact coin.”
ANYPREVOUT says: “I authorize spending any coin that looks like this.”

Same Schnorr math. Different preimage.

Bitcoin is not designed top-down.  
It is discovered through execution.

"Run the Future" — starts here.

TL;DR — Same private key, same tapscript leaf (<0x01||xonly> OP_CHECKSIG, 35 bytes), two different UTXOs. Sign once, copy the witness verbatim onto the second transaction — no re-signing. Both pass Inquisition consensus validation and confirm in the same block. The mechanism: BIP 118’s sighash preimage omits sha_prevouts, so the outpoint vanishes from the digest. The signature binds not to “which UTXO” but to “what shape of UTXO.”

1. What Signatures Actually Are, and How Bitcoin Uses Them

Schnorr signatures (BIP 340) have nothing inherently to do with Bitcoin. They simply sign a message:

sig = Sign(privkey, message)
Verify(pubkey, message, sig) → true / false

message can be anything — a text string, a file hash, a chat message. A signature proves: the holder of this private key endorsed this message. No relation to transactions whatsoever.

Bitcoin took this general-purpose tool and did something specific: it dictated what the message must be.

When a script executes OP_CHECKSIG, the node does not let you pass in your own message. It automatically assembles a byte string from the current transaction’s fields — input sources, output destinations, amounts, timelocks — called the sighash preimage, then hashes it to produce a 32-byte digest. This digest is the message being signed.

General signing:  you choose the message → sign → verify
CHECKSIG:         consensus rules choose the message → you just sign → node rebuilds the message to verify

So CHECKSIG is not just “verify a signature” — it turns signatures from general authorization into transaction authorization. You are not signing “I agree.” You are signing “I agree to spend this money, from here, to there.” The strength of the signature depends on which fields are stuffed into the sighash preimage.

Where sighash comes from

The sighash mechanism has evolved through several generations:

Legacy (pre-SegWit): Serializes the entire transaction, strips different parts depending on sighash type, double SHA256. The infamous O(n²) problem originated here.
BIP 143 (SegWit v0): Redesigned the preimage format — SHA256 prevouts, sequences, and outputs once each, then plug those 32-byte hashes into the preimage. Solved O(n²).
BIP 341 / 342 (Taproot / Tapscript): Built on BIP 143 with TaggedHash("TapSighash", ...) for domain separation, added spend_type, tapleaf_hash, key_version, and other fields.

Every generation adjusts the same question: which fields go into the sighash preimage? More fields means tighter binding; fewer fields means more flexibility.

Sighash type: choosing how much to bind

Even within the same sighash generation, the signer can choose which fields to bind via sighash type. The standard options:

sighash typeBinds all inputsBinds all outputsSIGHASH_ALL (0x01)YesYesSIGHASH_NONE (0x02)Yes*NoSIGHASH_SINGLE (0x03)YesSame-index output onlySIGHASH_ANYONECANPAY (0x80, combinable)Current input only*Depends on the above three

These all operate on the output side — relaxing “where the money goes.” But they share one invariant: the input side never relaxes. The input you sign is permanently bound to a specific txid:vout. Once signed, that signature can only spend that one UTXO. Swap it, and the signature fails.

This is exactly what BIP 118 changes.

What problem BIP 118 solves

Scenario: you and a counterparty opened a Lightning channel and went through 100 state updates. The counterparty cheats by broadcasting the old state from round 50. You need your round-100 update transaction to override it.

But your round-100 update transaction was signed during round 100 — at that time you had no idea whether the counterparty would broadcast round 50, let alone what txid round 50 would have on-chain. Under standard CHECKSIG, the signature is bound to the prevout’s txid:vout. You cannot pre-sign a “spend any future old state” transaction.

BIP 118 (SIGHASH_ANYPREVOUT) solves this: remove **`sha_prevouts*`* from the sighash preimage.** The signature no longer binds to a specific outpoint. As long as the UTXO’s amount and script match, the same signature works. You can pre-sign at round 100 a transaction that spends “any shape-matching old state” — whether the counterparty broadcasts round 50 or round 73.

This is the foundation of Eltoo / LN-Symmetry.

2. SigMsg vs Msg118: What Exactly Was Removed

Standard Tapscript (BIP 342) SigMsg assembles these fields:

SigMsg = hash_type
       || nVersion || nLocktime
       || sha_prevouts          ← SHA256(txid₁||vout₁ || txid₂||vout₂ || ...)
       || sha_amounts           ← SHA256(amount₁ || amount₂ || ...)
       || sha_scriptpubkeys     ← SHA256(spk₁ || spk₂ || ...)
       || sha_sequences         ← SHA256(seq₁ || seq₂ || ...)
       || sha_outputs           ← SHA256(all outputs)
       || spend_type
       || input_amount          ← current input's amount
       || input_scriptpubkey    ← current input's scriptPubKey
       || input_index
       || ...

sha_prevouts hashes every input’s txid:vout into the digest. Change one prevout, the hash changes, the digest changes, signature verification fails. This is the “bind to UTXO” mechanism — not some abstract design, but a line of bytes in the preimage.

BIP 118’s Msg118 removes these fields:

Note the subtlety: BIP 342 includes both the global sha_amounts (hash of all input amounts) and the per-input input_amount. BIP 118 keeps only the latter — if the global were retained, you would still indirectly bind to other inputs’ information.

Result: the digest contains no information about which outpoint is being spent. As long as the new UTXO has the same amount and same scriptPubKey, Msg118 produces the identical byte string, the identical digest, and signature verification passes.

3. Three Tiers of Sighash: Package Pickup

BIP 118 defines two new sighash flags. Together with standard BIP 342, there are three tiers:

Package pickup analogy:

Standard CHECKSIG (0x01): The pickup slip says “collect package YT1234567890.” Only that one package — the signature is valid only for that tracking number.
ANYPREVOUT (0x41): The pickup slip says “collect any 5 kg package addressed to Zhang San.” Three qualifying packages at the station — this slip works for any of them. But it must be 5 kg, addressed to Zhang San.
ANYPREVOUTANYSCRIPT (0xC1): The pickup slip just says “Zhang San is here to pick up.” Any package will do, regardless of weight or sender, as long as the station accepts Zhang San’s ID.

This experiment uses 0x41 (the middle tier), which is also the tier Eltoo / LN-Symmetry actually needs.

4. How the Node Switches: the 0x01 Public Key Prefix

Standard tapscript uses 32-byte x-only public keys. BIP 118 stipulates: if the public key in a tapscript is 33 bytes and the first byte is **`0x01**, the node uses BIP 118’s Msg118 + Ext118 to compute the digest when executing OP_CHECKSIG, instead of standard BIP 342’s SigMsg`.

Standard tapscript:  <32-byte xonly pubkey> OP_CHECKSIG   → uses BIP 342 SigMsg
BIP 118:             <0x01 || 32-byte xonly pubkey> OP_CHECKSIG → uses Msg118 + Ext118

This is an opt-in mechanism — it does not affect any existing tapscript. Only when you explicitly use a 0x01-prefixed public key does BIP 118 sighash logic activate.

Additionally, key_version = 0x01 in Ext118 (BIP 342 uses 0x00) isolates the sighash domain: even if the public key bytes are identical, a BIP 118 signature cannot replay on a standard BIP 342 key. The two worlds do not interfere.

5. Commit Phase: Building an APO-only P2TR Address with btcaaron

key = Key.from_wif(DEMO_KEY_WIF)

program = (
    TapTree(internal_key=key, network="signet")
    .bip118_checksig(key, label="apo_rebind")
    .build()
)
addr = program.address

btcaaron API Walkthrough

**.bip118_checksig(key, label="apo_rebind")** is a convenience wrapper around .custom(). It is equivalent to:

apo_pk = apo_pubkey_bytes(key.xonly_bytes)   # 0x01 || xonly (33 bytes)
leaf_script = RawScript(build_script(push_bytes(apo_pk), OP_CHECKSIG))

program = (
    TapTree(internal_key=key, network="signet")
    .custom(script=leaf_script, label="apo_rebind")
).build()

The leaf script is:

<0x01 || xonly_pubkey> OP_CHECKSIG

35 bytes (OP_PUSHBYTES_33 1 byte + 0x01||xonly 33 bytes + OP_CHECKSIG 1 byte). The 0x01 prefix tells the Inquisition node to use BIP 118 sighash. apo_pubkey_bytes() prepends the 0x01 byte to the x-only public key. The subsequent .build() → .spend() → .sign() / .unlock_with() flow is identical to all prior experiments.

Tapscript bytecode:

21                                                                <- OP_PUSHBYTES_33
01ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8  <- 0x01 || xonly pubkey
ac                                                                <- OP_CHECKSIG

Funding Two Identical UTXOs

txid1 = wallet_send_sats(rpc_wallet, addr, 50_000)
txid2 = wallet_send_sats(rpc_wallet, addr, 50_000)

Two independent wallet transfers, 50,000 sats each, sent to the same P2TR address. Two UTXOs with the same amount and scriptPubKey, but different txids.

6. Reveal Phase: Sign Once, Spend Twice

# Sign the first UTXO normally
tx1 = (
    program.spend("apo_rebind")
    .from_utxo(u1_txid, u1_vout, sats=50_000)
    .to(change_addr, 47_000)
    .sign(key)          # ← internally calls key.sign_taproot_script_bip118()
    .build()
)

# Extract the witness stack
stack = tx1._tx.witnesses[0].stack   # [sig, leaf_script, control_block]
# Attach the same witness to the second transaction - no re-signing
tx2 = (
    program.spend("apo_rebind")
    .from_utxo(u2_txid, u2_vout, sats=50_000)
    .to(change_addr, 47_000)
    .unlock_with([stack[0].hex(), stack[1].hex(), stack[2].hex()])
    .build()
)
out1 = broadcast_or_raise(tx1.hex)
out2 = broadcast_or_raise(tx2.hex)

btcaaron Signing API Walkthrough

**.sign(key)**, upon detecting that the current leaf uses a BIP 118 public key, internally calls:

key.sign_taproot_script_bip118(
    tx, txin_index=0,
    utxo_scripts=[scriptPubKey],
    amounts=[50_000],
    tapleaf_script=leaf,
    hash_type=0x41,      # SIGHASH_ALL | SIGHASH_ANYPREVOUT
)

This method calls bip118_sighash() to construct Msg118 || Ext118, computes TaggedHash("TapSighash", 0x00 || msg || ext) to get a 32-byte digest, then produces a BIP 340 Schnorr signature, appends sighash byte 0x41, returning 65 bytes (130 hex chars).

**.unlock_with([sig, leaf, cb])** does not sign — it directly uses the three provided hex strings as the witness stack. Because Msg118 does not contain the outpoint, the witness from the first spend is equally valid on the second.

7. Transaction Structure and On-chain Evidence

Funding: Two Independent Wallet Transfers

TxIDAmountFunding A[4b64…344a](https://mempool.space/signet/tx/4b6451082fe4349fdb2acad6bf0964c6cfd8c9cbf5161806fc342b051dee344a?showDetails=true)50,000 satsFunding B[543c…a5eb](https://mempool.space/signet/tx/543c97f777ea04624392f6a1547146d6e98996b38aec0794f6b79e3275f6a5eb?showDetails=true)50,000 sats

Both pay to: tb1prpa4a7wc0v5ghesn8pqhz7uw6lccd5u52rgzcfdqv3kwd3ptapcqnt93g2

Reveal: The Rebinding Pair

TxIDPrevoutOutputSpend A (signed)[03c0…f3a4](https://mempool.space/signet/tx/03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4?showDetails=true)4b64…344a:047,000 satsSpend B (reused witness)[4609…1a43](https://mempool.space/signet/tx/46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43?showDetails=true)543c…a5eb:047,000 sats

Both confirmed in Inquisition signet block 298,280. 3,000 sats fee.

Witness Comparison

Decoding both spend transactions on mempool.space, the witness stacks are byte-for-byte identical:

Witness[0] = 902004a5...b5fa04064bdc41   <- Schnorr signature + sighash byte 0x41 (65 bytes)
Witness[1] = 2101ff1f...9986b8ac         <- tapscript (35 bytes)
Witness[2] = c1ff1f9fa3...9986b8         <- control block (33 bytes)

Witness[0]: 64-byte Schnorr signature with 0x41 (SIGHASH_ALL | SIGHASH_ANYPREVOUT) appended, totaling 65 bytes.

Witness[1]: 21 (OP_PUSHBYTES_33) + 01||xonly_pubkey (33 bytes) + ac (OP_CHECKSIG) = 35 bytes. The BIP 118 leaf script.

Witness[2]: Control block starts with c1. c1 = leaf version 0xc0 + parity bit 1. The parity bit is determined by the Y-coordinate parity of the output key Q after TapTweak computation — c0 for even, c1 for odd; it cannot be chosen in advance. Followed by 32-byte internal public key, totaling 33 bytes.

Different inputs, same witness, both confirmed. This is rebinding.

Negative Test

Modifying Spend B’s output address or amount causes script verification failure. sha_outputs remains in Msg118 (SIGHASH_ALL mode) — the signature commits to where the money goes. Rebinding lets you swap the input, not the destination.

8. Rebuilding the Address with RootScope

The tapscript is 35 bytes: OP_PUSHBYTES_33 (0x21) + 0x01||xonly_pubkey (33 bytes) + OP_CHECKSIG (0xac). The derivation chain is identical to the single-leaf TapTree used in all prior experiments.

Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || compact_size(35) || script_bytes)
               (leaf version 0xc0, script length 35, script = 21 01||xonly ac)
Merkle root  = TapLeaf hash
Tweak t      = tagged_hash("TapTweak",  internal_pubkey || Merkle root)
Output key Q = internal_pubkey + t*G
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

internal_pubkey = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
script_bytes = bytes.fromhex(
    "2101ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8ac"
)

tapleaf_hash = tagged_hash(
    "TapLeaf",
    # compact_size(35) = 0x23, single byte since 35 < 253
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1prpa4a7wc0v5ghesn8pqhz7uw6lccd5u52rgzcfdqv3kwd3ptapcqnt93g2  [OK]

RootScope Visualization

Internal key
  ff1f9fa3...9986b8
        |
    TapLeaf (0xc0)
    Script: 2101<01||xonly>ac  (35 bytes)
                 ^--- 0x01 prefix triggers BIP 118 sighash
        |
    TapLeaf hash
        |   (no sibling -> single-leaf tree)
    Merkle root
        |
    TapTweak
        |
    Output key Q  (parity: odd -> control block byte = c1)
        |
    P2TR address
    tb1prpa4a7wc0v5ghesn8pqhz7uw6lccd5u52rgzcfdqv3kwd3ptapcqnt93g2  [OK]

The control block starts with c1 — the same odd-parity result as the IK+CSFS experiment, but for a different reason: this 35-byte BIP 118 script produces a different TapLeaf hash, and after tweaking, the output key Q’s Y-coordinate happens to be odd. Same internal_pubkey (ff1f9fa3...9986b8) as all prior experiments, different tapscript, different Merkle root, different TapTweak, different address.

9. Cross-validation: Two Independent Implementations Agree on One Spec

Two confirmed transactions mean two independent implementations agreed on the digest:

Signing side (Python, btcaaron/bip118.py): constructs Msg118 || Ext118, TaggedHash("TapSighash", ...), BIP 340 signature
Validation side (C++, Bitcoin Inquisition): reconstructs the same digest from the transaction, verifies the Schnorr signature

Bitcoin Core’s wallet and CLI do not support constructing BIP 118 signatures — there is no signrawtransaction --sighash=anyprevout. Signing must be done externally. btcaaron/bip118.py is a Python implementation independent of Core’s test framework, building Msg118 / Ext118 byte assembly from the BIP 118 specification.

On-chain confirmation is the strictest test: if my implementation and Inquisition’s C++ disagree on any byte, the transaction gets rejected.

10. Why This Matters for Eltoo

ANYPREVOUT is the infrastructure for Eltoo (LN-Symmetry). In Eltoo, channel state update transactions need to be able to spend any prior state’s UTXO:

Counterparty cheats by broadcasting old State v2 (txid: aaaa...)
You need your State v5 update transaction to override it
But State v5 was pre-signed during round 5 — you didn't know State v2 would ever go on-chain

0x41 makes this possible: when pre-signing, you don’t need to know the txid — just that the amount and scriptPubKey match. Because all rounds’ state UTXOs share the same “lock” (same amount + same script), the signature you pre-signed works against any round.

Building on this signing code, I also ran a three-round Eltoo-style state chain (APO updates + CTV settlement), with all six transactions confirmed on the same signet — details at the BIP 118 implementation post on Delving Bitcoin and the Braidpool covenant challenge reply.

Series Position

What We Did

We ran an on-chain BIP 118 SIGHASH_ANYPREVOUT experiment: a 35-byte tapscript (<0x01||xonly> OP_CHECKSIG), two UTXOs with the same amount and scriptPubKey. After signing the first UTXO, we copied the full witness — 65-byte Schnorr signature (sighash byte 0x41), 35-byte leaf script, 33-byte control block — verbatim onto the second transaction. No re-signing. Both broadcast, both confirmed in Inquisition signet block 298,280.

Signing was done with btcaaron’s Key.sign_taproot_script_bip118(), which internally calls the independently implemented Msg118 / Ext118 / TaggedHash("TapSighash", ...) construction in bip118.py. This is a Python implementation independent of Bitcoin Core’s test framework — on-chain confirmation means it agrees byte-for-byte with Inquisition’s C++ consensus engine on the BIP 118 specification.

Negative testing confirmed the boundary: modifying the second transaction’s output address or amount causes script verification failure. Under SIGHASH_ALL, sha_outputs remains in Msg118. Rebinding relaxes “which UTXO to spend,” not “where the money goes.”

References

BIP 118 specification: github.com/bitcoin/bips/bip-0118
btcaaron toolkit: github.com/aaron-recompile/btcaaron
BIP 118 sighash implementation: [btcaaron/bip118.py](https://github.com/aaron-recompile/btcaaron/blob/main/btcaaron/bip118.py)
Rebinding demo script: [examples/braidpool/rca_taptree_smoke.py](https://github.com/aaron-recompile/btcaaron/blob/main/examples/braidpool/rca_taptree_smoke.py)
Bitcoin Inquisition: github.com/bitcoin-inquisition
RootScope visualization tool: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition 29.2 | Funding *[*4b64…344a*](https://mempool.space/signet/tx/4b6451082fe4349fdb2acad6bf0964c6cfd8c9cbf5161806fc342b051dee344a?showDetails=true) [*543c…a5eb*](https://mempool.space/signet/tx/543c97f777ea04624392f6a1547146d6e98996b38aec0794f6b79e3275f6a5eb?showDetails=true) | Spend A [*03c0…f3a4*](https://mempool.space/signet/tx/03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4?showDetails=true) | Spend B [*4609…1a43*](https://mempool.space/signet/tx/46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43?showDetails=true) | Confirmed in block 298,280*

By Aaron Recompile on April 11, 2026.

Canonical link

Exported from Medium on July 3, 2026.

RootScope: A Tool for Reconstructing Taproot Script Paths — Step by Step

aaron.recompile — Fri, 03 Jul 2026 02:47:53 +0000

When you spend from a Taproot script path, the hash chain is deterministic. Reconstructing it by hand is a trap.

Taproot is elegant on paper. Spend from a script path, and the witness contains everything needed to prove your script was committed: the script itself, the control block, and the Merkle path up to the root. The math is clean.

The problem is inspection.

Given a real transaction, try to manually verify that the reconstructed Merkle root matches the output key. You’ll need to:

Parse the control block byte by byte
Compute TaggedHash("TapLeaf", version || compact_size(len) || script)
Walk the sibling hashes in the control block up to the root
Compute TaggedHash("TapTweak", internal_pubkey || root)
Do the elliptic curve point addition on secp256k1
Bech32m-encode the result
Check that it matches the output address

Miss one step — wrong hash tag, wrong byte order, parity bit ignored — and you get a silent mismatch. No error message. Just a wrong address.

I built RootScope to do this deterministically and show every step.

What RootScope Does

Given a script and control block, RootScope computes the complete reconstruction chain:

TapLeaf hash
  → TapBranch step 1
  → TapBranch step 2
  → ...
  → Merkle root
  → TapTweak
  → tweaked output key
  → bech32m address
  → ✓ matches expected address (optional check)

Each intermediate value is shown. Nothing is hidden.

There’s also a fetch-witness helper: give it a txid + vin, and it resolves the witness from a block explorer and prefills the inputs. No manual hex-copying from a mempool explorer.

Repo: github.com/aaron-recompile/rootscope

The Hash Chain, Concretely

BIP 341 defines three tagged hashes used in Taproot construction:

TapLeaf:

TapLeaf_hash = TaggedHash("TapLeaf", leafVersion || compact_size(len) || script)

TapBranch (each step up the Merkle path):

TapBranch_hash = TaggedHash("TapBranch", left || right)

where left and right are the lexicographically-sorted pair — the control block provides sibling hashes in order, so sorting happens at construction time.

TapTweak:

tweak = TaggedHash("TapTweak", internal_pubkey || merkle_root)
taproot_pubkey = lift_x(internal_pubkey) + tweak × G

The final output key is the x-coordinate of that point. Parity check against the control block’s low bit completes the verification.

RootScope implements all of this in pure Python — hashlib only, no external crypto libraries. crypto.py re-implements tagged_hash, secp256k1 lift_x, point_add, point_mul, and bech32m_encode/decode from scratch. Every function is independently testable.

Validation

Before touching mainnet data, I ran the full BIP 341 test vectors.

wallet-test-vectors.json contains 6 test cases with 12 distinct script-path spending paths — including unbalanced trees (case 3) and mixed-depth paths (cases 5 and 6). All 12 pass:

$ make bip341-vectors
Running BIP341 test vectors...
 [PASS] Case 1 - path 0/0
 [PASS] Case 1 - path 0/1
 [PASS] Case 2 - path 0/0
 ...
 [PASS] Case 6 - path 0/1/0


12 / 12 PASS

Additional vectors from Mastering Taproot cover single-leaf, dual-leaf (balanced), and the first documented 4-leaf Taproot tree — including the full unbalanced variant from Chapter 8.

Control block guard checks:

(len - 33) % 32 == 0 — control block length must be valid
depth ≤ 128 — as specified in BIP 341
output-key parity check against the version & 0x01 bit

Quick repro:

git clone https://github.com/aaron-recompile/rootscope
cd rootscope
python3 -m venv .venv && ./.venv/bin/python -m pip install -r backend/requirements.txt

make bip341-vectors
./.venv/bin/python -m backend.cli tx \
  f1de8d3b3894a7cc0efffa7332bf7236ad089195b9d642121f4844f13e01f1e0 \
  --vin 0 --network mainnet

The Deeper the Tree, the More the Control Block Reveals

Most mainnet script-path spends use single-leaf trees — 33-byte control blocks with no Merkle path at all. That’s the on-chain reality. But it’s not what Taproot was designed for. The interesting structures are in the Mastering Taproot book vectors and the BIP 341 test cases.

Depth progression: single-leaf to 4-leaf

The book’s three chapters correspond to three tree shapes. Control block length grows linearly with depth:

Chapter 06 — single leaf (depth=0)
control block = 1 + 32 = 33 bytes

internal_key
       │
     leaf_A  ← script here, no sibling hashes in control block
Chapter 07 - dual-leaf balanced (depth=1)
control block = 1 + 32 + 32 = 65 bytes


  internal_key
       │
    Branch
   ┌───┴───┐
 leaf_A  leaf_B  ← reveal A, control block carries hash of B
Chapter 08 - 4-leaf balanced (depth=2)
control block = 1 + 32 + 32 + 32 = 97 bytes


  internal_key
       │
      Root
   ┌───┴────┐
Branch0   Branch1
┌──┴──┐  ┌──┴──┐
S0   S1  S2   S3  ← reveal S1: control block carries [S0_hash, Branch1_hash]

Each additional depth level adds 32 bytes. Verification complexity is O(depth).

Unbalanced trees: two different proofs, same output address

This is the most counterintuitive part of Taproot’s design: different leaves in the same tree can have different control block depths, but all resolve to the same output address.

Unbalanced 3-leaf tree:

      Root
    ┌──┴──┐
  Branch  leaf_C  ← depth=1, control block carries Branch_hash
  ┌─┴─┐
leaf_A leaf_B     ← depth=2, control block carries [leaf_B_hash, leaf_C_hash]

Revealing leaf_A (depth=2):

control_block = version | parity
              + internal_pubkey       (32 bytes)
              + leaf_B_hash           (32 bytes, sibling)
              + leaf_C_hash           (32 bytes, sibling one level up)
total = 97 bytes

Revealing leaf_C (depth=1):

control_block = version | parity
              + internal_pubkey       (32 bytes)
              + Branch_AB_hash        (32 bytes, entire left subtree)
total = 65 bytes

Two paths, identical Merkle root, identical output address. RootScope reconstructs both correctly and produces consistent results.

BIP 341 Case 3: non-standard leaf version

Test case 3 in wallet-test-vectors.json includes a path with leaf version 0xfa — not the standard Tapscript 0xc0:

control_block = "faee4fe085983462a184015d1f782d6a5f8b9c2b..."
#                ^^
#                0xfa = non-standard leaf version, low bit = parity

The script for this path is the raw bytes 06424950333431 — ASCII "BIP341". From the perspective of address verification, the leaf version only affects the TapLeaf hash computation. TapBranch and TapTweak are unaffected. RootScope handles this correctly.

Open Questions

Depth distribution at scale. Does depth > 0 appear more often in protocol-specific spending — Lightning, RGB, covenant constructions? Are there real multi-leaf trees in the wild beyond ordinals infrastructure?
Template labeling. The current pipeline identifies templates by script structure. Automatic classification is possible but risks false positives. Is conservative, opt-in labeling better for a tool like this?
Dataset integration. Are there public datasets of script-path spends — academic datasets, mempool.space exports, or other tooling outputs — that would plug directly into the batch pipeline?

Repo: github.com/aaron-recompile/rootscope

By Aaron Recompile on March 9, 2026.

Canonical link

Exported from Medium on July 3, 2026.

OP_INTERNALKEY + OP_CHECKSIGFROMSTACK on Signet — Identity-Bound Authorization

aaron.recompile — Fri, 03 Jul 2026 02:47:51 +0000

Bitcoin is not designed top-down.  
It is discovered through execution.

"Run the Future" — starts here.

Pure CSFS asks: did someone sign this? IK + CSFS asks: did the *owner sign this?*

Bitcoin does not enforce identity declarations. It enforces authorization structures.

TL;DR — Two opcodes, two bytes (cbcc), zero pubkey in the witness. OP_INTERNALKEY pushes the UTXO's internal key from Taproot execution context; OP_CHECKSIGFROMSTACK verifies that the key holder signed the message. Authorization is bound to UTXO identity at creation time, not declared at spend time. One structural consequence: a fixed message is replayable across UTXOs with the same internal key — the next experiment (CAT+CSFS) closes that window.

The distinction matters more than it looks.

In the standalone CSFS experiment, the witness supplies three items: signature, message, and pubkey. Any pubkey can walk in. If you have a key that matches the sig-message pair, you pass. The script has no opinion about who that key belongs to.

OP_INTERNALKEY changes the question. It is a single opcode that pushes the x-only internal pubkey of the current Taproot context onto the stack. The script no longer accepts a key from the witness — it reads the key from the UTXO itself. The authorized signer is whoever created this specific UTXO, not whoever happens to have a matching key.

Combined as OP_INTERNALKEY OP_CHECKSIGFROMSTACK, two bytes, this produces an authorization primitive that is bound to a specific Taproot identity: the internal key holder must have signed the message. The witness shrinks from three items to two — signature and message only. The pubkey never appears in the witness. It arrives at runtime from the execution context.

This post runs the first combo experiment: cbcc on Signet, with a commit-reveal cycle through Bitcoin Inquisition 29.2. The witness is two items. The stack execution is three steps. Both transactions are confirmed.

Same verification primitive. Different binding surface.

Bitcoin changes when the binding surface changes.

The IK+CSFS Contract

Compare pure CSFS to the combo:

Pure CSFS (OP_CHECKSIGFROMSTACK):
  witness  = [sig, message, pubkey]
  script   = OP_CHECKSIGFROMSTACK
  pubkey source: witness (caller-supplied)


IK + CSFS (OP_INTERNALKEY OP_CHECKSIGFROMSTACK):
  witness  = [sig, message]
  script   = OP_INTERNALKEY OP_CHECKSIGFROMSTACK
  pubkey source: Taproot context (UTXO-bound)

In the IK+CSFS version, the pubkey is never in the witness. It is pushed by OP_INTERNALKEY from the validated Taproot execution context — the internal key used to construct the TapTree the spender is revealing.

This matters because of how the Taproot verifier works. When a script-path spend occurs, the control block in the witness carries the candidate internal key P and a Merkle path. The verifier reconstructs the output key Q' = P + tweak·G and checks Q' == Q against the UTXO. Only after this consistency check passes does OP_INTERNALKEY expose the validated P to the execution stack. There is no way to inject a different key through the witness.

The result: the signer identity is bound to this UTXO’s creation. The same two-byte script can be used in any TapTree — but each instance enforces a different authorized signer, because each instance has a different internal key.

The Contract Design

Signer offline:
  message = SHA256("authorized:group_combo_ik_csfs:v1")
           = c4820b82...313ebc
  sig     = Schnorr.sign(secret_key, message)
           = 5a5a5107...a1fdd37

At spend time, witness provides:
  Witness[0] = sig       (64 bytes)
  Witness[1] = message   (32 bytes)
Script (two bytes):
  0xcb = OP_INTERNALKEY           <- push internal key from Taproot context
  0xcc = OP_CHECKSIGFROMSTACK     <- verify sig(message, internal_key)

The tapscript bytecode:

cb   <- OP_INTERNALKEY
cc   <- OP_CHECKSIGFROMSTACK

Two bytes. No key in the script, no key in the witness. The authorized identity is implicit in the UTXO’s Taproot construction.

Commit Phase: Building the Taproot Address with btcaaron

MESSAGE = hashlib.sha256(b"authorized:group_combo_ik_csfs:v1").digest()

key = Key.from_wif(DEMO_KEY_WIF)
leaf_script = RawScript(build_script(OP_INTERNALKEY, OP_CHECKSIGFROMSTACK))
program = (
    TapTree(internal_key=key, network="signet")
    .custom(script=leaf_script, label="ik_csfs")
).build()
addr = program.address

btcaaron API Highlights

**build_script(OP_INTERNALKEY, OP_CHECKSIGFROMSTACK)** assembles the two-byte tapscript cbcc. Both opcodes are imported from experiments.opcodes as raw bytes — they are proposed opcodes, not standard btcaaron primitives, so they live in the experiment layer rather than the library.

**TapTree(...).custom(script, label).build()** derives the P2TR address via the same TapLeaf → Merkle root → TapTweak → output key chain as all previous experiments. Two-byte script, same derivation depth as any other single-leaf tree.

Funding the Address

txid = fund_address(addr, FUND_TXID_FILE, fund_sats=50_000)

Reveal Phase: Spending with Sig and Message Only

The witness is two items. No pubkey.

def _make_witness():
    secret = wif_secret_bytes(DEMO_KEY_WIF)
    sk = PrivateKey(secret, raw=True)
    sig = sk.schnorr_sign(MESSAGE, "", raw=True)
    return [sig.hex(), MESSAGE.hex()]

tx = (
    program.spend("ik_csfs")
    .from_utxo(txid, vout, sats=sats)
    .to(change_addr, sats - fee_sats)
    .unlock_with(_make_witness())
    .build()
)
reveal_txid = broadcast_or_raise(tx.hex)

btcaaron Spend API

**_make_witness()** returns [sig, message] in that order. sig is pushed first (lands at stack bottom), message is pushed second (lands at stack top). No pubkey item — OP_INTERNALKEY will supply it at runtime.

**pk.schnorr_sign(MESSAGE, "", raw=True)** signs the 32-byte digest using BIP340 Schnorr with a deterministic nonce.

The final witness layout:

Witness[0] = 5a5a5107...a1fdd37    <- Schnorr sig (64 bytes)
Witness[1] = c4820b82...313ebc     <- message = SHA256("authorized:...") (32 bytes)
Witness[2] = cbcc                  <- tapscript (OP_INTERNALKEY OP_CHECKSIGFROMSTACK, 2 bytes)
Witness[3] = c1ff1f9fa3...9986b8   <- control block (33 bytes)

Transactions, OP_RETURN_203 + OP_RETURN_204, and Stack Trace

Commit: what lands on-chain

TxID: [9930e922...0ea8](https://mempool.space/signet/tx/9930e922036a80d04a96a4b08f15838bcb880ce2a4be91da0b24af1484e10ea8?showDetails=true)

OUTPUTS (relevant)
  tb1p...    0.00050000 sBTC  <- IK+CSFS lock UTXO

Standard P2TR output. Nothing about the two-byte script is visible externally.

Reveal: what lands on-chain

TxID: [8d0b2156...dd8f](https://mempool.space/signet/tx/8d0b2156e9425afe64cabf3c906da255b6b86c51cb8968f828d5253fc261dd8f?showDetails=true)

Fee        : 500 sats
Features   : SegWit | Taproot | RBF

INPUT
  (IK+CSFS lock UTXO)    0.00050000 sBTC
OUTPUT
  (change address)       0.00049500 sBTC  (V1_P2TR)

The witness as shown by mempool.space:

Witness[0]  5a5a5107...a1fdd37
            <- Schnorr sig (64 bytes)

Witness[1]  c4820b82...313ebc
            <- SHA256("authorized:group_combo_ik_csfs:v1") (32 bytes)
Witness[2]  cbcc
            <- tapscript
Witness[3]  c1 ff1f9fa3...9986b8
            <- control block (leaf version 0xc0 + parity 1 + internal pubkey)

P2TR tapscript decoded:

OP_RETURN_203
OP_RETURN_204

The OP_RETURN_203 + OP_RETURN_204 labels — and what they actually mean

(Readers familiar with the OP_SUCCESS soft fork upgrade pattern can skip this section.)

0xcb = 203 decimal. 0xcc = 204 decimal. Both fall in BIP342's OP_SUCCESS range (opcodes 187–254 are OP_SUCCESS in Tapscript). On standard nodes, any OP_SUCCESS opcode causes the tapscript to pass immediately without evaluating anything further. On Bitcoin Inquisition 29.2, 0xcb executes as OP_INTERNALKEY and 0xcc as OP_CHECKSIGFROMSTACK.

mempool.space, running standard software, labels both as OP_RETURN_203 and OP_RETURN_204 — its naming convention for unrecognized opcodes, not OP_RETURN the data-embedding opcode. When two OP_SUCCESS opcodes appear in the same script, a non-upgraded node passes on the first one without reaching the second. Inquisition nodes execute both sequentially in full.

This is the same soft fork upgrade mechanism as the standalone CSFS experiment. The new rules turn “always pass” opcodes into real constraints; old nodes see OP_SUCCESS and accept the block because they have no rule to reject it.

Stack execution

Executing: OP_INTERNALKEY OP_CHECKSIGFROMSTACK

The Taproot interpreter strips Witness2 and Witness3, loading Witness[0..1] as the initial execution stack.

Initial State: two witness items loaded as execution stack

+--------------------------------------------+
| c4820b82...313ebc                          |  <- message  (Witness[1], top)
| 5a5a5107...a1fdd37                         |  <- sig      (Witness[0], bottom)
+--------------------------------------------+

Two items. No pubkey anywhere on the stack yet.

Step 1 — OP_INTERNALKEY: push internal key from Taproot context

+--------------------------------------------+
| ff1f9fa3...9986b8                          |  <- internal key (32 bytes, from context)
| c4820b82...313ebc                          |  <- message
| 5a5a5107...a1fdd37                         |  <- sig
+--------------------------------------------+

OP_INTERNALKEY reads the validated internal key from the Taproot execution context — the P that was checked against the UTXO's output key Q when the control block was processed. This value was never in the witness. It comes from the UTXO's construction history.

Step 2 — OP_CHECKSIGFROMSTACK: pop pubkey, message, sig — verify — push result

+--------------------------------------------+
| 01                                         |  <- TRUE
+--------------------------------------------+

OP_CSFS pops top-first: internal key, then message, then sig. Executes BIP340 Schnorr verification:

verify: Schnorr(sig=5a5a5107...a1fdd37,
                msg=c4820b82...313ebc,
                pub=ff1f9fa3...9986b8)
result: VALID -> push 01

Script terminates with a single truthy value. The spend is valid.

Why the witness has two items instead of three

In the standalone CSFS experiment, the spender supplies [sig, message, pubkey] — three explicit items. The pubkey is caller-supplied: whoever constructs the reveal transaction chooses which key to present. This works fine for verifying against an external key like an oracle or a co-signer, but it means the script has no binding to the UTXO's specific identity.

IK+CSFS replaces that third item with the execution context. The spender cannot choose a different pubkey. They cannot substitute a key that matches their own private key unless their private key happens to be the TapTree’s internal key. The authorization is not externally presented — it is structurally enforced by the UTXO’s Taproot construction.

The practical pattern: a cold key holder pre-signs authorization tickets (sig, message) offline. A hot-side executor broadcasts those tickets without ever holding the cold private key. The script enforces that only the internal key holder's signatures are valid — and the internal key is locked into the UTXO at creation time, not declared at spend time.

Address Reconstruction with RootScope

The tapscript is two bytes: cb (OP_INTERNALKEY) and cc (OP_CHECKSIGFROMSTACK). The derivation chain is identical to any other single-leaf TapTree.

The Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || 0x02 || 0xcb || 0xcc)
               (leaf version 0xc0, script length 2, script bytes)
Merkle root  = TapLeaf hash
tweak t      = tagged_hash("TapTweak",  internal_pubkey || merkle_root)
output key Q = internal_pubkey + t*G
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

internal_pubkey = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
script_bytes = bytes([0xcb, 0xcc])

tapleaf_hash = tagged_hash(
    "TapLeaf",
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1p...  [OK]

The same internal_pubkey (ff1f9fa3...9986b8) from all four solo experiments. Same key, two-byte tapscript, different Merkle root, different TapTweak, different address.

RootScope Visual Output

Internal Key
  ff1f9fa3...9986b8  <----- also the key OP_INTERNALKEY pushes at runtime
        |
    TapLeaf (0xc0)
    script: cb cc  (2 bytes)
               ^--- OP_INTERNALKEY pushes this key from context
        |
    TapLeaf Hash
        |   (no siblings -> single-leaf tree)
    Merkle Root
        |
    TapTweak
        |
    Output Key Q  (parity: odd -> control block byte = c1)
        |
    P2TR Address
    tb1p...  [OK]

The control block opens with c1, not c0 as in the CAT, CSFS, and CTV experiments. The different parity reflects a different TapTweak value — this two-byte script produces a different Merkle root than any of the 34-byte or 1-byte scripts, and the tweak lands on an odd-parity point.

There is a deeper connection here worth making explicit. RootScope performs forward derivation: given P and the script, compute Q. The Taproot verifier during control block processing performs the same computation in reverse: given Q from the UTXO and candidate P from the control block, verify that P → Q holds under the same formula. The math is identical; only what is known and what is being verified differs.

This is why OP_INTERNALKEY can be trusted. It does not reach into the witness and grab a key — it surfaces a value that was already validated by the control block check before script execution began. RootScope’s derivation chain is not just an address verification tool; it is a visualization of the trust chain that makes OP_INTERNALKEY meaningful. The key it pushes onto the stack is the same key that satisfies Q = P + t·G for this specific UTXO. That relationship, computed forward by RootScope and verified backward by the node, is the foundation.

Where IK+CSFS Sits in the Series

The four solo experiments each isolated one opcode. The combo experiments start combining them. This is the first.

The progression from CSFS alone to IK+CSFS is the progression from “someone signed this” to “the owner signed this.” OP_INTERNALKEY does one thing: it replaces a witness-supplied public key with the UTXO-bound Taproot identity. That single substitution turns a generic signature check into an ownership-gated authorization.

Next combo: CAT + CSFS — building the signed message dynamically from stack components rather than pre-committing it at script creation time.

A Boundary Condition: Signature Replay

This experiment uses a fixed message constant:

MESSAGE = hashlib.sha256(b"authorized:group_combo_ik_csfs:v1").digest()

Once a successful reveal transaction is on-chain, the (sig, message) pair is permanently visible. If a second UTXO existed with the same cbcc script and the same internal key, that pair could be replayed against it — no private key required. The control block would validate, OP_INTERNALKEY would push the same P, and OP_CSFS would verify the same signature against the same message. The spend would pass.

This is not a flaw in IK+CSFS as a primitive. It is a consequence of using a fixed message in a contract that does not bind the authorization to a specific UTXO. The fix is straightforward: include UTXO-specific data in the message — the txid, vout, amount, or destination — so each signature is only valid for one spend:

MESSAGE = SHA256(txid || vout || amount || destination_scriptpubkey)

This is precisely what the next experiment addresses. CAT + CSFS composes the message dynamically at execution time from stack components. Each signature becomes specific to the spend it authorizes. The replay window closes. IK+CSFS establishes who can authorize; CAT+CSFS establishes what is being authorized and binds the two together.

What We Built

We ran the first combo experiment: a two-byte tapscript that pairs OP_INTERNALKEY with OP_CHECKSIGFROMSTACK. The design is minimal — OP_INTERNALKEY pushes the UTXO’s internal key, then OP_CSFS verifies that the message SHA256("authorized:group_combo_ik_csfs:v1") was signed by that key. The witness supplies only the signature and the message. The pubkey never appears in the witness; it arrives from the Taproot execution context.

We built the TapTree with btcaaron's build_script(OP_INTERNALKEY, OP_CHECKSIGFROMSTACK), assembled the two-byte leaf, and derived the Signet address. The witness was constructed with _make_witness(), which signs the message offline using the same key that controls the TapTree's internal key path. The spend used .unlock_with([sig, message]) — two items, no pubkey.

Both transactions confirmed on Signet. The trace file records the exact witness bytes. The stack execution is three steps: load two witness items, push the internal key via OP_INTERNALKEY, verify and push TRUE via OP_CSFS.

RootScope confirmed the address derivation: same internal key as all prior experiments, two-byte tapscript, different Merkle root, different output key, different address. The control block opens with c1 rather than c0 — the odd-parity outcome of this specific tweak combination.

The real applications of this combination emerge in multi-leaf trees and vault constructions. A leaf that uses IK+CSFS alongside a CTV leaf can enforce both who authorized a spend and exactly where the funds go, with neither condition visible from the P2TR address alone.

Run the future. Execute first. Formalize later.

Evidence Index

Everything needed to reproduce this experiment end-to-end:

Script hex        cbcc
                  (cb = OP_INTERNALKEY, cc = OP_CHECKSIGFROMSTACK)

Internal pubkey   ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8
Message           c4820b82d8856e9d8df36a9138d20149a9cd2f5b83d2e33d1b7e026abc313ebc
                  (SHA256("authorized:group_combo_ik_csfs:v1"))
Commit TxID       9930e922036a80d04a96a4b08f15838bcb880ce2a4be91da0b24af1484e10ea8
Reveal TxID       8d0b2156e9425afe64cabf3c906da255b6b86c51cb8968f828d5253fc261dd8f
Control block     c1ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8
                  (c1 = leaf version 0xc0 + odd parity)
Experiment code   experiments/group_opcodes/code/combo_ik_csfs.py
Trace output      experiments/group_opcodes/outputs/combo_ik_csfs_trace.json
Network           Signet | Bitcoin Inquisition 29.2

Resources

Bitcoin Inquisition: github.com/bitcoin-inquisition
btcaaron toolkit: github.com/aaron-recompile/btcaaron
RootScope visualizer: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition 29.2 | Commit *[*9930e922...0ea8*](https://mempool.space/signet/tx/9930e922036a80d04a96a4b08f15838bcb880ce2a4be91da0b24af1484e10ea8?showDetails=true) | Reveal *[*8d0b2156...dd8f*](https://mempool.space/signet/tx/8d0b2156e9425afe64cabf3c906da255b6b86c51cb8968f828d5253fc261dd8f?showDetails=true)

By Aaron Recompile on March 21, 2026.

Canonical link

Exported from Medium on July 3, 2026.

OP_CHECKTEMPLATEVERIFY on Signet — Locking Outputs at UTXO Creation Time

aaron.recompile — Fri, 03 Jul 2026 02:47:49 +0000

With OP_CAT you assemble data. With OP_CSFS you authorize it. With OP_CTV you enforce it.

Bitcoin is not designed top-down.  
It is discovered through execution.

"Run the Future" — starts here.

Constraining the Future, Not the Present

OP_CHECKSIG proves that the current key holder authorized this spend. OP_CSFS proves that someone authorized some statement. OP_CHECKTEMPLATEVERIFY (BIP119) does something different from both: it proves that the spending transaction itself matches a template committed at UTXO creation time.

The script does not look at a witness. It does not verify a signature. It computes a hash over the spending transaction’s structure — version, locktime, input count, sequences, output count, outputs — and checks whether that hash matches the one baked into the locking script. If the outputs deviate by a single satoshi or a single byte, the hash fails and the spend is rejected.

This is output covenant by pre-commitment. The creator of the UTXO decides, at funding time, exactly where and how much the money can go. The spender has no discretion over the outputs; they can only construct a transaction that reproduces the template exactly.

BIP119 assigns opcode 0xb3 to OP_CTV. On standard nodes 0xb3 is OP_NOP4 — it does nothing, so any spend passes. Bitcoin Inquisition 29.2 activates BIP119 on Signet, turning OP_NOP4 into the real constraint. Same soft fork upgrade pattern as OP_CAT (BIP347, 0x7e) and OP_CSFS (BIP348, 0xcc).

This post runs a minimal CTV experiment on Signet: commit to a template that sends exactly 49,500 sats to a fixed address, then spend by providing an empty witness and a matching transaction. The spending transaction proves itself.

The CTV Contract

The locking script is:

OP_PUSHBYTES_32 <template_hash>
OP_NOP4                          <- OP_CTV on Inquisition (0xb3)

The template hash commits to the spending transaction structure. At spend time, the script:

Pushes <template_hash> onto the stack (from the script itself)
OP_CTV pops it, computes DefaultCheckTemplateVerifyHash(spending_tx, input_index)
Checks: computed_hash == template_hash
If equal, script succeeds

The witness is empty. The spender provides no data — no signature, no preimage, no pubkey. The spending transaction itself is the proof. This is the fundamental contrast with every other script we have seen in this series:

OP_CAT experiment:
  witness  -> ["hello", "world"]     (data for stack computation)
  script   -> OP_CAT OP_SHA256 <hash> OP_EQUAL

OP_CSFS experiment:
  witness  -> [sig, message, pubkey] (authorization proof)
  script   -> OP_CHECKSIGFROMSTACK

OP_CTV experiment:
  witness  -> []                     (nothing)
  script   -> <template_hash> OP_CTV (spending tx proves itself)

The Template Hash: What Gets Committed

DefaultCheckTemplateVerifyHash is defined in BIP119 as:

SHA256(
  nVersion          (4 bytes, little-endian)
  nLockTime         (4 bytes, little-endian)
  -- scriptSigs hash omitted for native segwit (all empty) --
  nInputs           (4 bytes, little-endian)
  SHA256(sequences) (32 bytes)
  nOutputs          (4 bytes, little-endian)
  SHA256(outputs)   (32 bytes)
  input_index       (4 bytes, little-endian)
)

For our experiment, the committed values are:

nVersion          = 2
nLockTime         = 0
nInputs           = 1
sequences         = [0xffffffff]
nOutputs          = 1
outputs           = [49500 sats -> tb1p32g0c5...wsxlfd5s]
input_index       = 0

Computed template hash: f4ceec28ec225e022e059355819726668dca411b9239ee4ef65379dc7bd2d8e08

Every field that could affect the spending transaction’s character is committed. The output address and amount cannot change. The sequence cannot change. The version and locktime cannot change. The only free variable is the input itself — which is implicitly determined by spending the committed UTXO.

The Contract Design

At UTXO creation time:
  compute template_hash = SHA256(version=2 || locktime=0 ||
                                 nInputs=1 || SHA256(seq=0xffffffff) ||
                                 nOutputs=1 || SHA256(49500 sats to tb1p32g0c5...wsxlfd5s) ||
                                 input_index=0)
                        = f4ceec28...d8e08


Lock script:
  OP_PUSHBYTES_32 f4ceec28...d8e08
  OP_NOP4  (= OP_CTV on Inquisition)
At spend time:
  witness  = []   <- empty
  spending tx must reproduce:
    version=2, locktime=0, sequence=0xffffffff,
    exactly one output: 49500 sats -> tb1p32g0c5...wsxlfd5s

The tapscript bytecode:

20     <- OP_PUSHBYTES_32
f4ceec28ec225e022e059355819726668dca411b9239ee4ef65379dc7bd2d8e08
b3     <- OP_NOP4 / OP_CTV

Commit Phase: Building the Taproot Address with btcaaron

btcaaron provides inq_ctv_program_for_output() which handles the template hash computation and TapTree construction in a single call. The caller provides the destination output; the function derives everything else.

FUND_SATS   = 50_000
FEE_SATS    = 500
OUTPUT_SATS = FUND_SATS - FEE_SATS   # 49_500、

change_addr = default_change_address()
script_pubkey_hex = rpc_wallet("getaddressinfo", change_addr)["scriptPubKey"]
program, template_hash = inq_ctv_program_for_output(
    internal_key=key,
    output_sats=OUTPUT_SATS,
    output_script_pubkey=script_pubkey_hex,
    network="signet",
    sequence=0xFFFFFFFF,
)
addr = program.address

btcaaron API Highlights

**inq_ctv_program_for_output(internal_key, output_sats, output_script_pubkey, network, sequence)** wraps the full CTV setup:

Serializes the output: value (8 bytes LE) || compact_size(len(scriptpubkey)) || scriptpubkey
Computes DefaultCheckTemplateVerifyHash over the template fields above
Builds the tapscript: OP_PUSHBYTES_32 <hash> OP_NOP4
Constructs a single-leaf TapTree and derives the Bech32m address
Returns (program, template_hash) — the program carries the spend builder, the hash is for inspection

The caller must save change_addr to disk — it is needed at spend time to reconstruct the exact same template hash. If change_addr changes, the template hash changes, and the spend fails.

Funding the Address

txid = fund_address(addr, FUND_TXID_FILE, fund_sats=FUND_SATS)

Reveal Phase: Spending with an Empty Witness

The spend is architecturally the simplest of the three experiments. The spender provides no data. They only need to reconstruct the identical template (same change_addr, same amounts) and submit a matching transaction.

_, program, _ = _build_ctv_address(change_addr)

tx = (
    program.spend("ctv")
    .from_utxo(txid, vout, sats=sats)
    .to(change_addr, OUTPUT_SATS)
    .sequence(0xFFFFFFFF)
    .unlock_with([])          # <- empty: no witness data
    .build()
)
reveal_txid = broadcast_or_raise(tx.hex)

**.unlock_with([])** passes an empty list. The final witness contains only two items: the tapscript and the control block. There is nothing before them.

**.sequence(0xFFFFFFFF)** must be set explicitly to match the committed template. Any other sequence value produces a different hash and fails the CTV check.

**.to(change_addr, OUTPUT_SATS)** must reproduce the exact scriptpubkey committed in the template. Amount and address must be identical.

The final witness layout:

Witness[0] = 20 f4ceec28...d8e08 b3     <- tapscript (34 bytes)
Witness[1] = c0 ff1f9fa3...9986b8       <- control block (33 bytes)

No Witness[2], no Witness[3]. Two items total.

Transactions, OP_NOP4, and Stack Trace

Commit: what lands on-chain

TxID: [d083e038...69b6681f](https://mempool.space/signet/tx/d083e038393afb711a6f8c11499131e4f856bb3fae898b74e43aa3bb69b6681f?showDetails=true)

INPUT
  tb1pqzxvhv...lsycut3t    1.99999816 sBTC  (key-path spend, 64-byte Schnorr sig)

OUTPUTS
  tb1pg5quycyy...yspzja7g  1.99949661 sBTC  <- change
  tb1pvqhal44...5q6g6avk   0.00050000 sBTC  <- CTV lock UTXO

The CTV lock output tb1pvqhal44...5q6g6avk is a standard P2TR address. No observer can distinguish it from a key-path address. Its previous output script (visible in the reveal tx) confirms:

Previous output script:
  OP_PUSHNUM_1
  OP_PUSHBYTES_32  602fdfd6...042728    <- P2TR output key
Previous output type: V1_P2TR

Reveal: witness data and stack execution

TxID: [2789983e...86a244db](https://mempool.space/signet/tx/2789983e7f01997ef1fa04a718ea83d388e813cd2ded3116a5acb1a986a244db?showDetails=true)

Timestamp  : 2026-03-15 23:47:15 UTC
Fee        : 500 sats  (4.46 sat/vB)
Features   : SegWit | Taproot  (no RBF -- see below)

INPUT
  tb1pvqhal44...5q6g6avk   0.00050000 sBTC
OUTPUT
  tb1p32g0c5...wsxlfd5s    0.00049500 sBTC  (V1_P2TR)

The witness as shown by mempool.space:

Witness[0]  20f4ceec28ec225e022e059355819726668dca411b9239ee4ef65379dc7bd2d8e08b3
            <- tapscript: OP_PUSHBYTES_32 <template_hash> OP_NOP4

Witness[1]  c0ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8
            <- control block (leaf version 0xc0 + internal pubkey)

Two witness items. Nothing else.

P2TR tapscript decoded:

OP_PUSHBYTES_32  f4ceec28ec225e022e059355819726668dca411b9239ee4ef65379dc7bd2d8e08
OP_NOP4

The OP_NOP4 label — same pattern, different opcode

mempool.space decodes 0xb3 and displays:

P2TR tapscript   OP_PUSHBYTES_32 f4ceec28...d8e08  OP_NOP4

0xb3 = 179 decimal. On standard nodes, opcode 179 is OP_NOP4 — a no-op that leaves the stack unchanged. Under BIP342, NOPs in Tapscript are treated differently from OP_SUCCESS: they do not cause immediate pass, but they also do not fail. A standard node executes OP_PUSHBYTES_32 <hash> (stack now has one item) and then OP_NOP4 (does nothing), leaving the hash on the stack. The script terminates with a non-empty stack — which in Tapscript counts as success. So old nodes accept this spend without ever checking the template.

On Bitcoin Inquisition 29.2 with BIP119 active, the same 0xb3 is OP_CTV. It pops the hash from the stack, computes DefaultCheckTemplateVerifyHash from the spending transaction, and checks equality. Only a transaction with the exact matching outputs passes.

This is subtly different from the CSFS case. OP_CSFS (0xcc) is an OP_SUCCESS opcode — old nodes immediately pass without executing anything. OP_NOP4 (0xb3) is a NOP — old nodes execute the full script but do nothing at the NOP step. The end result is the same (old nodes always accept), but the upgrade mechanism differs. BIP119 could have chosen OP_SUCCESS for a cleaner soft fork; instead it chose a NOP to preserve the property that old nodes still execute and validate the non-CTV parts of the script.

Stack execution

Executing: OP_PUSHBYTES_32 <template_hash> OP_NOP4/OP_CTV

The Taproot interpreter strips Witness0 and Witness1. The remaining witness items become the initial execution stack — and there are none.

Initial State: empty stack

+--------------------------------------------+
|                  (empty)                   |
+--------------------------------------------+

No witness data. The spending transaction is implicitly available to OP_CTV, but it is not on the stack.

Step 1 — OP_PUSHBYTES_32: push template hash from script

+--------------------------------------------+
| f4ceec28...d8e08                           |  <- template_hash (32 bytes)
+--------------------------------------------+

The script itself supplies the committed hash. The spender provided nothing — this value came from the locking script, fixed at UTXO creation time.

Step 2 — OP_CTV (0xb3): pop hash, verify spending tx, push result

+--------------------------------------------+
| 01                                         |  <- TRUE
+--------------------------------------------+

OP_CTV pops f4ceec28...d8e08 and computes:

computed = DefaultCheckTemplateVerifyHash(spending_tx, input_index=0)
         = SHA256(
             version=2          nLockTime=0
             nInputs=1          SHA256(seq=0xffffffff)
             nOutputs=1         SHA256(49500 sats to tb1p32g0c5...wsxlfd5s)
             input_index=0
           )
         = f4ceec28...d8e08

check: computed == template_hash  -> TRUE

The spending transaction’s structure exactly reproduces the committed template. Script terminates with TRUE. Spend is valid.

Why nSequence = 0xffffffff and no RBF

The reveal transaction features show no RBF flag. This is not an accident.

nSequence = 0xffffffff is committed in the template hash. If you tried to replace the transaction (RBF) with a different fee by changing the fee rate, you would need to either reduce the output amount or add a second input. Reducing the output amount changes the outputs hash — the CTV check fails. Adding a second input changes nInputs — the CTV check fails. There is no fee-bumping path that leaves the template hash intact.

CPFP is the practical solution. After the reveal transaction confirms and sends 49,500 sats to tb1p32g0c5...wsxlfd5s, that output can spend those sats with a high-fee child transaction. Miners who see the child's fee incentive will mine the parent (reveal) too. This is why the Delving Bitcoin post noted: "CTV: parent template constraints make direct replacement less flexible; CPFP is the practical accelerator."

In the experiment, we set the fee to 500 sats and waited for natural confirmation. At 4.46 sat/vB on Signet, this took hours — the EXPERIMENT_MATRIX records a reveal-to-confirm window of ~338,814 seconds (~3.9 days) for the earlier CTV run. For production CTV vaults, fee planning at template creation time is critical.

Address Reconstruction with RootScope

The tapscript is 34 bytes: one OP_PUSHBYTES_32 (0x20), the 32-byte template hash, and OP_NOP4 (0xb3).

The Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || 0x22 || 0x20 || template_hash || 0xb3)
               (leaf version, script length=34, OP_PUSHBYTES_32, hash, OP_NOP4)
Merkle root  = TapLeaf hash
tweak t      = tagged_hash("TapTweak",  internal_pubkey || merkle_root)
output key Q = internal_pubkey + t*G
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

template_hash = bytes.fromhex(
    "f4ceec28ec225e022e059355819726668dca411b9239ee4ef65379dc7bd2d8e08"
)
script_bytes = bytes([0x20]) + template_hash + bytes([0xb3])

tapleaf_hash = tagged_hash(
    "TapLeaf",
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash
internal_pubkey = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1pvqhal44...5q6g6avk  [OK]

Notice: the same internal_pubkey (ff1f9fa3...9986b8) appears in all three experiments. It is the x-only pubkey of key = Key.from_wif(DEMO_KEY_WIF), the key that controls all three TapTree key paths. The three experiments share one key but embed completely different tapscripts.

RootScope Visual Output

Internal Key
  ff1f9fa3...9986b8
        |
    TapLeaf (0xc0)
    script: 20 f4ceec28...d8e08 b3  (34 bytes)
        |
    TapLeaf Hash
        |   (no siblings -> single-leaf tree)
    Merkle Root
        |
    TapTweak
        |
    Output Key Q
        |
    P2TR Address
    tb1pvqhal44...5q6g6avk   [OK]

The Series Complete: CAT, CSFS, CTV

This is the third and final post in the series. All three opcodes are now confirmed on Signet.

Opcode BIP Legacy opcode What it constrains Witness Stack at start OP_CAT 347 OP_SUCCESS Stack composition [part1, part2] 2 items from witness OP_CSFS 348 OP_SUCCESS Signature scope [sig, message, pubkey] 3 items from witness OP_CTV 119 OP_NOP4 Output template [] empty

The three opcodes represent three different answers to the question “what should Bitcoin Script be able to prove?”:

CAT says: the stack should be able to assemble arbitrary byte strings. It gives Script a serialization primitive. Without CAT, you cannot construct dynamic messages or concatenate transaction fields. With CAT, you can build any 32-byte value from components available on the stack.

CSFS says: Script should be able to verify that a specific key holder pre-authorized a specific statement. It decouples authorization from the spending transaction. Without CSFS, a key can only authorize one transaction. With CSFS, a key can authorize any statement — an oracle reading, an output template, a channel state.

CTV says: Script should be able to constrain the spending transaction to a fixed template, without requiring any runtime authorization. It is deterministic covenant enforcement. Without CTV, you need a signature to authorize every spend. With CTV, the UTXO is self-enforcing — anyone can spend it, but only to the committed destination.

The three together form a covenant design space. A vault that allows emergency recovery, time-locked inheritance, and fee optimization might use all three: CAT to serialize the output template at runtime, CSFS to verify the vault manager’s pre-authorization, and CTV to enforce the final destination unconditionally.

What We Built

We constructed a CTV output that commits exactly 49,500 sats to a fixed destination. The locking script is 34 bytes: a pushed template hash followed by OP_NOP4/OP_CTV. The spending witness is empty — the transaction structure is its own proof.

We used btcaaron's inq_ctv_program_for_output() to derive the template hash and build the TapTree in one call. The spend used .unlock_with([]) and .sequence(0xFFFFFFFF) — no data supplied, but the transaction structure must match exactly. RootScope verified the address reconstruction: same internal key as the CAT and CSFS experiments, different 34-byte tapscript, different output key, different address.

The OP_NOP4 label in mempool.space reflects a different soft fork path than CSFS’s OP_SUCCESS: old nodes execute the full script but treat the NOP as inert, leaving the hash on the stack and accepting. Inquisition nodes enforce the actual CTV semantics. Both paths lead to old-node acceptance — only upgraded miners can reject an invalid template spend.

The reveal transaction has no RBF flag and no viable fee-bumping path short of CPFP. This is not an implementation detail; it is a direct consequence of the template hash committing to nSequence and outputs. Fee planning belongs at UTXO creation time, not at spend time.

All three transactions — CAT, CSFS, CTV — are permanently confirmed on Signet and reproducible end-to-end using the tools below.

Resources

Bitcoin Inquisition: github.com/bitcoin-inquisition
btcaaron toolkit: github.com/aaron-recompile/btcaaron
RootScope visualizer: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition 29.2 | Commit *[*d083e038...69b6681f*](https://mempool.space/signet/tx/d083e038393afb711a6f8c11499131e4f856bb3fae898b74e43aa3bb69b6681f?showDetails=true) | Reveal *[*2789983e...86a244db*](https://mempool.space/signet/tx/2789983e7f01997ef1fa04a718ea83d388e813cd2ded3116a5acb1a986a244db?showDetails=true)

By Aaron Recompile on March 19, 2026.

Canonical link

Exported from Medium on July 3, 2026.

OP_CHECKSIGFROMSTACK on Signet — Sign Anything, Verify on Stack

aaron.recompile — Fri, 03 Jul 2026 02:47:48 +0000

Satoshi disabled OP_CAT in 2010. OP_CSFS was never even enabled. We ran it on-chain in 2026.

Bitcoin is not designed top-down.  
It is discovered through execution.

"Run the Future" — starts here.

Decoupling the Signature from the Transaction

Every Bitcoin signature you have ever seen signs the same thing: a hash of the current transaction. OP_CHECKSIG, OP_CHECKMULTISIG, Schnorr — they all implicitly bind the signature to the spending transaction. The message is not a parameter; it is fixed by consensus.

OP_CHECKSIGFROMSTACK (BIP348) breaks that assumption. It takes three explicit stack items — a signature, a message, and a public key — and verifies the signature over that arbitrary message. The message can be anything: a SHA256 digest of a string, a serialized output template, a price oracle feed, a cross-input commitment. The transaction is irrelevant.

This changes what Bitcoin Script can express. OP_CHECKSIG can only attest that the signer authorized this spend. OP_CSFS can attest that the signer authorized any statement, and that statement can be checked against other stack values produced by introspection. Combined with OP_CAT (previous post), it becomes possible to serialize transaction fields, hash them, sign them in advance, and enforce the result as a covenant.

BIP348 assigns opcode 0xcc to OP_CHECKSIGFROMSTACK. Bitcoin Inquisition 29.2 activates it on Signet alongside BIP347 (OP_CAT) and BIP119 (OP_CTV), making all three available for combined experimentation.

This post runs a minimal CSFS experiment on Signet: sign the digest of "hello world" offline, embed the pubkey in the tapscript, and let the script verify the signature at spend time. The message has nothing to do with the transaction.

One thing to note upfront: OP_CSFS reveal transactions are non-standard under legacy mempool policy. They will not appear in standard Signet mempools before confirmation. After Inquisition mines the block, the transaction becomes visible on public explorers. “Not in the mempool” is a policy observation, not a consensus rejection.

The CSFS Contract

OP_CHECKSIGFROMSTACK in its simplest form is a single opcode. The script is:

OP_CHECKSIGFROMSTACK   (0xcc)

That is the entire locking script. The spending witness must supply, in order:

[sig]      <- Schnorr signature over the committed message
[message]  <- the 32-byte message that was signed
[pubkey]   <- x-only public key of the signer

The script pops all three and verifies. If the signature is valid over the message under the pubkey, the result is 1 (TRUE).

Compare this to OP_CHECKSIG:

OP_CHECKSIG behavior:
  message  = implicit (current tx sighash)
  pubkey   = from script
  sig      = from witness
  -> verifies sig(tx_hash, pubkey)

OP_CHECKSIGFROMSTACK behavior:
  message  = explicit (from witness stack)
  pubkey   = explicit (from witness stack)
  sig      = explicit (from witness stack)
  -> verifies sig(message, pubkey)

The transaction is not in scope. This is the core design shift.

The Contract Design

Signer offline:
  message = SHA256("hello world")
           = b94d27b9...efcde9
  sig     = Schnorr.sign(secret_key, message)
           = ab69f346...76912

At spend time, witness provides:
  Witness[0] = sig       (64 bytes)
  Witness[1] = message   (32 bytes)
  Witness[2] = pubkey    (32 bytes)
Script (one byte):
  0xcc = OP_CHECKSIGFROMSTACK
       -> pops pubkey, message, sig
       -> verifies sig over message under pubkey
       -> pushes TRUE

The tapscript bytecode is exactly:

cc   <- OP_CHECKSIGFROMSTACK

One byte. No hash commitment in the script itself — the pubkey alone identifies the authorized signer.

Commit Phase: Building the Taproot Address with btcaaron

btcaaron ships inq_csfs_script() which returns the single-byte 0xcc tapscript. The commit phase is identical in structure to the CAT experiment: build a single-leaf TapTree, derive the address, fund it.

MESSAGE = hashlib.sha256(b"hello world").digest()

leaf_script = inq_csfs_script()
key = Key.from_wif(DEMO_KEY_WIF)
tap_tree = (
    TapTree(internal_key=key, network="signet")
    .custom(script=leaf_script, label="csfs")
).build()
addr = tap_tree.address

btcaaron API Highlights

**inq_csfs_script()** returns a RawScript containing the single byte 0xcc. This is Inquisition's opcode assignment for OP_CHECKSIGFROMSTACK under BIP348. On a standard node the same byte is an OP_SUCCESS opcode — more on this below.

**TapTree(...).custom(script, label).build()** derives the P2TR address via the same TapLeaf -> Merkle root -> TapTweak -> output key chain described in the previous post. The script being one byte makes no difference to the derivation logic.

Funding the Address

txid = rpc_wallet("sendtoaddress", tap_tree.address, FUND_SATS / 1e8)

Reveal Phase: Spending with an Offline Signature

The reveal transaction constructs the witness by signing the message offline with the secp256k1 library, then submitting all three items — sig, message, pubkey — to the script.

def _make_witness():
    secret = wif_secret_bytes(DEMO_KEY_WIF)
    pk = PrivateKey(secret, raw=True)
    sig = pk.schnorr_sign(MESSAGE, "", raw=True)
    pub_x = pk.pubkey.serialize()[1:33]
    return [sig.hex(), MESSAGE.hex(), pub_x.hex()]

tx = (
    program.spend("csfs")
    .from_utxo(txid, vout, sats=sats)
    .to(change_addr, sats - fee_sats)
    .unlock_with(_make_witness())
    .build()
)

reveal_txid = broadcast_or_raise(tx.hex)

btcaaron Spend API

**_make_witness()** produces three items in the order CSFS expects: signature first (deepest on stack), then message, then pubkey (topmost). The Taproot interpreter will load these as the initial execution stack before running the tapscript.

**pk.schnorr_sign(MESSAGE, "", raw=True)** signs the 32-byte message digest directly using BIP340 Schnorr. The second argument ("") is the auxiliary randomness string; passing empty uses a deterministic nonce.

**.unlock_with([...])** injects all three items before the script and control block, exactly as in the CAT experiment. The final witness layout is:

Witness[0] = ab69f346...76912      <- Schnorr sig (64 bytes)
Witness[1] = b94d27b9...efcde9     <- message = SHA256("hello world") (32 bytes)
Witness[2] = ff1f9fa3...9986b8     <- x-only pubkey (32 bytes)
Witness[3] = cc                    <- tapscript (OP_CHECKSIGFROMSTACK, 1 byte)
Witness[4] = c0ff1f9f...9986b8     <- control block (33 bytes)

Transactions, OP_RETURN_204, and Stack Trace

Commit: what lands on-chain

TxID: [2d68a0e6...133803fe](https://mempool.space/signet/tx/2d68a0e621533c2f7391159f4c2e252f409c1cec0ec681ff9c6b11cb133803fe?showDetails=true)

INPUT
  tb1p...                          0.00050000 sBTC  (funding source)

OUTPUTS
  tb1p822a0z...fqp6x5up            0.00050000 sBTC  <- CSFS lock UTXO
  (change)

The output tb1p822a0z...fqp6x5up is a standard P2TR address. No observer can tell that the script path is a single-byte OP_CSFS.

Reveal: what mempool.space shows

TxID: [cc1b6d35...85195f97](https://mempool.space/signet/tx/cc1b6d352f75348b6a52c7f5c68fc5caea2512423e08011e8f69a9bb85195f97?showDetails=true)

INPUT
  tb1p822a0z...fqp6x5up            0.00050000 sBTC

OUTPUT
  tb1pghctez...es5gqyqw            0.00049500 sBTC  (V1_P2TR)

The witness data as shown by mempool.space:

Witness[0]  ab69f3465e011994ae9d33650a75fa8b0d5f333d...76912
            <- Schnorr sig (64 bytes)

Witness[1]  b94d27b9934d3e08a52e52d7da7dabfac484efe3...efcde9
            <- SHA256("hello world") (32 bytes)
Witness[2]  ff1f9fa326a9438227e6aa25030ccf89bcb8ce53...9986b8
            <- x-only pubkey (32 bytes)
Witness[3]  cc
            <- tapscript
Witness[4]  c0 ff1f9fa3...9986b8
            <- control block (leaf version 0xc0 + internal pubkey)

The OP_RETURN_204 label — and what it actually means

mempool.space decodes the tapscript cc and displays it as:

P2TR tapscript   OP_RETURN_204

This label requires explanation. 0xcc = 204 decimal. On nodes that have not activated BIP348, opcode 204 falls in the OP_SUCCESS range defined by BIP342 (opcodes 187–254 are OP_SUCCESS in Tapscript). An OP_SUCCESS opcode causes the tapscript to pass immediately — no further evaluation. So a non-upgraded node reads cc, recognizes it as OP_SUCCESS, and marks the script valid without checking the signature at all.

On Bitcoin Inquisition 29.2, which has BIP348 activated, the same byte cc is interpreted as OP_CHECKSIGFROMSTACK. The node actually pops pubkey, message, and sig off the stack and performs the Schnorr verification.

This is the standard soft fork upgrade mechanism. The new rule turns an “always pass” opcode into a real constraint. Miners running Inquisition enforce the new semantics; legacy nodes see OP_SUCCESS and accept the block because they have no rule to reject it. mempool.space, running standard software, therefore labels it OP_RETURN_204 — their display name for "opcode 204, meaning unknown." The word "RETURN" here is not OP_RETURN the opcode; it is a mempool.space naming convention for unrecognized opcodes.

Stack execution

Executing: OP_CHECKSIGFROMSTACK (single opcode, 0xcc)

The Taproot interpreter strips Witness3 and Witness4, leaving Witness[0..2] as the execution stack:

Initial State: three witness items loaded

+--------------------------------------------+
| ff1f9fa3...9986b8                          |  <- pubkey    (Witness[2], top)
| b94d27b9...efcde9                          |  <- message   (Witness[1])
| ab69f346...76912                           |  <- sig       (Witness[0], bottom)
+--------------------------------------------+

Three explicit inputs. The transaction itself is not on the stack and plays no role in what follows.

Step 1 — OP_CHECKSIGFROMSTACK: pop pubkey, message, sig — verify — push result

+--------------------------------------------+
| 01                                         |  <- TRUE
+--------------------------------------------+

OP_CSFS pops all three items (top-first: pubkey, then message, then sig) and runs BIP340 Schnorr verification:

verify: Schnorr(sig=ab69f346...76912,
                msg=b94d27b9...efcde9,
                pub=ff1f9fa3...9986b8)

result: VALID -> push 01

Script terminates with a single truthy value. The spend is valid.

Why does the sig not cover the transaction?

With OP_CHECKSIG, the signer must know the transaction being spent — the signature is computed over the sighash, which commits to inputs, outputs, and amounts. If the outputs change, the signature breaks.

With OP_CSFS, the signer committed to SHA256("hello world") — a message that has nothing to do with the transaction. The signature was computed before the transaction existed. This is the delegation primitive: a key holder can pre-authorize an action by signing a statement, and anyone who obtains that signature can construct a transaction that passes the CSFS check, regardless of what the outputs look like. Combined with OP_CTV (next post), you can constrain both the authorization (CSFS) and the outputs (CTV) simultaneously.

Address Reconstruction with RootScope

The tapscript is a single byte: 0xcc. That makes the derivation maximally transparent.

The Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || 0x01 || 0xcc)
               (leaf version 0xc0, script length 1, script byte 0xcc)
Merkle root  = TapLeaf hash
tweak t      = tagged_hash("TapTweak",  internal_pubkey || merkle_root)
output key Q = internal_pubkey + t*G
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

script_bytes = bytes([0xcc])   # OP_CHECKSIGFROMSTACK, 1 byte

tapleaf_hash = tagged_hash(
    "TapLeaf",
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash
internal_pubkey = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1p822a0z...fqp6x5up  [OK]

Notice: the internal pubkey in the control block (ff1f9fa3...9986b8) is the same key provided in the witness as the CSFS pubkey. This is intentional for the demo — the same key controls both the Taproot key path and the CSFS verification. In production designs these would typically be different keys.

RootScope Visual Output

Internal Key
  ff1f9fa3...9986b8
        |
    TapLeaf (0xc0)
    script: cc  (1 byte)
        |
    TapLeaf Hash
        |   (no siblings -> single-leaf tree)
    Merkle Root
        |
    TapTweak
        |
    Output Key Q
        |
    P2TR Address
    tb1p822a0z...fqp6x5up   [OK]

The one-byte script produces the same derivation depth as any other single-leaf tree. The address gives no indication of the script’s size or content.

Where CSFS Sits in the CAT / CSFS / CTV Series

This is the second post in a three-part series. Each opcode in the series constrains a different layer of a transaction:

Opcode BIP What it constrains Mechanism Post OP_CAT 347 Stack composition Concatenate two elements; enables serialization [1] OP_CSFS 348 Signature scope Verify a signature over any message, not just tx [2] OP_CTV 119 Output template Commit the spend tx to a pre-defined hash [3]

OP_CAT operates purely on the stack and knows nothing about transactions. OP_CSFS understands signatures and keys, but deliberately decouples the message from the transaction. OP_CTV goes furthest — it commits the entire spending transaction to a hash baked into the locking script, requiring exact output reproduction.

The three together form a covenant toolkit. A realistic pattern: use CAT to serialize transaction output data onto the stack, use CSFS to verify that an authorized party signed that output template, and use CTV to enforce the template is reproduced exactly. Each opcode handles one layer; none of them alone is sufficient.

Next post: OP_CHECKTEMPLATEVERIFY on Signet — committing to outputs at UTXO creation time, and why CPFP is the practical fee-bumping strategy when the output template is fixed.

What We Built

We designed the simplest possible CSFS contract: a one-byte tapscript (0xcc) that verifies a Schnorr signature over an arbitrary 32-byte message. The message — SHA256("hello world") — was signed offline before the transaction existed. At spend time, the witness supplies the sig, message, and pubkey explicitly; OP_CSFS verifies without consulting the transaction sighash at all.

We used btcaaron's inq_csfs_script() to get the tapscript byte, built a single-leaf TapTree with TapTree(...).custom(...).build(), and constructed the witness with _make_witness() + .unlock_with(). RootScope verified the address reconstruction: internal key + one-byte script -> TapLeaf hash -> TapTweak -> output key -> tb1p822a0z...fqp6x5up.

The key thing mempool.space reveals: the decoded tapscript reads OP_RETURN_204, not OP_CHECKSIGFROMSTACK. That is not a bug in the explorer. It is the soft fork mechanism in action — non-upgraded nodes see OP_SUCCESS and pass the script unconditionally; Inquisition nodes see the actual CSFS semantics and enforce the signature check. The same upgrade pattern governs Taproot, SegWit, and every future Bitcoin soft fork.

Both transactions are permanently confirmed on Signet.

Resources

Bitcoin Inquisition: github.com/bitcoin-inquisition
btcaaron toolkit: github.com/aaron-recompile/btcaaron
RootScope visualizer: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition 29.2 | Commit *[*2d68a0e6...133803fe*](https://mempool.space/signet/tx/2d68a0e621533c2f7391159f4c2e252f409c1cec0ec681ff9c6b11cb133803fe?showDetails=true) | Reveal *[*cc1b6d35...85195f97*](https://mempool.space/signet/tx/cc1b6d352f75348b6a52c7f5c68fc5caea2512423e08011e8f69a9bb85195f97?showDetails=true)

By Aaron Recompile on March 17, 2026.

Canonical link

Exported from Medium on July 3, 2026.

OP_CAT + OP_CHECKSIGFROMSTACK on Signet — Dynamic Message, Oracle Authorization

aaron.recompile — Fri, 03 Jul 2026 02:47:46 +0000

OP_CAT + OP_CHECKSIGFROMSTACK on Signet — Dynamic Message, Oracle Authorization

IK + CSFS asks: did the owner sign this? CAT + CSFS asks: did the oracle sign what the stack assembled?

The interesting question is not what an opcode does.
It is what emerges when they compose.

The interesting question is not what an opcode does.
It is what emerges when they compose.

Bitcoin is not designed top-down.
It is discovered through execution.
"Run the Future" - continues here.

TL;DR — Four opcodes, 36 bytes (7ea820...cc). OP_CAT assembles the signed message on-chain from two witness fragments. OP_SHA256 fixes it to a 32-byte digest. An oracle pubkey hardcoded in the script authorizes exactly that digest via OP_CHECKSIGFROMSTACK. The signer never saw the transaction — they only signed a price quote. The witness carries the raw material; the script determines what counts as authorization.

From Identity to Message

The previous combo experiment established one axis of the binding surface: who is authorized. OP_INTERNALKEY pulls the UTXO’s internal key from the Taproot execution context; OP_CHECKSIGFROMSTACK verifies that this specific key holder signed the message. The pubkey moves from the witness into the structure of the UTXO itself.

This experiment shifts to a different axis: what is being authorized, and specifically, how the authorized message is constructed.

In every previous CSFS experiment — solo or combined — the witness hands the message in whole. It is a static 32-byte blob: SHA256("hello world"), SHA256("authorized:group_combo_ik_csfs:v1"). The signer commits to a pre-known string, and the verifier checks it. The message content is determined before the script runs.

OP_CAT changes that. Combined with OP_SHA256 and OP_CSFS, it makes the message a runtime product of execution. The witness provides raw fragments — two byte strings that the script assembles, hashes, and then checks a signature against. The oracle never sees the assembled form; they sign semantic components. The final authorization target is constructed on-chain.

This is the oracle-gate pattern: the script commits to an authorized signer (the oracle pubkey), but not to the authorized message. The message is determined by what the spender supplies. The oracle attests to a statement structure — “a price reading of the form ASSET=VALUE" — and any spend that presents matching fragments with a valid oracle signature passes.

Binding surface evolution:
  CSFS          pubkey: witness    message: witness (static whole)
  IK + CSFS     pubkey: context    message: witness (static whole)
  CAT + CSFS    pubkey: script     message: assembled on-chain from witness parts

The pubkey is now in the script itself, hardcoded at UTXO creation time. The message is not pre-committed anywhere — it emerges from execution.

The CAT+CSFS Contract

The locking script is:

OP_CAT
OP_SHA256
OP_PUSHBYTES_32 <oracle_pubkey>
OP_CHECKSIGFROMSTACK

The oracle signs a message offline. The spender provides two fragments and the signature. The script assembles the fragments, hashes them, pushes the oracle pubkey, and verifies.

For this experiment: PART1 = "BTC_USD=", PART2 = "100000". The oracle attests to a price reading.

Compare the three CSFS variants:

Standalone CSFS:
  witness  = [sig, message, pubkey]
  script   = OP_CHECKSIGFROMSTACK

IK + CSFS:
  witness  = [sig, message]
  script   = OP_INTERNALKEY OP_CHECKSIGFROMSTACK
CAT + CSFS:
  witness  = [sig, PART1, PART2]
  script   = OP_CAT OP_SHA256 <oracle_pubkey> OP_CHECKSIGFROMSTACK

In the CAT+CSFS version, the message is absent from the witness as a unit. It does not exist until OP_CAT runs. The oracle pubkey is not in the witness at all — it is embedded in the script, committed at UTXO creation time.

The Contract Design

Oracle offline:
  FULL_MESSAGE = PART1 || PART2 = "BTC_USD=100000"
  MESSAGE_HASH = SHA256("BTC_USD=100000")
               = d97200147349b678a5f38c5e5cf95181476b4961ef6566570f88c3ea9b4ccc73
  sig          = Schnorr.sign(oracle_key, MESSAGE_HASH)

At spend time, witness provides:
  Witness[0] = sig    (64 bytes)
  Witness[1] = PART1  "BTC_USD=" (8 bytes)
  Witness[2] = PART2  "100000"   (6 bytes)
Script constructs the message on-chain:
  CAT    -> "BTC_USD=100000"
  SHA256 -> d97200...ccc73   (same hash oracle signed)
  PUSH oracle_pk
  CSFS   -> verify sig(MESSAGE_HASH, oracle_pk) -> TRUE

The tapscript bytecode:

7e                                               <- OP_CAT
a8                                               <- OP_SHA256
20                                               <- OP_PUSHBYTES_32
ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8
cc                                               <- OP_CHECKSIGFROMSTACK (OP_RETURN_204 on standard nodes)

36 bytes. The oracle pubkey is the only constant embedded in the script — the message structure is implicit in the oracle’s signing convention, not enforced by the bytecode.

A note on the demo key. In this experiment, ORACLE_PUBKEY is derived from the same WIF as the TapTree's internal key — the oracle and the UTXO creator are the same entity. This is a deliberate simplification to keep the experiment self-contained. In production the two would be distinct: the internal key held by whoever deploys the contract, the oracle pubkey belonging to an independent data provider. The script mechanism is identical either way. When the two keys are the same, the oracle gate reduces to self-authorization. When they differ, it becomes a genuine third-party attestation gate — which is the pattern worth building toward.

Commit Phase: Building the Taproot Address with btcaaron

PART1 = b"BTC_USD="
PART2 = b"100000"
FULL_MESSAGE = PART1 + PART2
MESSAGE_HASH = hashlib.sha256(FULL_MESSAGE).digest()

key = Key.from_wif(DEMO_KEY_WIF)
ORACLE_PUBKEY = bytes.fromhex(key.xonly)
leaf_script = RawScript(
    build_script(
        OP_CAT,
        OP_SHA256,
        push_bytes(ORACLE_PUBKEY),
        OP_CHECKSIGFROMSTACK,
    )
)
program = (
    TapTree(internal_key=key, network="signet")
    .custom(script=leaf_script, label="cat_csfs")
).build()
addr = program.address

btcaaron API Highlights

**build_script(OP_CAT, OP_SHA256, push_bytes(ORACLE_PUBKEY), OP_CHECKSIGFROMSTACK)** assembles the 36-byte tapscript. OP_CAT and OP_CHECKSIGFROMSTACK are imported from experiments.opcodes as raw bytes 0x7e and 0xcc — proposed opcodes defined in the experiment layer rather than btcaaron's standard primitives. push_bytes(ORACLE_PUBKEY) encodes the 32-byte oracle pubkey with the 0x20 length prefix.

**TapTree(...).custom(script, label).build()** derives the P2TR address via the same TapLeaf → Merkle root → TapTweak → output key chain as all previous experiments. A 36-byte script produces the same derivation structure as any other single-leaf tree.

Funding the Address

txid = fund_address(addr, FUND_TXID_FILE, fund_sats=50_000)

Reveal Phase: Spending with Sig and Fragments

The witness is three items: the oracle signature, and the two fragments that the script will assemble on-chain. The assembled message never appears in the witness — it is a runtime product.

def _make_witness():
    secret = wif_secret_bytes(DEMO_KEY_WIF)
    sk = PrivateKey(secret, raw=True)
    sig = sk.schnorr_sign(MESSAGE_HASH, "", raw=True)
    return [sig.hex(), PART1.hex(), PART2.hex()]

tx = (
    program.spend("cat_csfs")
    .from_utxo(txid, vout, sats=sats)
    .to(change_addr, sats - fee_sats)
    .unlock_with(_make_witness())
    .build()
)
reveal_txid = broadcast_or_raise(tx.hex)

btcaaron Spend API

**_make_witness()** returns [sig, PART1, PART2]. Elements are pushed in list order, so sig lands at the bottom of the execution stack, PART1 in the middle, and PART2 at the top. This is what OP_CAT expects: it pops the top two elements and concatenates as bottom || top, producing PART1 || PART2.

**pk.schnorr_sign(MESSAGE_HASH, "", raw=True)** signs the 32-byte digest of the fully assembled message. The oracle signs a pre-computed hash — they never interact with the transaction or the fragments individually.

The final witness layout:

Witness[0] = e3e78a8f...83cfde       <- Schnorr sig (64 bytes)
Witness[1] = 4254435f5553443d        <- PART1: "BTC_USD=" (8 bytes)
Witness[2] = 313030303030            <- PART2: "100000" (6 bytes)
Witness[3] = 7ea820ff1f9f...9986b8cc <- tapscript (36 bytes)
Witness[4] = c1ff1f9fa3...9986b8     <- control block (33 bytes)

Transactions, OP_RETURN_204, and Stack Trace

Commit: what lands on-chain

TxID: [926c40c1...008f](https://mempool.space/signet/tx/926c40c1b72edb904a3bb7bf96795f351a6be597fc1aeab1390c15e0133b008f?showDetails=true)

Timestamp     : 2026-03-21 12:24:18 UTC
Confirmed     : after 9 minutes
Fee           : 155 sats  (1.01 sat/vB)
Features      : SegWit | Taproot | RBF

INPUT
  tb1p2nmwxkf...psdvg7ky    0.00132441 sBTC
OUTPUTS
  tb1p7vd6g2a...nscrqdhy    0.00082286 sBTC  <- change
  tb1peaj5tna...csd84jel    0.00050000 sBTC  <- CAT+CSFS lock UTXO

The output tb1peaj5tna...csd84jel is a standard P2TR address. No observer can tell from the outside that a 36-byte oracle-gate script is committed in the script path.

Reveal: what mempool.space shows

TxID: [75db54de...65ca2](https://mempool.space/signet/tx/75db54dea1f125174699710bd5b517ae13b6e09b3293a0b0f463ea5561a65ca2?showDetails=true)

Timestamp  : 2026-03-21 12:24:18 UTC
Fee        : 500 sats  (3.77 sat/vB)
Features   : SegWit | Taproot | RBF

INPUT
  tb1peaj5tna...csd84jel    0.00050000 sBTC
OUTPUT
  tb1p0tmlqak...xqcuvjzl    0.00049500 sBTC  (V1_P2TR)

The witness as shown by mempool.space:

Witness[0]  e3e78a8f93d0349a4c20694ed93a4593a0179615667d
            a0078658973ee8d939bf146c574398ed3af179b560306b
            2f8508aa33598b262d783b786c709dcd83cfde
            <- Schnorr sig (64 bytes)

Witness[1]  4254435f5553443d
            <- "BTC_USD=" (8 bytes)
Witness[2]  313030303030
            <- "100000" (6 bytes)
Witness[3]  7ea820ff1f9fa326a9438227e6aa25030ccf89bcb8ce
            53db4f78dbce6146499d9986b8cc
            <- tapscript: OP_CAT OP_SHA256 OP_PUSHBYTES_32 <oracle_pk> OP_RETURN_204
Witness[4]  c1ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db
            4f78dbce6146499d9986b8
            <- control block (leaf version 0xc0 + odd parity + internal pubkey)

nSequence for this input is 0xfffffffd — RBF is enabled. This differs from the CTV experiment where 0xffffffff was required by the template hash commitment. Here the output template is unconstrained; the spender is free to replace the transaction to adjust fees.

The OP_RETURN_204 label

mempool.space decodes the tapscript and displays:

P2TR tapscript   OP_CAT  OP_SHA256  OP_PUSHBYTES_32 ff1f9f...9986b8  OP_RETURN_204

OP_RETURN_204 is the explorer's label for opcode 0xcc = 204 decimal. On standard nodes without BIP348 active, 204 falls in the OP_SUCCESS range (BIP342 opcodes 187–254), causing the tapscript to pass immediately without checking the signature. On Bitcoin Inquisition 29.2 with BIP348 active, the same byte is OP_CHECKSIGFROMSTACK — the node pops pubkey, message, and sig from the stack and runs BIP340 Schnorr verification.

Notably, OP_CAT and OP_SHA256 are shown correctly by mempool.space — they are recognized opcodes on standard nodes (CAT via BIP347, SHA256 via existing script support). Only the final 0xcc is unknown to the standard decoder. The word "RETURN" in OP_RETURN_204 is not OP_RETURN the data-embedding opcode; it is mempool.space's naming convention for unrecognized opcodes.

Stack execution

Executing: OP_CAT OP_SHA256 OP_PUSHBYTES_32 <oracle_pubkey> OP_CHECKSIGFROMSTACK

The Taproot interpreter strips Witness3 and Witness4, loading Witness[0..2] as the initial execution stack.

Initial State: three witness items loaded

+--------------------------------------------+
| 313030303030                               |  <- "100000"   (Witness[2], PART2, top)
| 4254435f5553443d                           |  <- "BTC_USD=" (Witness[1], PART1)
| e3e78a8f...83cfde                          |  <- Schnorr sig (Witness[0], bottom)
+--------------------------------------------+

Two fragments and a signature. The assembled message does not exist yet. The oracle pubkey is not on the stack — it is waiting in the script.

Step 1 — OP_CAT: pop top two, push concatenation

+--------------------------------------------+
| 4254435f5553443d313030303030               |  <- "BTC_USD=100000" (14 bytes)
| e3e78a8f...83cfde                          |  <- sig (still on stack)
+--------------------------------------------+

OP_CAT pops "100000" (top), then "BTC_USD=" (next), and concatenates as bottom || top. The full price-reading string materializes on-chain for the first time. BIP347's 520-byte ceiling is nowhere near approached — 14 bytes is well within bounds.

Step 2 — OP_SHA256: pop top, push its SHA256

+--------------------------------------------+
| d97200147349b678...b4ccc73                 |  <- SHA256("BTC_USD=100000") (32 bytes)
| e3e78a8f...83cfde                          |  <- sig
+--------------------------------------------+

This is the exact 32-byte digest the oracle signed offline. The hash is deterministic — given the same PART1 and PART2, it always produces the same MESSAGE_HASH.

Step 3 — OP_PUSHBYTES_32: push oracle pubkey from script

+--------------------------------------------+
| ff1f9fa3...9986b8                          |  <- oracle_pubkey (from script)
| d97200147349b678...b4ccc73                 |  <- MESSAGE_HASH
| e3e78a8f...83cfde                          |  <- sig
+--------------------------------------------+

The oracle pubkey arrives from the locking script, not the witness. It was committed at UTXO creation time. The spender cannot substitute a different key.

Step 4 — OP_CHECKSIGFROMSTACK: pop pubkey, message, sig — verify — push result

+--------------------------------------------+
| 01                                         |  <- TRUE
+--------------------------------------------+

OP_CSFS pops all three items (top-first: pubkey → message → sig) and runs BIP340 Schnorr verification:

verify: Schnorr(sig  = e3e78a8f...83cfde,
                msg  = d97200147349b678...b4ccc73,
                pub  = ff1f9fa3...9986b8)
result: VALID -> push 01

Script terminates with a single truthy value. The spend is valid.

Why the sig doesn’t cover the transaction

The oracle signed SHA256("BTC_USD=100000") — computed before the UTXO existed. The signature does not bind to input amounts, output addresses, or sequence numbers. Anyone who obtains this oracle signature can construct a spend with any output structure and pass the CSFS check, provided they also supply the matching fragments. This is not a flaw — it is the oracle pattern. The oracle attests to a fact about the world; what happens to funds after that attestation is a separate contract design question, typically addressed by combining CAT+CSFS with OP_CTV to lock the output destination alongside the oracle condition.

A Structural Boundary: Replay

In this experiment the oracle signs the string "BTC_USD=100000". Once the reveal transaction is on-chain, the (sig, PART1, PART2) triple is permanently visible in the witness. If a second UTXO existed with the same 7ea820...cc script — same oracle pubkey — that triple could be replayed against it. The fragments match, the hash matches, the sig verifies — the spend passes.

This is an oracle-gate contract behaving exactly as designed. The oracle attested to a real-world fact at a point in time. The attestation is inherently transferable to any UTXO that accepts it. If you want each oracle signature to be valid for exactly one spend, include UTXO-specific data in the fragments:

PART1 = b"BTC_USD=100000|txid="
PART2 = bytes.fromhex(txid)   # 32 bytes of the input UTXO's txid

Now SHA256(PART1 || PART2) commits to a specific UTXO. The oracle signs a UTXO-bound attestation. Replay is structurally closed.

IK+CSFS established who can authorize. CAT+CSFS establishes what the authorization covers and hands the message construction to the execution stack. Combining all three — IK to bind signer identity, CAT to build a spend-specific message, CSFS to verify — produces authorization with no replay surface at any layer.

Address Reconstruction with RootScope

The tapscript is 36 bytes: 7e (OP_CAT) + a8 (OP_SHA256) + 20 (OP_PUSHBYTES_32) + 32-byte oracle pubkey + cc (OP_CHECKSIGFROMSTACK).

The Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || 0x24 || script_bytes)
               (leaf version 0xc0, script length 36 = 0x24)
Merkle root  = TapLeaf hash
tweak t      = tagged_hash("TapTweak",  internal_pubkey || merkle_root)
output key Q = internal_pubkey + t*G
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

ORACLE_PUBKEY = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
script_bytes = bytes([0x7e, 0xa8, 0x20]) + ORACLE_PUBKEY + bytes([0xcc])

tapleaf_hash = tagged_hash(
    "TapLeaf",
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash
internal_pubkey = bytes.fromhex(
    "ff1f9fa326a9438227e6aa25030ccf89bcb8ce53db4f78dbce6146499d9986b8"
)
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1peaj5tna...csd84jel  [OK]

Notice: the same internal_pubkey (ff1f9fa3...9986b8) appears as both the TapTree construction key and the oracle pubkey embedded in the script. In this demo, the oracle and the UTXO creator are the same entity. In production these would typically be distinct — the internal key held by the contract operator, the oracle pubkey by an independent data provider.

RootScope Visual Output

Internal Key
  ff1f9fa3...9986b8
        |
    TapLeaf (0xc0)
    script: 7e a8 20 ff1f9fa3...9986b8 cc  (36 bytes)
                     ^--- oracle pubkey hardcoded in script
        |
    TapLeaf Hash
        |   (no siblings -> single-leaf tree)
    Merkle Root
        |
    TapTweak
        |
    Output Key Q  (parity: odd -> control block byte = c1)
        |
    P2TR Address
    tb1peaj5tna...csd84jel   [OK]

The control block opens with c1, consistent with the IK+CSFS experiment and different from the CAT, CSFS, and CTV solo experiments which all produced c0. Same internal key, 36-byte script, different Merkle root, different TapTweak value, different parity outcome.

Where CAT+CSFS Sits in the Series

Opcode(s) Script Witness Pubkey source Message source What it proves OP_CAT 7ea820...87 [part1, part2] n/a assembled Preimage reassembly OP_CSFS cc [sig, msg, pubkey] witness witness (static whole) Someone with given key signed this OP_CTV 20...b3 [] n/a n/a Spending tx matches template OP_INTERNALKEY cb20...87 [] context n/a Internal key equals expected IK+CSFS cbcc [sig, msg] context (UTXO) witness (static whole) UTXO owner signed the message CAT+CSFS **7ea820...cc** [sig, part1, part2] script assembled on-chain Oracle signed what the stack built

The series now spans two levels: solo experiments that characterize individual primitives, and combo experiments that explore how composition shifts the authorization surface. The next direction: combining all three axes — IK to bind signer identity, CAT to assemble a spend-specific message, CSFS to verify — producing authorization with no replay surface at any layer.

What We Built

We ran the second combo experiment: a 36-byte tapscript that pairs OP_CAT and OP_SHA256 with a hardcoded oracle pubkey and OP_CHECKSIGFROMSTACK. The oracle signed SHA256("BTC_USD=100000") offline — a price attestation with no knowledge of the transaction it would eventually authorize. At spend time, the witness supplied the signature and two fragments separately; the script assembled them on-chain, hashed the result, and verified the oracle's signature against the computed digest.

We built the TapTree with btcaaron's build_script(OP_CAT, OP_SHA256, push_bytes(ORACLE_PUBKEY), OP_CHECKSIGFROMSTACK), constructed the single-leaf TapTree, and derived the Signet address. The witness was [sig, PART1, PART2] — three items, no pre-assembled message, no pubkey. The spend used .unlock_with(_make_witness()).

Both transactions confirmed on Signet at 2026–03–21 12:24:18 UTC. RootScope verified the address derivation: the oracle pubkey appears in two roles — once as the TapTree’s internal key feeding the TapTweak derivation, once as a literal constant inside the 36-byte script. Same key, two roles, different derivation paths. Control block opens with c1: same odd-parity outcome as the IK+CSFS experiment, arising from a different Merkle root produced by the 36-byte script.

The replay boundary is real and deliberate: this oracle attestation is transferable to any UTXO that accepts the same oracle signature. Closing it requires encoding UTXO-specific data in the assembled fragments. That is the design space this experiment opens — not a limitation to apologize for, but a primitive boundary to build from.

One more boundary worth naming: in this demo the oracle pubkey and the TapTree’s internal key are the same key. The oracle is the contract creator. Separating them — an independent oracle pubkey embedded in the script, a different internal key controlling the key path — is the production design. The mechanism is identical; only the trust model changes.

Resources

Bitcoin Inquisition: github.com/bitcoin-inquisition
btcaaron toolkit: github.com/aaron-recompile/btcaaron
RootScope visualizer: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition 29.2 | Commit *[*926c40c1...008f*](https://mempool.space/signet/tx/926c40c1b72edb904a3bb7bf96795f351a6be597fc1aeab1390c15e0133b008f?showDetails=true) | Reveal [*75db54de...65ca2*](https://mempool.space/signet/tx/75db54dea1f125174699710bd5b517ae13b6e09b3293a0b0f463ea5561a65ca2?showDetails=true) | Confirmed 2026-03-21*

By Aaron Recompile on March 27, 2026.

Canonical link

Exported from Medium on July 3, 2026.

OP_CAT on Signet — Concatenation, Commitment, and Bitcoin Inquisition

aaron.recompile — Fri, 03 Jul 2026 02:47:44 +0000

Satoshi disabled it in 2010. We ran it on-chain in 2026.

Bitcoin is not designed top-down.  
It is discovered through execution.

"Run the Future" — starts here.

From Satoshi’s Disabling to Protocol Revival

OP_CAT is one of Bitcoin’s most storied disabled opcodes. In 2010, Satoshi Nakamoto silently removed it along with a handful of others, citing concerns about unbounded memory growth — a concatenated loop could theoretically produce a stack element of arbitrary size, opening a vector for denial-of-service attacks against nodes.

The irony is that OP_CAT is perhaps the most expressive primitive in Bitcoin Script. A single opcode — pop two stack elements, push their concatenation — unlocks a surprising range of constructions: introspection, covenants, STARK proof verification, cross-input signature binding. For over a decade, it sat dormant while developers found increasingly exotic workarounds.

BIP347 (proposed 2024) formalizes OP_CAT’s return under Tapscript, with a strict 520-byte limit on concatenated outputs. Bitcoin Inquisition 29.2 ships BIP347 as a soft fork active on Signet, making Signet the canonical testbed for OP_CAT experiments before any mainnet activation.

This post walks through a complete commit-reveal experiment conducted on Signet, implemented with the btcaaron toolkit and reconstructed visually with RootScope. The core contract is intentionally minimal: a split-preimage hash lock that proves OP_CAT's basic functionality while demonstrating the full Taproot script-path lifecycle.

One thing worth noting upfront: before block confirmation, reveal transactions may be absent from standard Signet mempools — not because of a network fork, but because of policy. Inquisition nodes accept the non-standard spend, mine it, and make it visible on public explorers post-confirmation. “Not seen yet” does not mean the network rejected it.

The Split-Preimage Contract

The classical hash-lock script commits to a preimage and requires the spender to reveal it:

OP_SHA256 <hash> OP_EQUALVERIFY OP_TRUE

The preimage is presented as a single stack element. OP_CAT introduces a twist: we can commit to a preimage that the spender must reconstruct on the fly by providing two separate pieces and concatenating them on-chain. This is the split-preimage pattern:

OP_CAT
OP_SHA256
OP_PUSHBYTES_32 <SHA256(part1 || part2)>
OP_EQUAL

In our experiment: part1 = "hello", part2 = "world", and the expected hash is SHA256("helloworld").

Why this matters beyond the toy example. The split-preimage pattern is the embryo of more sophisticated constructions. When you control what gets concatenated — for instance, a transaction field extracted via introspection alongside a known constant — you can enforce covenant behavior. OP_CAT turns the stack into a serialization engine. But we walk before we run.

The Contract Design

Secret split:  "hello" (0x68656c6c6f)  ||  "world" (0x776f726c64)
                                   |
                               OP_CAT
                                   |
                    "helloworld" (0x68656c6c6f776f726c64)
                                   |
                               OP_SHA256
                                   |
          936a185c...8f8f07af   (SHA256 of "helloworld")
                                   |
                         compare with committed hash
                                   |
                               OP_EQUAL -> TRUE

The tapscript bytecode is exactly:

7e                                               <- OP_CAT
a8                                               <- OP_SHA256
20                                               <- OP_PUSHBYTES_32
936a185caaa266bb9cbe981e9e05cb78cd732b0b3280eb944412bb6f8f8f07af
87                                               <- OP_EQUAL

Commit Phase: Building the Taproot Address with btcaaron

The commit transaction funds a Taproot output whose script path encodes the OP_CAT hash lock. We construct it as a single-leaf TapTree with the internal key controlling the key path.

Computing the Committed Hash

part1 = b"hello"
part2 = b"world"
committed_hash = hashlib.sha256(part1 + part2).digest()

# 936a185caaa266bb9cbe981e9e05cb78cd732b0b3280eb944412bb6f8f8f07af

Constructing the OP_CAT Script

OP_CAT is opcode 0x7e — disabled on mainnet, activated on Signet via BIP347. We define it explicitly and pass it to btcaaron's script builder:

OP_CAT = bytes([0x7E])

script_hex = build_script(
    OP_CAT,
    OP_SHA256,
    push_bytes(committed_hash),
    OP_EQUAL,
)
cat_leaf = RawScript(script_hex)
tap_tree  = (
    TapTree(internal_key=key, network="signet")
    .custom(script=cat_leaf, label="cat")
).build()

btcaaron API Highlights

**TapTree(internal_key, network)** initialises a Taproot tree builder. The internal_key is used as the key-path spend key and as the basis for the P2TR address derivation tweak.

**.custom(script, label)** attaches a raw script leaf to the tree under a human-readable label. The label is used later by .spend(label) to identify which leaf's control block to construct.

**.build()** finalises the tree: computes TapLeaf hashes, assembles the Merkle root (for a single leaf, the Merkle root is the TapLeaf hash), applies the BIP341 tweak Q = P + t*G where t = tagged_hash("TapTweak", P || merkle_root), and derives the Bech32m Signet address.

Funding the Address

txid = rpc_wallet("sendtoaddress", tap_tree.address, FUND_SATS / 1e8)

Reveal Phase: Spending with the Split Preimage

The reveal transaction spends the UTXO by supplying "hello" and "world" as separate witness stack elements, letting OP_CAT reassemble them on-chain before the hash check.

tx = (
    tap_tree.spend("cat")
    .from_utxo(fund_txid, vout, sats=FUND_SATS)
    .to(change_addr, OUTPUT_SATS)
    .sequence(0xFFFFFFFF)
    .unlock_with([
        part1.hex(),   # "68656c6c6f"  <- pushed first -> sits at stack bottom
        part2.hex(),   # "776f726c64"  <- pushed second -> sits at stack top
    ])
    .build()
)
reveal_txid = rpc("sendrawtransaction", tx.hex)

btcaaron Spend API

**.spend(label)** looks up the named leaf in the tree, constructs its control block (internal pubkey + optional Merkle path), and returns a transaction builder pre-configured for script-path spending.

**.unlock_with([...])** injects raw witness stack elements before the script and control block. Order matters: elements are pushed in list order, so the first element ends up deepest on the execution stack. In our case, "hello" lands at the bottom and "world" sits on top — exactly what OP_CAT expects.

The final witness for our single input:

Witness[0] = 68656c6c6f                  <- "hello"
Witness[1] = 776f726c64                  <- "world"
Witness[2] = 7ea820...8f8f07af87         <- tapscript (OP_CAT script)
Witness[3] = c050be5f...126bb4d3         <- control block

Transactions and Stack Trace

Commit: what lands on-chain

TxID: [084d5a9c...ecaada09](https://mempool.space/signet/tx/084d5a9c6a8c176c24edc0a8b7ce54ed65808a326367d8a9299b4460ecaada09?showDetails=true)

Timestamp     : 2026-02-12 09:52:48 UTC
Fee           : 155 sats  (1.01 sat/vB)
Features      : SegWit | Taproot | RBF

INPUT
  tb1pvzghpa...sqkluxcm    0.00250812 sBTC
OUTPUTS
  tb1p7lcpdk...8snhqmnc    0.00050000 sBTC  <- CAT lock UTXO
  tb1pmfwqkg...jsk55q8v    0.00200657 sBTC  <- change

The output tb1p7lcpdk...8snhqmnc is a standard P2TR address. An external observer sees nothing unusual — no hint that an OP_CAT script lurks in the script path. The commitment is invisible until revealed.

Reveal: witness data and stack execution

TxID: [00072d4a...b2d05656](https://mempool.space/signet/tx/00072d4aa354b5987eb8f2ffec440db7467b0581c5e845a6a0ef6999b2d05656?showDetails=true)

The Taproot interpreter strips the last two witness items (script + control block) and uses the remaining items as the initial execution stack.

Witness[0]  68656c6c6f
            <- "hello"

Witness[1]  776f726c64
            <- "world"
Witness[2]  7e a8 20 936a185c...8f8f07af 87
            <- tapscript: OP_CAT OP_SHA256 OP_PUSHBYTES_32 <hash> OP_EQUAL
Witness[3]  c0 50be5fc4...126bb4d3
            <- control block (leaf version 0xc0 + internal pubkey, no Merkle path)

The 33-byte control block confirms a single-leaf TapTree: no sibling hash, because the TapLeaf hash is the Merkle root.

Executing: OP_CAT OP_SHA256 OP_PUSHBYTES_32 <committed_hash> OP_EQUAL

Initial State: Witness[0] and Witness[1] loaded as execution stack

+--------------------------------------------+
| 776f726c64                                 |  <- "world"  (Witness[1], top)
| 68656c6c6f                                 |  <- "hello"  (Witness[0], bottom)
+--------------------------------------------+

Two separate byte strings. Neither alone matches the preimage hash; only their concatenation does.

Step 1 — OP_CAT: pop top two, push concatenation

+--------------------------------------------+
| 68656c6c6f776f726c64                       |  <- "helloworld" (10 bytes)
+--------------------------------------------+

OP_CAT pops "world" then "hello" (top-first) and concatenates as bottom || top. BIP347 enforces a 520-byte ceiling on the result — our 10-byte string is well within bounds.

Step 2 — OP_SHA256: pop top, push its SHA256

+--------------------------------------------+
| 936a185c...8f8f07af                        |  <- SHA256("helloworld") (32 bytes)
+--------------------------------------------+

The hash is deterministic. The spender cannot influence it without controlling the preimage composition.

Step 3 — OP_PUSHBYTES_32: push the committed hash from script

+--------------------------------------------+
| 936a185c...8f8f07af                        |  <- committed_hash (from script)
| 936a185c...8f8f07af                        |  <- computed_hash  (from Step 2)
+--------------------------------------------+

The script carries the expected hash as a 32-byte constant embedded at compile time.

Step 4 — OP_EQUAL: compare, push result

+--------------------------------------------+
| 01                                         |  <- TRUE
+--------------------------------------------+

Both hashes match. Script terminates with a single truthy value — spend is valid. Output destination: tb1p4ug2v8...zqwnmkrp 0.00049500 sBTC (V1_P2TR).

Why not OP_EQUALVERIFY + OP_TRUE?

Both produce the same consensus result here. OP_EQUAL leaves the boolean on the stack, while OP_EQUALVERIFY consumes it and aborts on failure. For a single-path terminal opcode, OP_EQUAL is idiomatic — clearer intent, one fewer byte. The on-chain bytecode (87) confirms this choice.

Address Reconstruction with RootScope

The real payoff of understanding Taproot internals is being able to independently reconstruct the P2TR address from its constituent parts, without trusting any external source. RootScope walks through the full derivation and renders each step visually.

The Derivation Chain

TapLeaf hash = tagged_hash("TapLeaf",  0xc0 || compact_size(len(script)) || script)
Merkle root  = TapLeaf hash              <- single leaf: no TapBranch needed
tweak t      = tagged_hash("TapTweak",  internal_pubkey || merkle_root)
output key Q = internal_pubkey + t*G    <- elliptic curve point addition
P2TR address = Bech32m("tb", Q.x_only)

Verification Code

tapleaf_hash = tagged_hash(
    "TapLeaf",
    bytes([0xc0]) + bytes([len(script_bytes)]) + script_bytes,
)
merkle_root = tapleaf_hash

internal_pubkey = bytes.fromhex(
    "50be5fc44ec580c387bf45df275aaa8b27e2d7716af31f10eeed357d126bb4d3"
)
tweak = tagged_hash("TapTweak", internal_pubkey + merkle_root)
Q    = Key.from_x_only(internal_pubkey).tweak_add(tweak)
addr = Q.to_p2tr_address(network="signet")
# Expected: tb1p7lcpdk...8snhqmnc  [OK]

RootScope Visual Output

Internal Key
  50be5fc4...126bb4d3
        |
    TapLeaf (0xc0)
    script: 7ea820...07af87
        |
    TapLeaf Hash
        |   (no siblings -> single-leaf tree)
    Merkle Root
        |
    TapTweak
        |
    Output Key Q
        |
    P2TR Address
    tb1p7lcpdk...8snhqmnc   [OK]

For multi-leaf trees, RootScope renders the full binary tree, highlights the Merkle proof path for any selected leaf, and shows where sibling hashes appear in the control block — indispensable for debugging spend failures caused by mismatched script indexes or incorrect tree ordering.

What Comes Next: CAT, CSFS, and CTV

This post is the first in a three-part series covering the opcode proposals currently co-activated on Signet via Bitcoin Inquisition. Each targets a different layer of the transaction:

Opcode BIP What it constrains Mechanism OP_CAT 347 Stack composition Concatenate two elements; enables serialization OP_CSFS 348 Signature scope Check a signature against an arbitrary message OP_CTV 119 Output template Commit the spend tx to a pre-defined hash

OP_CAT, as shown here, operates purely on the stack. It does not know what a transaction looks like — it just concatenates bytes. That is precisely why covenant designs need to combine it with introspection: CAT reassembles serialized transaction fields, and something else checks them.

OP_CSFS goes one step further: it decouples the message being signed from the transaction itself. A signature can be validated against any data on the stack, not just the current transaction hash. This opens the door to delegation schemes and cross-input commitments.

OP_CTV takes the opposite approach: instead of building up constraints from scratch, it commits the spending transaction to a pre-computed hash at UTXO creation time. The spender cannot deviate from the template — output addresses, amounts, and sequence numbers are all locked in. No introspection needed; the commitment is baked into the script.

The three opcodes are complementary. A covenant that validates a transaction’s output structure might use CTV for the simple fixed-template case, or CAT + CSFS for a more dynamic one where the template is computed at runtime. Next post: OP_CSFS on Signet — what it takes to sign something other than the current transaction.

What We Built

We designed a split-preimage hash lock under Taproot’s script path, implemented it with btcaaron's TapTree / RawScript / .custom() / .unlock_with() chain, and broadcast both the commit and reveal transactions on Signet. The reveal witness puts "hello" and "world" on the stack as two separate items; OP_CAT reassembles them before the SHA256 check fires.

We then used RootScope to walk the derivation in reverse: starting from the raw script bytes and the internal key, we recomputed the TapLeaf hash, the Merkle root, the TapTweak, and the output key — arriving at the same tb1p7lcpdk...8snhqmnc that received the commit funds. That chain of trust, from script to address, is what makes Taproot's script-path commitments verifiable and auditable without any external authority.

Both transactions are permanently confirmed on Signet. The experiment is reproducible end-to-end using the tools linked below.

Resources

Bitcoin Inquisition: github.com/bitcoin-inquisition
btcaaron toolkit: github.com/aaron-recompile/btcaaron
RootScope visualizer: github.com/aaron-recompile/rootscope

Signet | Bitcoin Inquisition | Commit *[*084d5a9c...ecaada09*](https://mempool.space/signet/tx/084d5a9c6a8c176c24edc0a8b7ce54ed65808a326367d8a9299b4460ecaada09?showDetails=true) | Reveal [*00072d4a...b2d05656*](https://mempool.space/signet/tx/00072d4aa354b5987eb8f2ffec440db7467b0581c5e845a6a0ef6999b2d05656?showDetails=true) | Confirmed 2026-02-12*

By Aaron Recompile on March 16, 2026.

Canonical link

Exported from Medium on July 3, 2026.