QSB Config A · the mainnet spend · what every signature commits to
QSB Spend Anatomy
The transaction that spent the first QSB vault, taken apart at the level the script never sees: which bytes each of its 25 signatures is hashed over, which of those bytes the grind searched, and what changes if any field moves. Every sighash and every signature on this page was recomputed and verified here.
The transaction
Two inputs, one output. The vault is input 1; the helper pays the fee and is the only ordinary key the spend exposes.
Every byte
The 1,403 serialised bytes. Hover a segment. The two marked fields are the pinning search space.
Finality
Fields the script cannot read but the network enforces. A spend that is valid and not final reveals its preimages for nothing.
25 signatures, 25 messages
Pick a site. Left: what Core checked. Right: the exact preimage it hashed.
Change one field, which signatures break
Computed by recomputing all 25 messages under each mutation. Filled = message changes, so the signature at that site would need a new grind or a new key.
What the matrix says
- Seven sites bind the transaction: the helper witness, the three fixed signatures (SIGHASH_ALL), and the three puzzle hashes. Change the output, the locktime, the vault sequence or the version and all seven messages move.
- Eighteen sites are constants. Every dummy signature is SIGHASH_SINGLE with the vault at input index 1 and one output, so Core's legacy code returns the constant 1 as the message. Their pubkeys never depend on the transaction and need no grind.
- Two mutations break the constants: adding a second output, or putting the vault first. Both make index 1 point at a real output. This is the SIGHASH_SINGLE index rule the multi-output work proved on regtest, seen here from the artifact side.
- Round 2's puzzle ignores the helper. Its hash ends in 0x93, which sets ANYONECANPAY. The puzzle signatures carry whatever hashtype byte their hash happens to end in; Core treats undefined base types as ALL.
Where the binding actually lives
The fixed signature in each multisig is hashed over the script minus its own push and the nine chosen dummy pushes: 9,776 bytes in round 1, 9,777 in round 2, not 9,923. That deletion is how the choice of nine indices reaches the sighash, the recovered pubkey, and the puzzle. Anyone who recomputes these sighashes from the raw script gets a different number.
The pinning signature at element 2 is hashed over 9,866 bytes: the script minus one 57-byte push. Its recovered pubkey is what the pinning grind searched over sequence and locktime to make hash into a valid DER signature.
The digest
Nine indices per round out of 150. Filled: preimage revealed and checked. Hollow: bonus slot, dummy signature only.
Verified on this page
- Transaction parsed from raw bytes; the recomputed txid equals the on-chain txid.
- All 25 sighashes recomputed: 24 with Core's legacy algorithm including FindAndDelete and the SIGHASH_SINGLE index rule, 1 with BIP143 for the P2WPKH helper.
- All 25 signatures verified with pure-Python secp256k1 against the witness pubkeys; curve constants checked on-curve. Pubkey recovery reproduces every legacy pubkey, including two where R.x is r plus the curve order.
- Strict DER (BIP66) holds on all 25 signatures, including the three 32-byte hashes used as signatures.
Not verified on this page
- That these are the only witnesses the script accepts. That is the accepting-set statement, layer A.
- That the puzzle is expensive enough. That is the concrete-security argument, layer B.
- Relay. This transaction is non-standard in five independent ways and reached its block through a miner directly.