From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 08:54:17 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCg5g-00035m-Jq for bitcoindev@gnusha.org; Tue, 14 Apr 2026 08:54:17 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-40efa542b8asf7687946fac.2 for ; Tue, 14 Apr 2026 08:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776182050; x=1776786850; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=193GDly+EPim/B9IXKQI4fYb8nZMekBtZTpL/CI2jnc=; b=QK0d+e5iAAcCMCYQelik/6wa/tkjVQ0pfkOHivrsRgy/Di3QgHdXmKOtenUCqjH+qn 6ksHOiRvYNEC5ECFpC3DSE9pbwpdToefRocDz6RVvKyFvs92RVyT16cBjdVQlfwozdtu 85j97hXg3i3d8XBrUdvSoeYzmyt7t5DAsY0e/udYQ2FhxnUOsVa/jPfx/Y8qjva3bk5D /A2+pA0qy4lCXbpSCeFIF8l+SdowLlqj8kcLi2qNhqJ0pzoimf+Bb4Ar1vgavzLyCh69 2vhU9E0SX3emnR+H2IhpotRGn31tZc9r6bnEqalL3OV+3rU3Gsopih9YTrXsHvYCO+v1 /T8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776182050; x=1776786850; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=193GDly+EPim/B9IXKQI4fYb8nZMekBtZTpL/CI2jnc=; b=TxgVoWGCloHllow+jgI1jj3dKsR4UNM6+ylP90UvRs9kvicHJTUVI0hd/KHf5tW63z 3bm9NbASi8vXB2doghndzxS58yOLjhZi5ffZRthiNBI20/EkKsYeNjO1iCncw09DjaMI 6WDE2pU9eZ+4nplQ3D+X1yK+jkJoNsPgEE2E8c4LMc5rC4TNeR8V2Cjf0K7CsmbeQU5/ 8uK6vkoe/8VHV/eArHL20EaoKs3cD4sLPyvmbZBZbLm4rZExCWclqFQFGIZMfliV7j1N TFRotaM1Rozc8T719Q54TGRJFb+Bbk0mZRTtyyWE66nmwg0F3NfOvQ+4724OEhKVqsG5 YfHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776182050; x=1776786850; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=193GDly+EPim/B9IXKQI4fYb8nZMekBtZTpL/CI2jnc=; b=sdKLukfxtpahuMnwCmCG783fAlE2WpFYkPdFioJYRi1Y/4wBkWrYLMFYIIYLEDIeTR /l3VfFsP7/KAm1IF+vrvr3wchfxDddUNmZ3ofQiBU5g2P3fdE3ofpiCDonNQ00kBRvAU OA0rD4Ee16XHPdaeBmnbOwpMdnjwS7tszu+4EbwBk68NQBNiq3pTYIYbaJXE3aRf8hgI 7dqP7P2YdZXboIqhvC6Ma8Z3imDCwfoAEP8eugGoSux65SpGeD7MbPqGzqPrxYcGLm2r QUzwA57bPF32yNmBPdCkjdvK4HkW8G8MOGRj1QzcS50Wo/IuLfrUg0EbIyvSPYAMijL+ 9baQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9S0KoNzVNGop20FWKcP7H5YLfN9qi8jnrYDnywLVSauwRNOR4lTPcF5rdqcC7ySsvojaqwnXk3HyCS@gnusha.org X-Gm-Message-State: AOJu0YzSh9p0qeOFn+u0A60lCts5j+304Muu5n7PsYOcwp+H4d+ekuVH FVsB0CafERyeSpyF0M7dvxr/RiyCgvlTwceHV+/zdJQWhsxhTidlGOIf X-Received: by 2002:a05:6870:392c:b0:417:211:33ca with SMTP id 586e51a60fabf-423e10f2dbdmr10266587fac.36.1776182050248; Tue, 14 Apr 2026 08:54:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKblPe109kiQN8RHeeVnQuOrVtnfalyPLdBTKSAOFaGWg==" Received: by 2002:a05:6870:e983:b0:41c:583a:b50 with SMTP id 586e51a60fabf-423dd96d6f5ls2059066fac.1.-pod-prod-04-us; Tue, 14 Apr 2026 08:54:05 -0700 (PDT) X-Received: by 2002:a05:6808:180a:b0:467:f636:23bd with SMTP id 5614622812f47-478a0f1c46fmr9164018b6e.42.1776182045073; Tue, 14 Apr 2026 08:54:05 -0700 (PDT) Received: by 2002:a05:690c:d91:b0:7b3:443:26a9 with SMTP id 00721157ae682-7b304434911ms7b3; Tue, 14 Apr 2026 06:57:07 -0700 (PDT) X-Received: by 2002:a05:690c:7108:b0:7b2:bf20:cdc1 with SMTP id 00721157ae682-7b2bf20f83fmr94062977b3.0.1776175026475; Tue, 14 Apr 2026 06:57:06 -0700 (PDT) Date: Tue, 14 Apr 2026 06:57:06 -0700 (PDT) From: Greg Sanders To: Bitcoin Development Mailing List Message-Id: <494c0600-2daa-4500-8e49-bf36efbf2625n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_80188_1879793465.1776175026046" X-Original-Sender: gsanders87@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_80188_1879793465.1776175026046 Content-Type: multipart/alternative; boundary="----=_Part_80189_1495811572.1776175026046" ------=_Part_80189_1495811572.1776175026046 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In case anyone is interested, a few months ago I resurrected my old=20 ln-symmetry branch of CLN with various improvements and examples, thanks to= =20 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= =20 cannot be tested on signet directly until OP_TEMPLATEHASH is activated.=20 It's a drop-in replacement for CTV, if anyone cares to adapt it. Greg On Tuesday, April 14, 2026 at 5:18:24=E2=80=AFAM UTC-4 aaron.recompile wrot= e: > 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: OP_CHECKTEMPLATEVERIFY > leaf 2 -- apo_update: <0x01||xonly> OP_CHECKSIG (BIP 118) > leaf 3 -- csv_escape: OP_CHECKSEQUENCEVERIFY OP_DROP > 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 =E2=86=92 State v1: > 386dbb6aa23fcc35a69d34e3c0f760b185482467abc936196d3def19d54a9c41 > APO update v1 =E2=86=92 v2: > 096e31ccbd8f5460b2730ec4f757ee1b01acf9dde3e3b8cb55fbb534fe195601 > APO update v2 =E2=86=92 v3: > 091309b73e299436ff12fceda7e54e28c6f1817fdf3405bca3343ad15198d7f6 > CTV settlement:=20 > 13957f49d01aa21ed2aa28df7aa78f357d51a2a2fbfb434af05fdc75ad0ff9b7 > > Rebind A (signed): > 03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4 > Rebind B (witness copied): > 46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43 > > Rebind A and B share an identical witness stack =E2=80=94 same 65-byte si= gnature > (sighash flag 0x41), same leaf script, same control block =E2=80=94 spend= ing 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-rebind= ing-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 > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 494c0600-2daa-4500-8e49-bf36efbf2625n%40googlegroups.com. ------=_Part_80189_1495811572.1776175026046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In case anyone is interested, a few months ago I resurrected my old ln-symm= etry branch of CLN with various improvements and examples, thanks to LLM do= ing the heavy lifting for revival.

https://delvingbitc= oin.org/t/ln-symmetry-project-recap/359/17

Aside= from APO implementation, I also vibed a CSFS+TH+IK variant, though it cann= ot be tested on signet directly until OP_TEMPLATEHASH is activated. It's a = drop-in replacement for CTV, if anyone cares to adapt it.

<= /div>
Greg

On Tuesday, April 14, 2026 at 5:18:24=E2=80=AFA= M 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 eng= ine.
If the Python digest disagrees with Core's, the transaction is reje= cted.
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 =E2=86=92 State v1:
386dbb6aa23fcc35a69d34e3c0f760b185482467abc936196d3def19d54a9c41
APO update v1 =E2=86=92 v2:
096e31ccbd8f5460b2730ec4f757ee1b01acf9dde3e3b8cb55fbb534fe195601
APO update v2 =E2=86=92 v3:
091309b73e299436ff12fceda7e54e28c6f1817fdf3405bca3343ad15198d7f6
CTV settlement: 13957f49d01aa21ed2aa28df7aa78f357d51a2a2fbfb434af05fdc7= 5ad0ff9b7

Rebind A (signed):
03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4
Rebind B (witness copied):
46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43

Rebind A and B share an identical witness stack =E2=80=94 same 65-byte = signature
(sighash flag 0x41), same leaf script, same control block =E2=80=94 spe= nding 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-reb= inding-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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/494c0600-2daa-4500-8e49-bf36efbf2625n%40googlegroups.com.
------=_Part_80189_1495811572.1776175026046-- ------=_Part_80188_1879793465.1776175026046--