Eltoo state chain on signet, third time: TEMPLATEHASH + CSFS + INTERNALKEY

A comparative implementation of an Alice/Bob/Carol channel was conducted using three distinct approaches: APO+CTV, a CSFS+CTV rekey ladder, and, following the activation of OP_TEMPLATEHASH in Inquisition 29.4, scripts from @instagibbs’ 2026-01-eltoo_th BOLT draft utilizing TEMPLATEHASH, CSFS, and INTERNALKEY.

The most recent iteration intentionally published an outdated state to observe whether a newer update could supersede it—a core requirement for eltoo-style state channels. This process involved a sequence of transactions, beginning with funding (1163d3d5…9c259124), publishing an old state (22c0c67b…02188692), replacing it with a newer one (4a11cfca…dea15007), and finally settling the latest state (e7476180…e8001568). The deliberate skipping of a state further demonstrated the robustness of the mechanism.

A side-by-side comparison reveals significant differences among the three methods. The APO+CTV approach uses approximately 35 bytes for the update leaf and results in a witness size of about 150 bytes per update, requiring six transactions for a complete run. The CSFS+CTV ladder method increases the update witness size to 512 bytes (which grows with each step) but reduces the transaction count to just two. The new TEMPLATEHASH+CSFS+INTERNALKEY configuration results in a dramatically smaller update leaf (10 bytes), maintains a constant 143-byte witness, and uses four transactions—including the deliberate publication of an obsolete state.

Diving into the technical distinctions illuminates the unique ways these mechanisms interact with Bitcoin’s script interpreter. APO handles rebinding internally during signature verification by omitting the previous output when constructing the sighash, so the script receives only a binary valid/invalid response. CTV checks the hash and similarly provides a yes/no result, meaning that if another component like CSFS needs to sign off on the hash, it must be explicitly supplied in the witness data. TEMPLATEHASH, in contrast, pushes the computed hash onto the stack, enabling subsequent opcodes to manipulate or verify it directly. This subtle architectural change reduces the complexity of the update script to merely three opcodes and allows for more flexible scripting possibilities.

This implementation represents a simplified demonstration—using just one key and no HTLCs—to illustrate the fundamental mechanics rather than provide a production-ready payment channel. Source code for reproducing and examining the scripts is available at templatehash.py and th_csfs_ik_eltoo.py.