Bitcoin Script vs Ladder Script

1. Vault with Clawback

Hot key spends after a delay. Cold key sweeps immediately.

Bitcoin Script (OP_VAULT proposal)

OP_VAULT <recovery-spk> <delay> <target-hash> Requires: BIP-345 soft fork (not activated) Recovery: OP_VAULT_RECOVER Unvault: separate tx to OP_UNVAULT output Trigger: reveal target outputs, wait delay 4 opcodes, 2 transactions minimum

Not available BIP-345 is proposed but not activated on mainnet.

Ladder Script

ladder(vault_lock(@recovery, @hot, 144)) Recovery key: sweeps immediately (no delay) Hot key: signs + waits 144 blocks 1 block type, 1 transaction Descriptor: vault_lock(@recovery, @hot, 144)

Native Single block type. Works on signet today.

Ladder Script: Built-in vault primitive. No multi-transaction ceremony. Recovery is one signature, not a separate recovery transaction.

2. Hash Time-Locked Contract (Atomic Swap)

Claim with preimage + signature, or refund after timeout.

Bitcoin Script

OP_IF OP_SHA256 <hash> OP_EQUALVERIFY <receiver-pubkey> OP_CHECKSIG OP_ELSE <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP <sender-pubkey> OP_CHECKSIG OP_ENDIF 11 opcodes, stack manipulation, branching Witness: choose IF or ELSE path + data

Works but fragile Script execution is path-dependent. Both branches visible on-chain.

Ladder Script

ladder(or( htlc(@receiver, @sender, <preimage>, 144), and(sig(@sender), cltv(900000)) )) 1 compound block + 1 fallback rung Merkelised: only spending rung revealed Descriptor: htlc(@receiver, @sender, hex, 144)

Native HTLC is a single compound block. Unrevealed rung stays private (MLSC).

Ladder Script: HTLC as one typed block. No IF/ELSE branching. Only the spending path is revealed on-chain — the refund path stays private.

3. Rate-Limited Wallet

Cap how much can be spent per block, even if the key is compromised.

Bitcoin Script

Not possible with Bitcoin Script. No opcode inspects spending rate across blocks. OP_CHECKTEMPLATEVERIFY can constrain a single spending transaction but cannot enforce per-block rate limits over time. Workaround: pre-signed transaction chains (requires trust + key management)

Not possible No mechanism for cross-block spending rate enforcement.

Ladder Script

ladder(and( sig(@owner), rate_limit(200000, 1000000, 10) )) Max 200k sats per block Accumulation cap: 1M sats Refill: 10 blocks Descriptor: rate_limit(200000, 1000000, 10)

Native RATE_LIMIT is a single block type. Enforced at consensus.

Ladder Script: Native rate limiting. If your key is compromised, the attacker can only drain at the rate you set. Bitcoin Script has no equivalent.

4. Dollar-Cost Averaging Covenant

A UTXO that can be spent exactly 12 times, splitting off a fixed amount each time.

Bitcoin Script

Not possible without OP_CAT + CTV. Recursive covenants require introspecting the spending transaction's outputs. OP_CTV alone can pre-commit one template. OP_CAT (not activated) could enable generalized covenants but with unconstrained recursion depth. No bounded recursion primitive exists.

Not possible Requires covenant opcodes not available on mainnet.

Ladder Script

ladder(and( sig(@owner), amount_lock(50000, 100000), recurse_count(12) )) Count decrements each spend Terminates at 0 (free spend) Output must carry same conditions Descriptor: recurse_count(12)

Native Bounded recursion with automatic termination. No unbounded loops possible.

Ladder Script: Recursive covenants are first-class. Bounded by max_depth or countdown. No OP_CAT needed. The evaluator enforces that outputs carry the correct mutated conditions.

5. Dead Man's Switch (Inheritance)

Owner spends normally. If inactive for ~6 months, heir can claim.

Bitcoin Script

OP_IF <owner-pubkey> OP_CHECKSIG OP_ELSE <26000> OP_CHECKSEQUENCEVERIFY OP_DROP <heir-pubkey> OP_CHECKSIG OP_ENDIF Works but reveals both branches. No way to "reset" the timer without moving funds to a new UTXO.

Works Functional but both paths visible. No built-in timer reset.

Ladder Script

ladder(or( sig(@owner), and(csv(26000), sig(@heir)) )) Owner path: immediate, private Heir path: 26,000 blocks (~6 months) Only spending path revealed (MLSC) Timer resets on each owner spend

Native Same logic, but only the used path is revealed. Unrevealed rung stays private.

Ladder Script: Same inheritance logic, but with MLSC privacy. The heir path is never revealed unless used. With RECURSE_SAME, each owner spend resets the timer and re-encumbers with identical conditions.

6. Post-Quantum Key Migration

Use a classical key daily, with a post-quantum fallback for long-term security.

Bitcoin Script

Not possible. Bitcoin Script has no post-quantum signature verification opcodes. No soft fork proposal adds PQ support. Migration requires a hard fork or a new address type + opcode.

Not possible No PQ signature verification in Bitcoin Script.

Ladder Script

ladder(or( sig(@daily), sig(@pq_backup, falcon512) )) Daily spending: Schnorr (32-byte key) Recovery: FALCON-512 (897-byte key) Also: falcon1024, dilithium3, sphincs_sha Same descriptor notation, same RPC

Native PQ schemes are a 1-byte SCHEME field change. No new opcodes needed.

Ladder Script: Post-quantum support is built into the signature verification. Change one byte (the SCHEME field) to switch from Schnorr to FALCON-512, DILITHIUM3, or SPHINCS+. No new opcodes, no hard fork.

7. Governance-Gated Treasury

2-of-3 multisig + output must go to a specific address + max tx weight.

Bitcoin Script

OP_2 <pk1> <pk2> <pk3> OP_3 OP_CHECKMULTISIG Multisig: yes. Output constraints: not possible. Weight limits: not possible. Epoch gates: not possible. Bitcoin Script cannot inspect the spending transaction's outputs, weight, or block height modulo.

Partial Multisig works. Output/weight/epoch constraints don't exist.

Ladder Script

ladder(and( multisig(2, @dir_a, @dir_b, @dir_c), output_check(0, 1000000, 4294967295, <hash>), weight_limit(65536), epoch_gate(100, 100) )) Multisig + output constraint + weight limit + epoch window All in one rung, all enforced at consensus

Native Transaction-level constraints are first-class block types.

Ladder Script: OUTPUT_CHECK, WEIGHT_LIMIT, INPUT_COUNT, OUTPUT_COUNT, EPOCH_GATE, and RELATIVE_VALUE are all native block types. Bitcoin Script has no transaction introspection beyond signature verification.

8. Batch Payment (100 recipients)

Pay 100 different recipients in a single transaction.

Bitcoin Script (P2WPKH)

100 P2WPKH outputs in one tx Each output: 31 bytes (8 value + 23 SPK) Per-output cost is paid in full on-chain Transaction vsize: 3,179 vB Fee at 10 sat/vB: 31,790 sats

Linear cost Every recipient pays for full SPK + value bytes.

Ladder Script (MLSC)

100 leaves merkelised into one root On-chain SPK: 33 bytes (0xDF || 32B root) Per-leaf data is revealed only on spend Transaction vsize: 911 vB Fee at 10 sat/vB: 9,110 sats ≈ 3.5× smaller (P2WPKH) / 4.8× (P2TR)

Native Outputs collapse into one Merkle root. Recipients verify their leaf with a Merkle path.

Ladder Script: Same payment, 3.5× smaller. The economic model flips — large fan-out becomes the cheap path, not the expensive one.

9. UTXO Chainstate Footprint

How much RAM each unspent coin occupies on every full node, forever.

Bitcoin Script

P2WPKH: 24 bytes per coin (compressed) P2TR: 36 bytes per coin (compressed) Each output adds permanent RAM cost Chainstate currently > 9 GB and growing UTXO bloat is the dominant scaling concern

Permanent cost Every UTXO sits in RAM until it is spent.

Ladder Script (MLSC)

3 bytes per coin (compressed) Conditions live in the witness, not the UTXO Synthetic root vout (MLSC_ROOT_VOUT) holds the 32-byte root, but per-leaf coins are represented as a one-byte tag + index 8–12× smaller chainstate footprint

Native Conditions are revealed at spend, not stored at creation.

Ladder Script: A 100-leaf MLSC output costs ~3 B per coin in chainstate vs 24 B for P2WPKH. Across millions of coins this is the difference between a ~9 GB and a sub-GB chainstate.

10. Lightweight Post-Quantum Batches

Spend N inputs each guarded by a FALCON-512 signature.

Bitcoin Script

No PQ verification opcodes exist. Hypothetical: N independent FALCON sigs Each sig: 666 bytes Each pubkey: 897 bytes ~700 vB per input, no amortisation 100 inputs → ~70,000 vB Exceeds standard relay (100,000 vB cap soon)

Not possible No PQ opcodes; even if added, every input pays full sig cost.

Ladder Script (PQ_BATCH)

Anchor input carries one FALCON signature bound to the entire batch. Subsequent inputs reference the anchor with H(falcon_pubkey) only. Anchor: ~392 vB (FALCON witness, SegWit-discounted) Non-anchor: ~14 vB per input 100 inputs → ~1,778 vB total ≈ 17.8 vB per input (mean) ≈ 22× cheaper than per-input FALCON sigs

Native One signature, N spends. Anchor ordering enforced at consensus.

Ladder Script: PQ_BATCH (block 0x0A03) makes post-quantum signatures economically viable for high fan-in spending. Without batching, FALCON-protected wallets would be priced out of consolidation.

11. Multi-Party Atomic Settlement (QABIO)

N parties co-spend their inputs in a single atomic transaction.

Bitcoin Script (CoinJoin / FROST)

CoinJoin / FROST workflow: 1. Off-chain coordinator collects intents 2. Round-trip nonce exchange (multiple) 3. Aggregate signature construction 4. Broadcast + monitor for double-spends 5. On failure: restart from step 1 Liveness depends on coordinator; any drop-out aborts the round.

Off-chain protocol Atomicity through coordination, not consensus.

Ladder Script (QABIO)

Each party publishes a QABI_PRIME UTXO with their batch_id commitment. At settlement: one tx with N QABI_SPEND inputs, all bound to the same batch_id. Atomicity: enforced at consensus ~143 vB per cosigner at N=100 ≈ 139 vB at N=500+ (asymptote) Drop-outs cannot block the rest of the batch

Native Batch atomicity is a consensus rule, not a coordination protocol.

Ladder Script: QABIO turns multi-party batching into a primitive. No coordinator round-trips, no liveness assumption — the only failure mode is “this batch did not confirm,” which is the same failure mode as any other tx.

12. Lightning Anchor — Anti-Pinning

Bound the fee rate of an anchor output so it cannot be RBF-pinned by an adversary.

Bitcoin Script (current LN anchors)

Anchor output: tiny P2WSH covenant with no fee-rate constraint. Pinning attack: Attacker spends anchor at low fee + attaches a long, low-fee descendant. Honest party cannot RBF efficiently because mempool policies cap rate bumps. Mitigations exist but are mempool-policy.

Policy-only No consensus-level fee bound on anchor spends.

Ladder Script (ANCHOR_FEE)

ladder(anchor_fee( @local, @remote, 10, // min_fee_rate (sat/vB) 1000, // max_fee_rate (sat/vB) 4000, // max_weight (WU) N // commitment_number )) Spend tx's 2-of-2 sig must clear, fee rate must lie in [min, max], weight bounded by max_weight. Enforced at consensus, not policy.

Native Anchor spends carry their own fee-rate envelope.

Ladder Script: ANCHOR_FEE removes pinning as an attack class. The attacker cannot attach a low-fee child because the spend tx itself must clear min_fee_rate.

13. PTLC vs HTLC (Lightning routing privacy)

Conditional payment without leaking a hash linker across the route.

Bitcoin Script (HTLC)

OP_SHA256 <H> OP_EQUALVERIFY ... Same hash H is reused on every hop Surveillance can correlate hops by H Wormhole attack: intermediate node steals fees by skipping the next hop Privacy depends on Tor + onion routing

Linkable Same hash on every hop — observable on-chain if any hop closes.

Ladder Script (PTLC)

ladder(or( ptlc(@receiver, 144), and(sig(@sender), cltv(900000)) )) PTLC: single signing key + CSV refund. The adaptor point T = t·G is off-chain only; each hop uses a different P_i so on-chain spends are not linked by a shared hash. Adaptor sig reveals scalar t_i — not H.

Native PTLC block uses point-locked adaptor signatures, not preimage reveal.

Ladder Script: PTLC is a typed block, not a script template. Each hop's point is independent, so the route is unlinkable even if multiple force-close txs land on-chain.

14. Accumulator Set Membership (whitelist of up to 16 entries)

Commit to a small enumerated set on-chain; spend by proving an element is in the set, without revealing the rest.

Bitcoin Script (P2SH OR-of-N)

OP_IF <pk1> OP_CHECKSIG OP_ELSE OP_IF <pk2> OP_CHECKSIG OP_ELSE ... Witness reveals every alternative pubkey inside the redeem script when spent — the unused branches are visible on-chain and contribute to the script-size cap. P2WSH/Taproot script trees help, but each leaf still embeds the full key.

Linear / leaky Every alternative pubkey is materialised in the redeem script or as a Tapscript leaf.

Ladder Script (ACCUMULATOR + SIG)

ladder(and( accumulator(<set_root>), sig(@spender) )) Conditions store: 32-byte set root only. Witness reveals: element_id (1-4 B NUMERIC) + Merkle path (32 B per level, depth ≤ 4). Per-tx caps: 1 ACCUMULATOR per rung, 2 per transaction. Tree depth is capped at 4 — the set holds up to 2⁴ = 16 entries; element_id is the per-leaf tag (range 0–65535).

Native ACCUMULATOR holds the set root; spender reveals only its element_id and the path to the root.

Ladder Script: ACCUMULATOR commits a Merkle root over a small enumerated set (up to 16 entries) and proves membership in O(log N) bytes. Pair with a SIG/MULTISIG block to bind a signature to the proven element. Larger allowlists today route through the inner-pubkey-Merkle MULTISIG (up to 16 keys) or off-chain coordination.

15. Recursive Splitting Tree (congestion control)

A single UTXO that fans out into a binary tree of pre-committed payments.

Bitcoin Script (CTV trees)

OP_CHECKTEMPLATEVERIFY (BIP-119) Each tree node: a CTV-locked output Spender constructs N-1 internal txs before any leaf can be claimed. Pre-signed templates: rigid, no flexibility CTV not activated on mainnet Wallet must store entire pre-computed tree

Not activated BIP-119 is proposed; tree structure is rigid even when activated.

Ladder Script (RECURSE_SPLIT)

ladder(and( sig(@owner), recurse_split(2, 10000) )) recurse_split(max_splits, min_split_sats): each spend may produce up to max_splits outputs — each at least min_split_sats — that re-encumber the same conditions with max_splits decremented. Tree depth is bounded; total output value ≤ input.

Native Bounded recursive fan-out with per-child conditions.

Ladder Script: RECURSE_SPLIT enables CTV-style congestion trees today — bounded, typed, with no soft-fork dependency. Each child is a real UTXO with its own conditions, not a pre-signed template.

16. COSIGN — Paired UTXOs

Two unrelated UTXOs that can only be spent together.

Bitcoin Script

No equivalent. Bitcoin Script cannot reference the presence of other UTXOs in the spending transaction. Workaround: trust + protocol enforcement (e.g. Lightning channel funding tx is a 2-of-2 multisig agreed off-chain)

Not possible No cross-UTXO co-spend primitive.

Ladder Script (COSIGN)

ladder(cosign(<SHA256(partner_spk)>)) UTXO A's conditions commit to the SHA256 of UTXO B's scriptPubKey. Spend tx must include another input whose spent SPK hashes to the same. B can carry its own COSIGN pointing back to A — mutual binding at consensus.

Native Cross-UTXO atomic spend, enforced at consensus.

Ladder Script: COSIGN makes paired UTXOs a first-class concept. Useful for: vault + clawback splits, escrow with dispute UTXOs, and federated reserves where halves must move together.

17. Counter / Latch State Machines

A UTXO that remembers state across spends.

Bitcoin Script

No persistent state. Each UTXO is “memoryless”. Cross-tx state requires: - Off-chain protocol (channels) - Pre-signed transaction chains - External oracles No native counter, no native latch.

Not possible Bitcoin Script is purely stateless within one spend.

Ladder Script (COUNTER / LATCH)

ladder(and( counter_down(@owner, 10), // or counter_up recurse_same(100) )) counter_down(@event_pk, count): each spend must be authorised by event_pk; pair with RECURSE_MODIFIED to decrement count and re-encumber. Terminates at 0. LATCH_SET / LATCH_RESET: one-shot toggles. COUNTER_PRESET: accumulator vs preset.

Native Persistent state via recursion + counter blocks.

Ladder Script: Counters and latches are the building blocks for usage caps, one-shot allowances, multi-stage approvals, and timed escrows — all native, no external oracle.

18. Typed Data Embedding (DATA_RETURN)

Embed up to 40 bytes of structured data in a tx, with type tagging.

Bitcoin Script (OP_RETURN + envelopes)

OP_RETURN <raw bytes> Untyped: parsers race to claim payloads Inscription envelopes: hijack witness to embed kilobytes of data, bloating block weight at 1/4 cost No size cap that consensus enforces Standard relay: 80 bytes (policy only)

Untyped + abused OP_RETURN is a free-for-all; envelopes weaponise the witness discount.

Ladder Script (DATA_RETURN)

ladder(data_return(<1-40 byte hex>)) Single DATA payload (1-40 bytes), with the first bytes typically used by an application as a protocol tag — the consensus rule is on total length, not on a separate type field. Cap: 40 bytes per output, consensus-enforced. Cap: 1 DATA_RETURN output per tx (evaluator.cpp:537). Output is consensus-unspendable (nValue == 0).

Native Typed, capped, non-bloating.

Ladder Script: DATA_RETURN replaces OP_RETURN with a typed, capped primitive. Inscriptions and similar envelope abuses cannot exist because witness data is not free — per-tx user-chosen data is bounded at 40 bytes (one DATA_RETURN output max) plus the structural overhead of the conditions tree.

19. Adaptor Signatures (cross-chain DLC)

Signature that reveals a scalar to the counterparty when broadcast.

Bitcoin Script

No native adaptor primitive. DLC implementations: - Off-chain construction - Custom Schnorr nonce arithmetic - Trust the counterparty's signing - Nonce reuse risk if implemented poorly Adaptor logic lives in the wallet, not the consensus layer.

Off-chain Adaptor sigs are a wallet-side construction; brittle to implement.

Ladder Script (ADAPTOR_SIG)

ladder(adaptor_sig(@signer)) ADAPTOR_SIG v0.7+: single signing key only. The adaptor point T = t·G lives off-chain; the adapted signature s' verifies on-chain as a normal Schnorr against @signer. Counterparty extracts t off-chain by comparing s' to its presig — revealing the DLC scalar atomically with confirmation.

Native Adaptor signatures verified at consensus.

Ladder Script: ADAPTOR_SIG is a typed block, not a wallet trick. Cross-chain swaps and DLCs become as easy to write as a P2PKH — the adaptor scalar is revealed atomically with the on-chain spend.

Summary

Pattern	Bitcoin Script	Ladder Script
Vault with clawback	Not available	vault_lock
HTLC (atomic swap)	11 opcodes	htlc (1 block)
Rate-limited wallet	Not possible	rate_limit
Recursive covenant (DCA)	Not possible	recurse_count
Dead man's switch	IF/ELSE + CSV	or(sig, csv+sig)
Post-quantum signatures	Not possible	sig(@pk, falcon512)
Governance treasury	Multisig only	multisig + output_check + weight_limit
Batch payment (N=100)	3,179 vB	911 vB (3.5×)
Chainstate per coin	24–36 B	3 B (8–12×)
PQ batch (N inputs)	Not possible	pq_batch (~17.8 vB/in)
Multi-party batch settlement	CoinJoin / FROST	qabi_prime + qabi_spend
LN anchor anti-pinning	Policy only	anchor_fee
PTLC (route privacy)	HTLC (linkable)	ptlc
Set-membership proof (≤16 entries)	Linear / leaky	accumulator
Recursive split tree	CTV (rigid + inactive)	recurse_split
Paired UTXOs	Not possible	cosign
Persistent state machines	Not possible	counter / latch
Typed embedded data	OP_RETURN + envelopes	data_return (capped)
Adaptor signatures	Off-chain wallet trick	adaptor_sig

Bitcoin Script works for simple signatures, timelocks, and hash locks. For everything else — vaults, rate limiting, covenants, PQ signatures, batching, transaction introspection, persistent state, paired UTXOs — it either can't do it, requires proposed opcodes that aren't activated, or needs fragile off-chain coordination. Ladder Script provides all of these as native, typed block types with bounded execution and deterministic evaluation.