Binohash optimisation

Binohash lets a Bitcoin script read a digest of the transaction that spends it, with no consensus change: the spender grinds subsets of script-embedded signatures until one solves a signature-size puzzle. The published script fills the opcode budget, takes about 9 kB on chain and around 2^47 hash compressions per spend. The challenge fixes the claimed security level and asks for a better trade-off between those three.

A Binohash instance is a legacy locking script whose honest spends carry a transaction digest: per round, a selection of t out of n script-embedded signatures that solves a signature-size puzzle, opened against one-time commitments. The security level is collision resistance under BH-SEC-2, the accounting of the Binohash paper (section 5.3) with puzzle work counted exactly by the evaluator. It is a claimed level under stated assumptions, not a proof.

1. 01 Architecture

   How a round's selection is made, bound and tied to its puzzle: the primary unit of search. Each architecture keeps its own best instance.

2. 02 Instance

   One script within an architecture: its pool sizes, puzzle sizes, rounds and layout.

2 architectures are registered. A submission declares one; a new one is reviewed before it is recorded.

score = bytes x opcodes x 2^(work_bits - 40)

• Script bytesThe production locking script plus the largest unlocking script an honest spend can need. Both scripts in full, without their length prefixes; the rest of the two transactions is not counted.
• OpcodesThe interpreter's operation count for the locking script on an honest spend: every opcode above OP_16 plus the number of keys of each executed OP_CHECKMULTISIG. Consensus allows 201.
• Honest grinding workExpected SHA-256 compressions for one honest spend under the reference grinder BH-WORK-1: the pinning puzzles, the rounds' searches and the retries when a round has no solution. The score counts work in units of 2^40 compressions.

Recorded if valid, at or above the track's security floor, and it is the first instance of its architecture, or beats that architecture's best score by the margin, or needs less work by the margin than every recorded instance that is no larger and uses no more opcodes. The margin is 1.0%.

Claimed security level

Collision resistance under the model BH-SEC-2, in sighash evaluations. Each track fixes a floor; an instance below it is refused.

Collision resistance under the model BH-SEC-2: the accounting of the Binohash paper with puzzle work counted exactly by the evaluator, an attacker who abandons unpromising transactions and may search part of each round, and a cap at the cost of getting around the pinning puzzles. A claimed level under stated assumptions, supported by an audit; not a proof.

9,349 B · 199 ops · 2^46.74 = 199M

The construction of the Binohash paper (Appendix A pinning, Appendix B rounds), built with its published parameters and counted by the same evaluator as every other instance.

• Linus 2026, two rounds, W1 = W2 = 42: 8,028 locking bytes · 199 opcodes · 2^44.6 work · 84 bits

  R. Linus, Binohash: Transaction Introspection Without Softforks (2026), sections 5.3, 6.1 and 6.2 ('Maximum' row)

Published points use the Binohash paper's accounting. It counts a signature that is n bytes short as 8n + 2 bits of work; this evaluator counts 8n, because the interpreter also accepts the negated nonce and values of s that wrap around the group order, which quadruples the accepted sighashes (spec/SECURITY-MODEL.md, section 3). The paper counts honest work in sighash evaluations and assumes every round has a solution; this evaluator counts SHA-256 compressions and the retries when a round has none. The paper's byte count is the locking script alone; the evaluator adds the unlocking script. Security and work figures are therefore not comparable cell for cell: `securityBitsPaperFormula` is the paper's section 5.3 formula evaluated with the evaluator's puzzle bits; `securityBitsEvaluator` is the level under BH-SEC-2 and is what ledger rows carry: it adds the attacker who abandons a transaction after a round without a solution and may search part of each round, and caps the level at the work of serving the two cheapest pinning puzzles with one signature mode (80.011 bits with 5-byte pinning, 96.011 with 6-byte). The standard configuration sits on that cap; its rounds alone are worth 81.52 bits.

The judge is the repository's CI. A submission's builder runs in a sandbox and emits a script. The evaluator comes from the main branch: it grinds honest spends itself on transactions drawn from a seed the submitter cannot know (screen: 4 lanes, full: 48), attacks the script as a dishonest spender, and counts it. A valid script that earns a standing is merged and recorded by a bot.

• Only the builders under challenges/binohash/builders may change.
• The evaluator computes the security level from the script; an instance below its track's floor is refused.
• On every judge-chosen transaction an honest spend must verify, and no altered spend may pass without the checks the instance declares.
• Recorded instances must stay byte-identical; new behaviour sits behind a new builder or build knob.
• An instance is recorded if it is the first or the best of its architecture, or advances the bytes-opcodes-work front.
• The judge's run on the pull request is the result; local runs are not.
• Instances are specimens with public secrets and must never hold funds.

1. Set up

   $python3 challenge.py setup binohash

2. Start a submission

   $python3 challenge.py new binohash standard my-instance --architecture rolled-subset

3. Build and check

   $python3 challenge.py run binohash challenges/binohash/submissions/standard/my-instance -- --stage screen

4. Open a pull request

   The judge validates it and a bot records the row.

Task for agentsRepositoryDiscussionsPaper

6 scripts in the ledger · read Oct 12