Re: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV)

["aaron.recompile" <aaron.recompile@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7798 bytes --]

Hi list,

In April, Greg mentioned he had vibed a CSFS+TH+IK variant that couldn't be
tested on signet until OP_TEMPLATEHASH was active, and that anyone was
welcome to adapt it. Inquisition 29.4 turned it on, so I took the scripts
from his eltoo draft and ran them in the same Alice/Bob/Carol channel as my
APO+CTV and CSFS+CTV ladder runs above. I published an old state, replaced
it with an update signed before any state existed, and settled.

Write-up with the transactions and a comparison of all three versions:
https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-third-time-templatehash-csfs-internalkey/3012

Building it also answered the three questions I asked Greg earlier in this
thread:

1. What TH adds over CTV + CSFS: it gives the hash back on the stack, so
CSFS can sign it directly. With CTV I had to carry a second copy of the
hash in the witness.
2. What IK is for: mostly bytes. It replaces a 32-byte key push, so the
update script is 10 bytes.
3. Can CSFS alone bind state: no. CSFS never sees the transaction, so
something like TH has to hand it the hash.

Thanks to Greg for the draft, it made this easy to follow.

Aaron


On Mon, Apr 27, 2026 at 10:59 AM aaron.recompile <aaron.recompile@gmail.com>
wrote:

> Following up on the APO+CTV state chain above — I also ran a
> CSFS+CTV ladder variant on Inquisition signet, achieving the same
> Eltoo property (3 rounds of state updates, only the latest can
> settle) with two transactions instead of six. No APO, no CAT —
> just already-activated CTV and CSFS.
>
> The compression comes from Jeremy Rubin's CSFS rekey ladder
> construction (https://rubin.io/bitcoin/2024/12/02/csfs-ctv-rekey-symmetry
> /),
> which makes each state hop a CSFS rekey — a signature
> delegation, not a transaction — collapsing the whole chain into
> one settlement witness. I made some engineering refinements to streamline
> the implementation.
>
> Confirmed Inquisition signet TxIDs, full construction, threat
> analysis, and witness layout:
>
> https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-again-three-rounds-two-transactions-csfs-ctv-with-rekey-and-ladder-no-cat/2430
>
> Source code:
> https://github.com/aaron-recompile/btcaaron/tree/main/examples/eltoo
>
> Aaron
>
>
> On Tue, Apr 14, 2026 at 12:02 PM Sergio Demian Lerner <
> sergio.d.lerner@gmail.com> wrote:
>
>> If you want to do have similar functionality to Eltoo without soft-forks,
>> you can use OTC-PCs:
>>
>> OTS-PC: OTS-based Payment Channels for the Lightning Network
>> https://arxiv.org/abs/2511.04021
>>
>> regards, Sergio
>>
>>
>> On Tue, Apr 14, 2026 at 12:54 PM Greg Sanders <gsanders87@gmail.com>
>> wrote:
>>
>>> In case anyone is interested, a few months ago I resurrected my old
>>> ln-symmetry branch of CLN with various improvements and examples, thanks to
>>> LLM doing the heavy lifting for revival.
>>>
>>> https://delvingbitcoin.org/t/ln-symmetry-project-recap/359/17
>>>
>>> Aside from APO implementation, I also vibed a CSFS+TH+IK variant, though
>>> it cannot be tested on signet directly until OP_TEMPLATEHASH is activated.
>>> It's a drop-in replacement for CTV, if anyone cares to adapt it.
>>>
>>> Greg
>>>
>>> On Tuesday, April 14, 2026 at 5:18:24 AM UTC-4 aaron.recompile wrote:
>>>
>>>> Hi List,
>>>>
>>>> I ran a three-round Eltoo-style state chain on Bitcoin Inquisition 29.2
>>>> signet using APO (BIP 118) for state updates and CTV for settlement.
>>>> Six transactions, all confirmed on-chain.
>>>>
>>>> An independent Python implementation of the BIP 118 sighash (Msg118 /
>>>> Ext118) was cross-validated against Inquisition's C++ consensus engine.
>>>> If the Python digest disagrees with Core's, the transaction is
>>>> rejected.
>>>> It wasn't.
>>>>
>>>> Construction
>>>> ------------
>>>> Each state UTXO is a three-leaf Taproot tree:
>>>>
>>>> leaf 1 -- ctv_uhpo: <template_hash> OP_CHECKTEMPLATEVERIFY
>>>> leaf 2 -- apo_update: <0x01||xonly> OP_CHECKSIG (BIP 118)
>>>> leaf 3 -- csv_escape: <sequence> OP_CHECKSEQUENCEVERIFY OP_DROP
>>>> <pubkey> OP_CHECKSIG
>>>>
>>>> CTV locks each state's payout distribution
>>>> as a template hash. APO rebinding advances state. When an APO update
>>>> spends state vN, vN's CTV leaf
>>>> loses its only viable input and can never settle. Only the latest state
>>>> can produce a valid settlement. This is the Eltoo invariant, executed
>>>> end-to-end with current tooling.
>>>>
>>>> Confirmed txids (Inquisition signet)
>>>> -------------------------------------
>>>> Fund → State v1:
>>>> 386dbb6aa23fcc35a69d34e3c0f760b185482467abc936196d3def19d54a9c41
>>>> APO update v1 → v2:
>>>> 096e31ccbd8f5460b2730ec4f757ee1b01acf9dde3e3b8cb55fbb534fe195601
>>>> APO update v2 → v3:
>>>> 091309b73e299436ff12fceda7e54e28c6f1817fdf3405bca3343ad15198d7f6
>>>> CTV settlement:
>>>> 13957f49d01aa21ed2aa28df7aa78f357d51a2a2fbfb434af05fdc75ad0ff9b7
>>>>
>>>> Rebind A (signed):
>>>> 03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4
>>>> Rebind B (witness copied):
>>>> 46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43
>>>>
>>>> Rebind A and B share an identical witness stack — same 65-byte
>>>> signature
>>>> (sighash flag 0x41), same leaf script, same control block — spending
>>>> two
>>>> different UTXOs without re-signing. Outputs remain committed: changing
>>>> the output address in Rebind B causes script verification failure.
>>>> The last two transactions are a standalone rebinding demonstration,
>>>> not part of the state chain above.
>>>>
>>>> Links
>>>> ------
>>>> BIP 118 signing primitive and rebinding proof (Delving Bitcoin):
>>>>
>>>> https://delvingbitcoin.org/t/bip-118-signing-from-scratch-on-chain-rebinding-proof/2411
>>>>
>>>> Eltoo state chain construction (Delving Bitcoin):
>>>>
>>>> https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-three-rounds-six-transactions-apo-ctv/2413
>>>>
>>>> Source code (btcaaron, examples/braidpool/):
>>>> https://github.com/aaron-recompile/btcaaron
>>>>
>>>> Happy to discuss the construction or the CTV+CSFS gap.
>>>>
>>>> Aaron Zhang
>>>>
>>> --
>>> 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/494c0600-2daa-4500-8e49-bf36efbf2625n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/494c0600-2daa-4500-8e49-bf36efbf2625n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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/CAKzdR-ok1jwtXOYaAPBw1fhpavL%3DP%2B2jsT%2BVcKc9OwW6bhpRFw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAKzdR-ok1jwtXOYaAPBw1fhpavL%3DP%2B2jsT%2BVcKc9OwW6bhpRFw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/CAEmKuUHpybu_RZt-S4A09ev2T%3D%3Di%2BHLgSqf%3DnVf9wX%3D8JLZMZg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 10432 bytes --]