From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Mar 2026 09:12:48 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w2AYh-0001uI-5D for bitcoindev@gnusha.org; Mon, 16 Mar 2026 09:12:48 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-67bca522419sf23011409eaf.3 for ; Mon, 16 Mar 2026 09:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773677561; x=1774282361; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=8W21WBI7Glr39WO4upQQ0T0sd+v6FFxl9iQNFWMlhns=; b=w2RaihqM4NovD3nGAZPa49dIbrT1ZtxoozOASP0JmMJPKvQURXTOFczGEhRMR6B4MS IZxHK1yGA+q96yHybUW/5hnjVetYoWxIhhL537trO5gcPgAqkRNd7rcZdJb2ERsdQplK gnpDdAD6EOrk1s+yPMat7PY8qCQhJKU73PP1hE1NFh1xocxkQdyCyEhxm8mNVpmrylTf z33Lqd4QCAW0PeRw2avhLxKv+2cvlCJcDsYK8wpj6u7PyGuei81QcZyFBdZxipR4sZL4 CDn18CFclHf0nFaDXFs202Nykw6TLKD4IVv20T3E0RhEhncF6rb5PPgG+4AupaBa5KEi sq7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773677561; x=1774282361; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=8W21WBI7Glr39WO4upQQ0T0sd+v6FFxl9iQNFWMlhns=; b=McIF+pjBry9shBcZ4tH/JIyktaQ7h3/Nu6aExgciOuUB5BOwIZQj1bgzrgZ5ROeX/3 l4dDN16WUt7fQanrm02wMHs6E7iLcoHRnV2ck0AvEbz0kwydI+qTYZF+mvOXQ1XPnUMR 8TUyjm0iRqsL+IEDcxm1Woput003rANYqgoErE5C9CpLCpzOqF1pTbyj47KLozomFFuC Bw/erECgTYj6TrdDq7fR2Y6C2zUNjTBj59kA/4ND7bE7tvC7or171nOEspN+k+BxK7tp 2rMs6d7VzI+3b1iJ+8+dLkTF9I5iGbovn9TNK+oH3U1wC3WmEOsb+NtQXjiyolSRBxf6 f1sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773677561; x=1774282361; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=8W21WBI7Glr39WO4upQQ0T0sd+v6FFxl9iQNFWMlhns=; b=bzwDV2qfVPrXXQTxeH6IQLTSU8Cm3UI/7kPkWYo/l0ZJB/pBqj3/SNNJmveGxaX96G 739+lorAXfr5YzqM4NUA+85p9e2njri9ycBjP6EHg1J6gkA5HRGjQsEWlkadUr9Dv+j7 I49DPBpN7FGs5XClJ8sgFxEViiCa9HHY0IeLDL1q6iuT9j5EnvOenZ8beZmeaY/cZupf XHsqbBCUlA2PJz5VMtgrvjXIb5dFzhOqm03yvpV5Toxx81gYA37Dhug1ckiQ+bAtroD2 eaDVdsq82LEExM8R4KjqKvjW2G3NVRLQG7zb9FqtVOjWa2MO3cEz0N2THZ4C6siafON+ oVFA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVpz2x8L7qFY5wYzZ5f9VKpmHATjWyMyUPCME+Z8w/cFMdnRr5wdOUBqRoVK9hOABVLraV47/4LV7OC@gnusha.org X-Gm-Message-State: AOJu0YxyU5e5MlSmcHJ9Kk8HBA3+cp1M7qFXFqtpsgwYzXAQA1jVMO1N dChz+rgiJf923MFBqXENarg0gK2bHTIFm5MBzIG1rXqgwgjsKx17AU79 X-Received: by 2002:a05:6820:206:b0:67b:a8f8:f68c with SMTP id 006d021491bc7-67bdaa8b0b2mr9073625eaf.70.1773677561026; Mon, 16 Mar 2026 09:12:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HcXuZLjvuqqko9zozr76rXoUH2ma1kuTUQlE7lThedHw==" Received: by 2002:a4a:d66a:0:b0:67b:b18e:c115 with SMTP id 006d021491bc7-67bc61501e5ls962854eaf.2.-pod-prod-00-us-canary; Mon, 16 Mar 2026 09:12:36 -0700 (PDT) X-Received: by 2002:a05:6808:10ce:b0:467:2f58:dff3 with SMTP id 5614622812f47-467a7fd9d54mr86010b6e.18.1773677556239; Mon, 16 Mar 2026 09:12:36 -0700 (PDT) Received: by 2002:a05:690c:a193:b0:794:2788:2ae4 with SMTP id 00721157ae682-79a1c07b7c5ms7b3; Mon, 16 Mar 2026 09:10:38 -0700 (PDT) X-Received: by 2002:a05:690c:4b08:b0:79a:535e:75ae with SMTP id 00721157ae682-79a617ef584mr1529087b3.9.1773677437409; Mon, 16 Mar 2026 09:10:37 -0700 (PDT) Date: Mon, 16 Mar 2026 09:10:37 -0700 (PDT) From: defenwycke To: Bitcoin Development Mailing List Message-Id: <590f01a8-d704-4fcc-9dd2-f7c591124575n@googlegroups.com> Subject: [bitcoindev] [Draft BIP proposal] Ladder script MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_402854_466571253.1773677437031" X-Original-Sender: cal.defenwycke@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_402854_466571253.1773677437031 Content-Type: multipart/alternative; boundary="----=_Part_402855_341730881.1773677437031" ------=_Part_402855_341730881.1773677437031 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list, I'd like to introduce Ladder Script, a draft BIP proposing transaction=20 version 4 with typed, structured spending conditions as an alternative to= =20 opcode-based Script. *The problem it addresses* Bitcoin Script operates on untyped stack elements. A 520-byte data push=20 could be a public key, a hash preimage, a signature, or arbitrary data.=20 There is no way to distinguish them structurally. This makes static=20 analysis unreliable, compound conditions error-prone to construct, and=20 creates a surface for data embedding through witness fields. Adding new spending condition types requires new opcodes, each consuming=20 from a finite space and requiring individual activation. There is no=20 mechanism for structured extensibility. *How it works* The name and structure are borrowed from ladder logic, the programming=20 model used in industrial PLCs (programmable logic controllers) for decades.= =20 In a PLC, a program is a series of rungs on a ladder. Each rung contains=20 condition blocks wired in series (AND) or parallel (OR). The output=20 energises when the conditions are met. It's a model designed to make=20 complex conditional logic readable and composable by people who aren't=20 software engineers. Ladder Script applies the same model to Bitcoin transactions. A spending=20 policy is a ladder. Each rung is a possible spending path containing one or= =20 more typed condition blocks (a signature check, a timelock, a hash=20 verification, a covenant constraint). Blocks on the same rung are AND - all= =20 must be satisfied. Rungs themselves are OR - the first satisfied rung=20 authorises the spend. A vault with fee-gated spending and a dead man's=20 switch is three blocks on a rung. Every byte in a Ladder Script witness belongs to a declared data type with= =20 enforced size constraints. You can read a transaction and see exactly what= =20 it requires. The output format is MLSC (Merkelized Ladder Script Conditions): a 33-byte= =20 scriptPubKey (0xC2 || merkle_root) regardless of policy complexity. Only=20 the exercised spending path is revealed at spend time. Unused paths stay=20 hidden. The UTXO footprint is 40 bytes per entry. The system currently defines 59 block types across 10 families: signatures,= =20 timelocks, hash verification, covenants, recursion, anchors, programmable= =20 logic controllers, compound patterns, governance constraints, and legacy=20 Bitcoin transaction wrappers. New block types slot into numbered families= =20 without consuming opcode space. *Notable properties* Post-quantum signatures. FALCON-512, FALCON-1024, Dilithium3, and SPHINCS+= =20 are native block types. A SCHEME field on any signature block=20 routes verification to classical Schnorr or any PQ algorithm. Existing=20 spending policies (multisig, vaults, covenants) use quantum-resistant keys= =20 with no structural changes. COSIGN allows a PQ-secured UTXO to co-sign for= =20 classical UTXOs, enabling incremental migration without a flag day. *Anti-spam hardening* Three defenses close practical data embedding surfaces: merkle_pub_key=20 folds public keys into the Merkle leaf hash (no writable pubkey field in=20 conditions), selective inversion prevents key-consuming blocks from being= =20 inverted (closes the garbage-pubkey vector), and hash lock deprecation=20 removes standalone preimage blocks (closes the invertible-preimage vector). *Wire efficiency* Compound blocks collapse common multi-block patterns (HTLC, PTLC,=20 TIMELOCKED_MULTISIG, etc.) into single blocks. Relays allow shared=20 conditions across rungs without duplication. Template references let inputs= =20 inherit conditions from other inputs with field-level diffs,=20 which significantly reduces size for batched operations. *Programmable logic* The PLC family brings 14 block types drawn directly from industrial=20 automation: hysteresis controllers, timers, latches, counters, comparators,= =20 sequencers, rate limiters. State machines, approval accumulators, and=20 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= =20 output is a 33-byte MLSC scriptPubKey - identical to any other Ladder=20 Script output. The 897-byte public key is folded into the Merkle leaf and= =20 never appears in the UTXO set. At spend time, the witness carries the full public key (897 bytes) and=20 signature (~666 bytes) for a total of ~1,572 bytes, which is about 16x a=20 Schnorr witness. The cost is paid at spend time only, and only for the path= =20 actually exercised. The RPC interface is three calls: generatepqkeypair, createrungtx,=20 signrungtx. Switching from Schnorr to any PQ scheme is a one-byte SCHEME=20 field change. The same pattern works for FALCON-1024, Dilithium3, and=20 SPHINCS+. *Migration path* Ladder Script is a soft fork. Non-upgraded nodes treat version 4=20 transactions as anyone-can-spend, the same upgrade path as SegWit and=20 Taproot. The proposal includes a three-phase migration model for=20 coexistence with legacy transaction types: 1. Coexistence. Both legacy Bitcoin transaction types (P2PK, P2PKH, P2SH,= =20 P2WPKH, P2WSH, P2TR) and Ladder Script v4 transactions are valid on-chain.= =20 No existing type is deprecated. Wallets choose which format to use. 2. Legacy-in-Blocks. A Legacy block family (7 block types) wraps=20 traditional Bitcoin transaction types as typed Ladder Script blocks.=20 Spending semantics are identical, but all fields are typed and validated = =E2=80=94=20 no arbitrary data surfaces exist in the wrapped form. This lets wallets=20 standardise on a single transaction builder while preserving full backward= =20 compatibility. 3. Sunset. Raw legacy transaction formats are deprecated for new output= =20 creation. Only block-wrapped versions are accepted. Existing legacy UTXOs= =20 remain spendable under their original rules indefinitely. Each phase is a separate activation decision. Phase 1 is the BIP itself.=20 Phases 2 and 3 are future soft forks that the Legacy block family is=20 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=20 deployment, which is a different philosophy from the incremental opcode=20 approach. The argument for it is that a typed framework is extensible=20 without further soft forks =E2=80=94 the argument against is activation ris= k. The PLC family pushes beyond what most people consider "transaction=20 conditions." Whether timers, counters, and sequencers belong at the=20 consensus layer is a legitimate question. The three-phase migration is ambitious. Phase 1 (coexistence) is=20 straightforward, but phases 2 and 3 would be among the largest consensus=20 changes Bitcoin has undertaken. They're included in the design to show that= =20 the framework can absorb legacy semantics cleanly, not as an expectation=20 that they happen soon or at all. *Implementation* Ladder Script is fully implemented in C++ (Bitcoin Core v30.1 fork) with=20 437 unit tests and 229 functional tests, running on a dedicated signet. BIP draft, block library, and browser-based transaction builder:=20 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=20 builder and modify something. I'm looking for feedback on the approach, the block type taxonomy, the=20 activation surface, and anything I've got wrong. If you find any bugs=20 please let me know. Happy to answer questions here or on X (@defenwycke). Defenwycke --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 590f01a8-d704-4fcc-9dd2-f7c591124575n%40googlegroups.com. ------=_Part_402855_341730881.1773677437031 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list,

I'd like to introduce Ladder Script, a draft BIP pro= posing transaction version 4 with typed, structured spending conditions as = an alternative to opcode-based Script.

The problem it ad= dresses

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=C2=A0way to distinguish them structurally. Thi= s makes static analysis unreliable, compound conditions error-prone to cons= truct, and creates a surface for=C2=A0data embedding through witness fields= .

Adding new spending condition types requires new opcodes, each= consuming from a finite space and requiring individual activation. There i= s no mechanism for structured extensibility.

How it works

The name and structure are borrowed from ladder logic, the prog= ramming 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 co= ntains condition blocks wired in series (AND) or parallel (OR). The output = energises when the conditions are met. It's a model designed to make comple= x conditional logic readable and composable by people who aren't software e= ngineers.

Ladder Script applies the same model to Bitcoin transa= ctions. A spending policy is a ladder. Each rung is a possible spending pat= h containing one or more=C2=A0typed condition blocks (a signature check, a = timelock, a hash verification, a covenant constraint). Blocks on the same r= ung are AND - all must be satisfied. Rungs themselves are OR - the first sa= tisfied rung authorises the spend. A vault with fee-gated spending and a de= ad man's switch is three blocks on a rung.

Every byte in a Ladde= r Script witness belongs to a declared data type with enforced size constra= ints. You can read a transaction and see exactly what it requires.
The output format is MLSC (Merkelized Ladder Script Conditions): a 33-by= te scriptPubKey (0xC2 || merkle_root) regardless of policy complexity. Only= the exercised spending path is revealed at spend time. Unused paths stay h= idden. The UTXO footprint is 40 bytes per entry.

The system curr= ently defines 59 block types across 10 families: signatures, timelocks, has= h verification, covenants, recursion, anchors, programmable logic controlle= rs, compound patterns, governance constraints, and legacy Bitcoin transacti= on 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 bl= ock types. A SCHEME field on any signature block routes=C2=A0verification t= o classical Schnorr or any PQ algorithm. Existing spending policies (multis= ig, vaults, covenants) use quantum-resistant keys with no structural change= s. COSIGN allows a PQ-secured UTXO to co-sign for classical UTXOs, enabling= incremental migration without a flag day.

Anti-spam hardenin= g

Three defenses close practical data embedding surfaces: me= rkle_pub_key folds public keys into the Merkle leaf hash (no writable pubke= y field in conditions), selective inversion prevents key-consuming blocks f= rom being inverted (closes the garbage-pubkey vector), and hash lock deprec= ation removes standalone preimage blocks (closes the invertible-preimage ve= ctor).

Wire efficiency

Compound blocks collaps= e common multi-block patterns (HTLC, PTLC, TIMELOCKED_MULTISIG, etc.) into = single blocks. Relays allow shared conditions across rungs without duplicat= ion. Template references let inputs inherit conditions from other inputs wi= th field-level diffs, which=C2=A0significantly reduces size for batched ope= rations.

Programmable logic

The PLC family bri= ngs 14 block types drawn directly from industrial automation: hysteresis co= ntrollers, timers, latches, counters,=C2=A0comparators, sequencers, rate li= miters. State machines, approval accumulators, and watchdog patterns as com= posable blocks within the same wire format.

Example: FALCON-5= 12 on signet

FALCON-512 transactions are running on the live= signet today. The funding output is a 33-byte MLSC scriptPubKey - identica= l to any other Ladder Script=C2=A0output. The 897-byte public key is folded= into the Merkle leaf and never appears in the UTXO set.

At spen= d 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 witne= ss. The cost is paid at spend time only, and only for the path actually exe= rcised.

The RPC interface is three calls: generatepqkeypair, cre= aterungtx, signrungtx. Switching from Schnorr to any PQ scheme is a one-byt= e 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=C2=A0proposal inclu= des a three-phase migration model for coexistence with legacy transaction t= ypes:

=C2=A0 1. Coexistence. Both legacy Bitcoin transaction typ= es (P2PK, P2PKH, P2SH, P2WPKH, P2WSH, P2TR) and Ladder Script v4 transactio= ns are valid on-chain. No=C2=A0existing type is deprecated. Wallets choose = which format to use.
=C2=A0 2. Legacy-in-Blocks. A Legacy block family= (7 block types) wraps traditional Bitcoin transaction types as typed Ladde= r Script blocks. Spending semantics=C2=A0are identical, but all fields are = typed and validated =E2=80=94 no arbitrary data surfaces exist in the wrapp= ed form. This lets wallets standardise on a single=C2=A0transaction builder= while preserving full backward compatibility.
=C2=A0 3. Sunset. Raw l= egacy transaction formats are deprecated for new output creation. Only bloc= k-wrapped versions are accepted. Existing legacy UTXOs remain=C2=A0spendabl= e under their original rules indefinitely.

Each phase is a separ= ate activation decision. Phase 1 is the BIP itself. Phases 2 and 3 are futu= re soft forks that the Legacy block family is designed to=C2=A0support, not= requirements of this proposal.

Trade-offs and open questions=

This is a large surface area change. 59 block types activat= e as a single deployment, which is a different philosophy from the incremen= tal opcode approach. The argument for it is that a typed framework is exten= sible without further soft forks =E2=80=94 the argument against is activati= on risk.

The PLC family pushes beyond what most people consider = "transaction conditions." Whether timers, counters, and sequencers belong a= t the consensus layer is a legitimate question.

The three-phase = migration is ambitious. Phase 1 (coexistence) is straightforward, but phase= s 2 and 3 would be among the largest consensus changes Bitcoin=C2=A0has und= ertaken. They're included in the design to show that the framework can abso= rb legacy semantics cleanly, not as an expectation that they happen soon=C2= =A0or 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://bi= tcoinghost.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 activati= on surface, and anything I've got wrong. If you find any bugs please let me= know. Happy to answer questions here or=C2=A0on X (@defenwycke).

Defenwycke

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/590f01a8-d704-4fcc-9dd2-f7c591124575n%40googlegroups.com.
------=_Part_402855_341730881.1773677437031-- ------=_Part_402854_466571253.1773677437031--