From: Greg Sanders <gsanders87@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV)
Date: Tue, 14 Apr 2026 06:57:06 -0700 (PDT) [thread overview]
Message-ID: <494c0600-2daa-4500-8e49-bf36efbf2625n@googlegroups.com> (raw)
In-Reply-To: <CAEmKuUHJEf8R0ZPa--Jm=e1ToT2-f1CUqp+dRLP=XZ+A3mLBzA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3608 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 5345 bytes --]
next prev parent reply other threads:[~2026-04-14 15:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 4:04 [bitcoindev] " aaron.recompile
2026-04-14 13:57 ` Greg Sanders [this message]
2026-04-14 18:17 ` [bitcoindev] " aaron.recompile
2026-04-14 18:58 ` Sergio Demian Lerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=494c0600-2daa-4500-8e49-bf36efbf2625n@googlegroups.com \
--to=gsanders87@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox