Transaction Introspection Without Soft Forks
Binohash by Robin Linus — reading transaction data from inside Bitcoin Script
RL
Robin Linus · creator of BitVM
THE PROBLEM
Bitcoin Script can verify signatures, but it cannot inspect the transaction itself. A script has no way to ask "what outputs does this transaction create?" or "what value is being sent where?" This means you can't build covenants — rules that constrain how coins can be spent in the future.
WHAT SCRIPT CAN DO
Verify signatures via
OP_CHECKSIG. Confirm "this key authorized this spend." But that's opaque — the signed message (the tx) is a black box.WHAT WE WANT
Read the transaction's outputs, amounts, timelocks — inside Script. This enables vaults, covenants, bridges, and programmable spending rules without trusting anyone.
PROPOSED OPCODES (REQUIRE SOFT FORKS)
OP_CTV (BIP-119), OP_TXHASH, OP_CAT, OP_CHECKSIGFROMSTACK — all require consensus changes that have been debated for years. Binohash achieves a form of transaction introspection with the existing opcodes, no fork needed.Core Primitive: FindAndDelete in Legacy OP_CHECKMULTISIG
WHAT BINOHASH ACTUALLY USES
Binohash's main primitive is not "one bit per DER length". The core trick is legacy
OP_CHECKMULTISIG's FindAndDelete behavior: selected signatures are removed from scriptCode before sighashing, so different selected subsets produce different sighashes.SUBSET-SELECTED NONCE SPACE
locking script: n embedded sig blobs
→
unlocking script reveals t indices
→
OP_ROLL + OP_CHECKMULTISIG
FindAndDelete removes selected sigs from scriptCode
→
different subset => different sighash
C(n,t)
subset count per roundlog2 C(n,t)
bits of nonce entropyPAPER PARAMETERS
Round space:
n=120, t=8 gives C(120,8) ≈ 2^39.6 options per round. Two rounds provide ~2^79.2 index-space combinations. Those indices are directly readable in Script and form the Binohash digest material.IMPORTANT SCOPE
This relies on legacy Script semantics where FindAndDelete exists. SegWit v0 and Tapscript sighashing do not use this same behavior, so this construction targets a narrow script environment.
Protocol Flow: Pin, Extract, Extract
1
Stage 1: Transaction Pinning
Use 4 signature puzzles (each
W1 bits) so mutating the transaction requires expensive re-grinding. This binds later nonce extraction to a specific transaction context.2
Stage 2 Round 1: Subset Nonce Extraction
Choose a subset of
t indices from n embedded signatures. FindAndDelete yields a unique sighash candidate; grind puzzle signature work W2 for a valid hit.3
Stage 2 Round 2: Independent Extraction
Repeat extraction with a second independent signature pool. Concatenate both index sets to form the final digest components.
4
Output and Verify In Script
Script verifies subset membership + puzzle checks and can read the chosen indices directly from witness data. This provides Script-readable transaction digest material without new opcodes.
SECURITY (PAPER TARGET)
With
W1=W2=42 and two rounds, the paper reports roughly 83-84 bits collision resistance and ~44.6 bits honest work.COST PROFILE
Large/complex legacy script, significant grinding, and non-standard relay profile. It is a feasibility result, not a wallet-friendly covenant primitive.
Worked Example: Toy Two-Round Binohash
Toy parameters for intuition: n=6, t=2 per round (not secure)
TOY SETUP
Each round selects 2 indices out of 6. That gives
C(6,2)=15 possible subsets (~3.91 bits) per round. Two rounds give 15 × 15 = 225 combinations (~7.81 bits total).ROUND OUTPUTS (TOY)
Round 1
i
selected subset: {1,4} from pool A
15 options
Round 2
i
selected subset: {0,5} from pool B
15 options
TOY DIGEST MATERIAL:
[01,04 | 00,05]
space = 225 = 2^7.81
SCRIPT SHAPE (HIGH LEVEL)
// Round j: select subset indices with OP_ROLL
// OP_CHECKMULTISIGVERIFY triggers FindAndDelete-based sighash variation
// Then verify puzzle work for this round:
OP_SIZE <target_len> OP_EQUALVERIFY <puzzle_pk_j> OP_CHECKSIGVERIFY
// Repeat for round 2, then use concatenated indices as Binohash output
PRODUCTION-SCALE NUMBERS (PAPER)
n=120, t=8 per round gives ~2^39.6 space per round (~2^79.2 two-round). Combined with Stage-1 pinning work, this reaches ~83-84 bits collision resistance in the paper's baseline configuration.What This Enables
COVENANTS WITHOUT SOFT FORKS
If Script can derive transaction-bound digest material, it can enforce committed transaction structure. That is the covenant direction Binohash points to. The mainnet PoC shows this is possible today under constrained, non-standard legacy conditions.
Vaults
Time-locked withdrawal patterns where coins must go to a staging address first, enabling cancellation of unauthorized spends.
State Machines
Enforce transaction chains — each output commits to the next valid state, enabling on-chain protocols and contracts.
Bridge Constructions
Cross-chain bridges that can verify Bitcoin transaction properties inside Script, relevant to the BitVM ecosystem.
Spending Conditions
Restrict outputs to specific addresses or amounts — "these coins can only go to address X with value Y."
PRACTICAL LIMITATIONS
The paper's baseline construction is still heavy: roughly 8 kB locking script (including about 240 minimum-sized signatures + 240 HASH160 commitments) and a transaction around ~10 kB. It works, but is expensive and non-standard.
PROVEN ON MAINNET
Robin Linus published a mainnet proof-of-concept transaction demonstrating a reduced Binohash instance in production (4-byte output). It validates the protocol mechanics and Script readability of the derived output.
MARA SLIPSTREAM SUBMISSION
The proof-of-concept transaction is highly non-standard and would be rejected by default mempool relay policy. It was submitted through MARA's Slipstream service, which allows miners to accept non-standard transactions directly. MARA's node was specifically configured to accept this transaction. This highlights an important nuance: non-standard ≠ invalid. The tx is fully consensus-valid, just not relayed by default policy.
INTERACTIVE EDUCATIONAL SITE
An interactive educational site has been created to help visualize how Binohash works step by step, including signature-puzzle grinding and protocol flow.
ROBIN LINUS PATTERN
This follows the same creative DNA as BitVM — finding unexpected capabilities hidden in Bitcoin's existing rules. Rather than waiting for new opcodes, Linus exploits what already exists. BitVM used hash locks and Taproot composition; Binohash combines FindAndDelete subset extraction with signature puzzles.
IN HIS OWN WORDS
"I hope Core Devs will hate Binohash so much, they will finally get their shit together and enable a softfork."
— Robin Linus. The subtext: Binohash is intentionally ugly. It works, but a purpose-built opcode (OP_CTV, OP_CAT) would be orders of magnitude more efficient. The proof of concept is a provocation — demonstrating demand for introspection primitives.