Top Tweets for #bch9

CashScript 0.13.0 ships with something that sounds incremental until you actually try to write a complex contract without it: bounded loops. Here's the concrete problem it solves. Before Layla (May 2026), Bitcoin Script had no iteration. If a contract needed to validate five token outputs, you wrote the validation logic five times — literally copied and pasted at the bytecode level. Ten outputs meant ten copies. The contract size grew linearly with the number of items you needed to process, which meant script size limits became a hard ceiling on contract expressiveness. You weren't limited by what you could think of. You were limited by how many times you could repeat yourself before hitting the wall. OP_BEGIN and OP_UNTIL change this at the VM level. You write the loop body once, define a termination condition, and the VM iterates. The "bounded" qualifier is doing real work here — the VM rejects loops that can't be proven to terminate before execution begins. This isn't a runtime check. It's a validation-time constraint. The miner doesn't execute an infinite loop and discover the problem; the transaction is rejected outright if the termination proof fails. This preserves something BCH's design has always prioritized: predictable validation cost. Miners can bound the work a script requires before committing to execute it. In CashScript, this surfaces as actual loop syntax. You write it like a loop, the compiler handles the OP_BEGIN/OP_UNTIL translation, and the termination proof is derived from the loop structure itself. The abstraction is clean. What this unlocks in practice: iterating over a variable-length list of $BCH CashToken outputs, implementing merkle proof verification generically rather than hardcoding for a fixed tree depth, writing batch validation logic that scales with actual input size. These were all possible before Layla — they just required either unrolling manually (expensive, verbose, fragile) or simply not building them. OP_DEFINE and OP_INVOKE are the other piece that matters here. Before these opcodes, Bitcoin Script was a flat sequence. Repeated logic meant duplicated bytecode, full stop. CashScript could abstract this at the source level, but the compiled output still contained every copy. A contract with three settlement paths that all needed to validate a collateral ratio would have that validation logic three times in the bytecode. OP_DEFINE lets you register a named subroutine in the script itself. OP_INVOKE calls it. The VM maintains a proper call stack, executes the subroutine, and returns cleanly. The compiled output reflects the actual structure of the source — repeated logic appears once. For auditors, this is significant. The gap between "what the CashScript source says" and "what the bytecode actually does" narrows considerably when the compiler can preserve function boundaries rather than flattening everything. For DeFi contracts specifically, this compounds with the loop support. A PUSD vault contract checking collateral ratios across multiple redemption scenarios — with shared validation logic and iteration over output sets — is now expressible in a way that's both smaller in bytecode and structurally auditable. Smaller bytecode means lower fees. Lower fees on a chain where fees are already a fraction of a cent means contract interaction is genuinely free for practical purposes. The bitwise opcodes (OP_AND, OP_OR, OP_XOR, OP_LSHIFT, OP_RSHIFT) round out what Layla added to the VM. These were disabled in early Bitcoin and have been absent from BCH Script since the fork. Re-enabling them with well-defined semantics on byte strings sounds like a footnote. It isn't. CashTokens NFT commitments are 40-byte arbitrary byte strings. Contracts that want to interpret structured data packed into a commitment — a type field, a timestamp, a hash — previously had to use arithmetic unpacking, which was verbose and expensive. Bitwise shifts and masks make this clean. You check whether a flag is set with a single OP_AND. You extract a 2-byte field with a shift. The contract logic reads like the data structure it's operating on. P2S (Pay-to-Script) as a standard output type completes the picture for covenant chains. P2SH outputs commit to a hash of the script — you can't inspect what an output does without the full preimage. P2S outputs carry the script directly. For a covenant contract that needs to verify the exact script of an output it's creating, this eliminates the hash-preimage dance. The contract can introspect the output script natively. Certain patterns — enforcing that change returns to the same contract type, building contract chains where each step validates the next — become straightforward rather than requiring workarounds. All four of these features are in CashScript 0.13.0. The compiler handles the translation. Existing contracts don't break. New contracts opt into the new primitives selectively. The BCH VM in mid-2026 can express loops, functions, bitwise operations, and introspectable outputs — none of which existed in Bitcoin Script four years ago. Each upgrade was incremental. The compound effect is a contract environment that can handle real financial logic without contorting itself to fit a flat, iteration-free bytecode model. The fee for deploying and interacting with any of it: still a fraction of a cent. The infrastructure improved. The fee didn't.