* [bitcoindev] Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) @ 2026-04-14 4:04 aaron.recompile 2026-04-14 13:57 ` [bitcoindev] " Greg Sanders 0 siblings, 1 reply; 5+ messages in thread From: aaron.recompile @ 2026-04-14 4:04 UTC (permalink / raw) To: Bitcoin Development Mailing List 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/CAEmKuUHJEf8R0ZPa--Jm%3De1ToT2-f1CUqp%2BdRLP%3DXZ%2BA3mLBzA%40mail.gmail.com. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) 2026-04-14 4:04 [bitcoindev] Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) aaron.recompile @ 2026-04-14 13:57 ` Greg Sanders 2026-04-14 18:17 ` aaron.recompile 2026-04-14 18:58 ` Sergio Demian Lerner 0 siblings, 2 replies; 5+ messages in thread From: Greg Sanders @ 2026-04-14 13:57 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) 2026-04-14 13:57 ` [bitcoindev] " Greg Sanders @ 2026-04-14 18:17 ` aaron.recompile 2026-04-14 18:58 ` Sergio Demian Lerner 1 sibling, 0 replies; 5+ messages in thread From: aaron.recompile @ 2026-04-14 18:17 UTC (permalink / raw) To: Greg Sanders; +Cc: Bitcoin Development Mailing List Thanks Greg — good to see the ln-symmetry CLN branch revived. A few questions about CSFS+TH+IK: 1. What does TH give you that CTV+CSFS can't already express? 2. What's IK's role — just saving a pubkey push, or something more structural? 3. For state binding, does the construction fundamentally require TH, or could CSFS alone cover that part? Curious what the minimal opcode set for ln-symmetry actually is. Aaron On Tue, Apr 14, 2026 at 8:54 AM 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. -- 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/CAEmKuUGqrmYuCNA9rBd8F-iqH%2BBr2ENWBAvy0Yt6kUPBvuxDMw%40mail.gmail.com. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) 2026-04-14 13:57 ` [bitcoindev] " Greg Sanders 2026-04-14 18:17 ` aaron.recompile @ 2026-04-14 18:58 ` Sergio Demian Lerner 2026-04-27 17:59 ` aaron.recompile 1 sibling, 1 reply; 5+ messages in thread From: Sergio Demian Lerner @ 2026-04-14 18:58 UTC (permalink / raw) To: Greg Sanders; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 4556 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 6187 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Re: Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) 2026-04-14 18:58 ` Sergio Demian Lerner @ 2026-04-27 17:59 ` aaron.recompile 0 siblings, 0 replies; 5+ messages in thread From: aaron.recompile @ 2026-04-27 17:59 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: Greg Sanders, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 6335 bytes --] 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/CAEmKuUEw6YFcrDoVRz4fwjta3sREErSvx9S4UHQ%2B1S5B%3DAfbAg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 8637 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-04-27 18:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-04-14 4:04 [bitcoindev] Subject: Eltoo / LN-Symmetry on Inquisition Signet: BIP 118 + 3-Round State Chain (APO+CTV) aaron.recompile 2026-04-14 13:57 ` [bitcoindev] " Greg Sanders 2026-04-14 18:17 ` aaron.recompile 2026-04-14 18:58 ` Sergio Demian Lerner 2026-04-27 17:59 ` aaron.recompile
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox