Why BIP-110 Doesn't Stop Alkanes

There is a recurring fantasy in Bitcoin politics: that the "right" soft fork will finally make metaprotocols go away. BIP-110, the latest "reduced data" proposal, is the current version of that fantasy. It won't work against alkanes, and it's worth being precise about why, because the reason is structural, not clever.

What BIP-110 actually proposes

BIP-110 is a relay/consensus tightening aimed squarely at data-carrying witness scripts. In its current shape it does two things:

1. Bans script flow control in spends :OP_IF, OP_NOTIF, and the rest of the conditional family become non-standard (and, under the temporary soft fork, invalid) inside witness/tapscript execution.
2. **Caps individual pushes: **every data push is restricted to ≤ 256 bytes.

The target is obvious to anyone who has looked at an inscription. Theord-style envelope, and, until now, the alkanes deploy envelope, is a witness script of the form:

OP_FALSE OP_IF "BIN" <chunk_0> <chunk_1> ... OP_ENDIF

That construction is defined by the two things BIP-110 removes: it hides its payload behind an OP_IF that never executes, and it leans on large data pushes. Kill flow control and shrink pushes, and the classic envelope becomes unminable under the new rules. On paper, that's a win for the "keep arbitrary data off the chain" camp.

The problem: censorship needs a pattern

Any data-filtering rule is really a pattern matcher. BIP-110 doesn't, and cannot, ban "data." It bans a shape: the OP_IF … OP_ENDIF inscription envelope with fat pushes. The moment the payload stops having that shape, the rule has nothing to grab.

The kungfuflex/bip110 branch of alkanes-rs demonstrates exactly this. It introduces a new deploy envelope that carries the same gzip-compressed contract bytecode, but wraps it in a structure that is indistinguishable from an ordinary Lightning-style HTLC, and is therefore BIP-110-clean by construction.

The hashlock envelope

Instead of an inscription envelope, the payload is embedded in a Taproot script-path leaf shaped like a hashed-timelock contract. The compressed WASM is split into ≤ 256-byte chunks, each chunk is SHA-256'd, and the hashes become a chain of hashlock gates:

OP_SHA256 <sha256(chunk_0)> OP_EQUALVERIFY
OP_SHA256 <sha256(chunk_1)> OP_EQUALVERIFY
...
<reveal_key> OP_CHECKSIG

The chunks themselves are supplied as witness stack elements (the "preimages"), exactly as a Lightning node reveals a preimage to claim an HTLC. The Taproot internal key is the BIP-341 NUMS point, so the key path is provably unspendable and the script leaf is the only way to spend, the standard trick for a commitment that exists purely to carry a script.

Read that leaf again and notice what it isn't:

• No OP_IF / OP_NOTIF. Only OP_SHA256, OP_EQUALVERIFY, and OP_CHECKSIG. The branch even ships a hashlock_is_bip110_clean test that asserts the leaf contains none of the banned opcodes.
• No push over 256 bytes. Payload chunking is pinned to HASHLOCK_MAX_ELEMENT_SIZE = 256, and the test asserts every witness element is within the cap.
• No protocol tag. The old envelope announced itself with a literal "BIN" marker. The hashlock envelope announces nothing. The only marker is the two gzip magic bytes (0x1f 0x8b) at the front of the reassembled payload, and those are invisible until you've already concatenated the preimages and decompressed them.

The indexer recovers the contract by reading the ordered hashes out of the leaf, hashing every witness element to build a hash → preimage map, and reassembling in gate order. Recovery is order-independent and ignores the signature, the leaf, and the control block. If the reassembled bytes don't start with the gzip magic, it's simply treated as what it looks like, a real HTLC, and skipped.

Why this is effectively uncensorable

This is the crux, and it's not a loophole, it's a category error in the premise of BIP-110.

A hashlock spend is one of the most load-bearing script templates on Bitcoin. It is the atomic primitive behind Lightning channels, submarine swaps, cross-chain atomic swaps, and discreet log contracts. An alkanes deploy transaction built this way is byte-for-byte the same shape as a routine Lightning HTLC being claimed. There is no field, opcode, tag, or push-size signature that separates "someone claiming a payment" from "someone deploying a contract."

So the filter authors are left with a genuine dilemma:

• Ban the pattern, and you ban HTLCs, i.e., you break Lightning, swaps, and every hashlock contract on the network. That is a political and economic non-starter; it would do far more damage than the data it's trying to stop.
• Don't ban the pattern, and alkanes rides through untouched, because it is the pattern.

There is no threshold in between that catches one and spares the other, because the two are the same object. This is what "riding a lightning-like container" means: the payload travels inside the network's own most essential, most defended script template. You cannot censor the passenger without shooting the vehicle.

The takeaway

BIP-110 is not wrong about what it does; it's wrong about what it accomplishes. It removes one recognizable way to put data in a witness. It does nothing about data availability as a structural property of a programmable-witness blockchain, and it hands metaprotocols a strong incentive to stop being recognizable, which is precisely what the hashlock envelope does.

Alkanes does not need Bitcoin's permission to carry state, and it does not need flow-control opcodes or oversized pushes to do it. If BIP-110 activates tomorrow, the deploy path simply switches to the hashlock envelope on the kungfuflex/bip110 branch, and every new contract deploys as an HTTP... sorry, as an HTLC that no one can afford to filter.

Soft forks can change what Bitcoin transactions are allowed to look like. They cannot make Bitcoin unable to tell whether a hashlock is paying Alice or deploying a contract, because it can't, and neither can the censor.