QSB Config A · bare legacy script · one execution path

QSB Script Trace

Every opcode of the vault script, executed against the real mainnet witness. 880 script elements, 57 witness elements, no branches. The stack is exact at every step; the hash checks are recomputed here; the 24 ECDSA checks are Bitcoin Core's to verify.

Consensus budgets

Legacy limits: 201 non-push opcodes with the CHECKMULTISIG key surcharge, 10,000 script bytes, 1,000 stack items

The tape

One column per script element, coloured by phase. Click anywhere to inspect.

Stack depth and opcode budget

Depth after each element against the 1,000 ceiling; opcode count against 201.

Step through the path

Left: stack before. Right: stack after. Depth 0 is the top.

Story mode

Stops follow the real spend. Use the stepper below to wander off the path; the story picks up where you left it.

← → step · shift for ×10

BEFORE

AFTER

One round, anatomised

Round 1, select 1, with the values from the mainnet witness. Round 2 repeats the shape with 7 checked slots and 2 bonus slots.

Load the pool

PUSH20 ×150 commitments C1…C150
PUSH9 ×150 dummy signatures S1…S150
OP_0 multisig dummy
PUSH56 fixed signature F2

302 elements, zero opcodes. Each commitment is HASH160 of a secret preimage the vault owner holds. Each dummy signature is a valid 9-byte DER signature for some pubkey the spender will compute. Stack climbs to 357.

Select one index (×8)

<302> ROLL index I18 = 12 to top
<152> MIN clamp: min(12,152)
DUP <151> ADD ROLL depth 163 → C140
<311> ROLL preimage X15 to top
HASH160 EQUALVERIFY C140 == HASH160(X15)
ROLL depth 12 → dummy S140 to top

13 elements, 9 opcodes. The spender's index reaches its commitment and its same-numbered dummy signature through fixed offsets. The preimage proves ownership; the dummy signature becomes one of the ten the multisig will check, and so gets deleted from the scriptCode before the sighash.

MIN with 152: our reading is a bounds clamp so an out-of-range index cannot roll outside the pool. D1 confirms.

Puzzle, then 10-of-10

DUP SHA256 hash of pubkey K13 = a "signature"
<305> ROLL CHECKSIGVERIFY K12 must validate it
OP_10 (K13…K22 rolled up) OP_10
CHECKMULTISIG F2 + 9 dummies vs 10 pubkeys

The 32-byte hash must parse as strict DER with a recoverable r. Random bytes do that with probability 2^-46.01 per recovery (Core-verified kernel predicate, r or r+N; 2026-09-11 recompute). That failure rate is one factor of the grind. Every pubkey in the round is recovered by the spender from the sighash, so the chosen subset is bound to this exact transaction.

What this page verifies, and what it does not

Verified here: tokenisation, stack effects, Core's opcode count rule, element and stack limits, and the 15 HASH160 preimage checks (all 15 match on the mainnet witness).
Not verified here: the 24 ECDSA checks (2 pinning, 2 puzzle, 20 inside the two 10-of-10 multisigs) and the sighash. These are assumed to pass; Bitcoin Core on regtest is the oracle, and the mainnet block is the proof.
Model, not oracle. This tracer shares no code with qsb-ingest or the pipeline. Its totals agree with the repo's stated 201 opcodes, 9,923 bytes and 615 peak stack, and with the registrar's independent count.

The two quirks the path uses

Key recovery. For any signature bytes and any sighash there is exactly one pubkey that validates, and the spender can compute it. Every pubkey in the witness is such a recovered key, so CHECKSIG becomes a transaction-hash oracle inside Script.

FindAndDelete. Legacy CHECKMULTISIG deletes the signatures it checks from the scriptCode before hashing. Choosing 9 of 150 dummies changes the sighash, so the recovered pubkeys, so the puzzle. The choice is the digest; the preimages sign it.