* [bitcoindev] [Draft BIP proposal] Ladder script
@ 2026-03-16 16:10 defenwycke
0 siblings, 0 replies; only message in thread
From: defenwycke @ 2026-03-16 16:10 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8029 bytes --]
Hello list,
I'd like to introduce Ladder Script, a draft BIP proposing transaction
version 4 with typed, structured spending conditions as an alternative to
opcode-based Script.
*The problem it addresses*
Bitcoin Script operates on untyped stack elements. A 520-byte data push
could be a public key, a hash preimage, a signature, or arbitrary data.
There is no way to distinguish them structurally. This makes static
analysis unreliable, compound conditions error-prone to construct, and
creates a surface for data embedding through witness fields.
Adding new spending condition types requires new opcodes, each consuming
from a finite space and requiring individual activation. There is no
mechanism for structured extensibility.
*How it works*
The name and structure are borrowed from ladder logic, the programming
model used in industrial PLCs (programmable logic controllers) for decades.
In a PLC, a program is a series of rungs on a ladder. Each rung contains
condition blocks wired in series (AND) or parallel (OR). The output
energises when the conditions are met. It's a model designed to make
complex conditional logic readable and composable by people who aren't
software engineers.
Ladder Script applies the same model to Bitcoin transactions. A spending
policy is a ladder. Each rung is a possible spending path containing one or
more typed condition blocks (a signature check, a timelock, a hash
verification, a covenant constraint). Blocks on the same rung are AND - all
must be satisfied. Rungs themselves are OR - the first satisfied rung
authorises the spend. A vault with fee-gated spending and a dead man's
switch is three blocks on a rung.
Every byte in a Ladder Script witness belongs to a declared data type with
enforced size constraints. You can read a transaction and see exactly what
it requires.
The output format is MLSC (Merkelized Ladder Script Conditions): a 33-byte
scriptPubKey (0xC2 || merkle_root) regardless of policy complexity. Only
the exercised spending path is revealed at spend time. Unused paths stay
hidden. The UTXO footprint is 40 bytes per entry.
The system currently defines 59 block types across 10 families: signatures,
timelocks, hash verification, covenants, recursion, anchors, programmable
logic controllers, compound patterns, governance constraints, and legacy
Bitcoin transaction wrappers. New block types slot into numbered families
without consuming opcode space.
*Notable properties*
Post-quantum signatures. FALCON-512, FALCON-1024, Dilithium3, and SPHINCS+
are native block types. A SCHEME field on any signature block
routes verification to classical Schnorr or any PQ algorithm. Existing
spending policies (multisig, vaults, covenants) use quantum-resistant keys
with no structural changes. COSIGN allows a PQ-secured UTXO to co-sign for
classical UTXOs, enabling incremental migration without a flag day.
*Anti-spam hardening*
Three defenses close practical data embedding surfaces: merkle_pub_key
folds public keys into the Merkle leaf hash (no writable pubkey field in
conditions), selective inversion prevents key-consuming blocks from being
inverted (closes the garbage-pubkey vector), and hash lock deprecation
removes standalone preimage blocks (closes the invertible-preimage vector).
*Wire efficiency*
Compound blocks collapse common multi-block patterns (HTLC, PTLC,
TIMELOCKED_MULTISIG, etc.) into single blocks. Relays allow shared
conditions across rungs without duplication. Template references let inputs
inherit conditions from other inputs with field-level diffs,
which significantly reduces size for batched operations.
*Programmable logic*
The PLC family brings 14 block types drawn directly from industrial
automation: hysteresis controllers, timers, latches, counters, comparators,
sequencers, rate limiters. State machines, approval accumulators, and
watchdog patterns as composable blocks within the same wire format.
*Example: FALCON-512 on signet*
FALCON-512 transactions are running on the live signet today. The funding
output is a 33-byte MLSC scriptPubKey - identical to any other Ladder
Script output. The 897-byte public key is folded into the Merkle leaf and
never appears in the UTXO set.
At spend time, the witness carries the full public key (897 bytes) and
signature (~666 bytes) for a total of ~1,572 bytes, which is about 16x a
Schnorr witness. The cost is paid at spend time only, and only for the path
actually exercised.
The RPC interface is three calls: generatepqkeypair, createrungtx,
signrungtx. Switching from Schnorr to any PQ scheme is a one-byte SCHEME
field change. The same pattern works for FALCON-1024, Dilithium3, and
SPHINCS+.
*Migration path*
Ladder Script is a soft fork. Non-upgraded nodes treat version 4
transactions as anyone-can-spend, the same upgrade path as SegWit and
Taproot. The proposal includes a three-phase migration model for
coexistence with legacy transaction types:
1. Coexistence. Both legacy Bitcoin transaction types (P2PK, P2PKH, P2SH,
P2WPKH, P2WSH, P2TR) and Ladder Script v4 transactions are valid on-chain.
No existing type is deprecated. Wallets choose which format to use.
2. Legacy-in-Blocks. A Legacy block family (7 block types) wraps
traditional Bitcoin transaction types as typed Ladder Script blocks.
Spending semantics are identical, but all fields are typed and validated —
no arbitrary data surfaces exist in the wrapped form. This lets wallets
standardise on a single transaction builder while preserving full backward
compatibility.
3. Sunset. Raw legacy transaction formats are deprecated for new output
creation. Only block-wrapped versions are accepted. Existing legacy UTXOs
remain spendable under their original rules indefinitely.
Each phase is a separate activation decision. Phase 1 is the BIP itself.
Phases 2 and 3 are future soft forks that the Legacy block family is
designed to support, not requirements of this proposal.
*Trade-offs and open questions*
This is a large surface area change. 59 block types activate as a single
deployment, which is a different philosophy from the incremental opcode
approach. The argument for it is that a typed framework is extensible
without further soft forks — the argument against is activation risk.
The PLC family pushes beyond what most people consider "transaction
conditions." Whether timers, counters, and sequencers belong at the
consensus layer is a legitimate question.
The three-phase migration is ambitious. Phase 1 (coexistence) is
straightforward, but phases 2 and 3 would be among the largest consensus
changes Bitcoin has undertaken. They're included in the design to show that
the framework can absorb legacy semantics cleanly, not as an expectation
that they happen soon or at all.
*Implementation*
Ladder Script is fully implemented in C++ (Bitcoin Core v30.1 fork) with
437 unit tests and 229 functional tests, running on a dedicated signet.
BIP draft, block library, and browser-based transaction builder:
https://bitcoinghost.org/labs/
Source: https://github.com/defenwycke/ghost-labs-ladder-script
The easiest way to understand it is to load an example in the signet
builder and modify something.
I'm looking for feedback on the approach, the block type taxonomy, the
activation surface, and anything I've got wrong. If you find any bugs
please let me know. Happy to answer questions here or on X (@defenwycke).
Defenwycke
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/590f01a8-d704-4fcc-9dd2-f7c591124575n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8522 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-03-16 16:12 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-16 16:10 [bitcoindev] [Draft BIP proposal] Ladder script defenwycke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox