Skip to content

Instantly share code, notes, and snippets.

@Ademan
Created October 13, 2025 20:11
Show Gist options
  • Select an option

  • Save Ademan/300f19f925e368a3b532ddbf3c88b425 to your computer and use it in GitHub Desktop.

Select an option

Save Ademan/300f19f925e368a3b532ddbf3c88b425 to your computer and use it in GitHub Desktop.

LNHANCE Expeditionary Project

Description

The LNHANCE Expeditionary Project explores the LNHANCE soft fork proposal by building proof-of-concept implementations of Eltoo channels, hArk, and Vaults, while creating tools and documentation, with a particular focus on OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACK. It aims to identify practical benefits and limitations, address overlooked issues, and highlight LNHANCE’s utility for Bitcoin as a monetary network. The project will produce educational materials and reusable libraries to facilitate further exploration. Building on this foundation, the project will then explore new protocol possibilities by building more experimental proof-of-concept applications, specifications, or high-level overviews as appropriate.

The first proof of concept to be built is a CTV-only vault, which uses a precomputed state tree to enable velocity control and a finite but arbitrarily large number of deposits and withdrawals, with a secure recovery path. The drawbacks of this design are fairly well understood by some developers. In spite of its limitations, the vault user experience can precisely communicate these limitations to the end user and provide a meaningful improvement in security. Because I’ve already implemented the bulk of the vault logic, this project will focus on user experience and key management.

The second and largest portion of the project is to implement multiple Eltoo channels. First, I will build a naive 2-party implementation within LDK, which I will then extend to multiple parties. I expect integrating with LDK to present a significant amount of work on its own, but this will guide the implementation towards a more production ready state. These proofs of concept will expose and address lurking issues, and prove the viability of these protocols. To the extent possible, all other Eltoo PoCs will build on this initial implementation in LDK. Using the full suite of LNHANCE opcodes I have already proposed a precomputed settlement state machine for multiparty Eltoo. As part of this exploration, I will document how to generalize this concept, and apply it to other state machines, including a vastly more computationally efficient version of my original proposal.

Third, this project will explore LNHANCE’s applicability to Ark-like protocols. Recently, Steven Roose shared two alternative protocols leveraging CTV and CSFS with different tradeoffs. Using the bark implementation as a base, I will implement one of these, the hArk protocol, to prove its viability.

Finally, I will use any remaining time to explore open questions in the design space of LNHANCE vaults, multiparty Eltoo constructions, and Ark. With Eltoo provided by CTV+CSFS, channel factories and coinpool implementations overlap significantly, and precomputed state machines can enable offline channel partner tolerance with varying tradeoffs in terms of computational complexity, on-chain weight, and interactivity. I will simulate different scenarios to discover the best, worst, and average case on-chain footprint of these coinpools using different methods for eviction. This analysis will inform whether multiparty Eltoo coinpool-like constructions are useful as non-custodial payouts for decentralized mining pools such as Braidpool. Since Braidpool miners are already connected, the interactivity requirements of a coinpool are less onerous. Next, time permitting, I will explore more of the Ark design space, possibly building a PoC of Erk, or else looking for opportunities to use PAIRCOMMIT to improve Erk or hArk. Lastly, time permitting, I will explore several enhancements to the CTV-only vault enabled by CSFS. These improvements include social recovery and offline key delegation, as well as using deleted key recursion to reduce the precomputation overhead to the point where a hardware wallet can precompute the entire Vault in a reasonable timeframe. The priority and focus of this exploration phase is likely to be guided by lessons learned in the first two phases, so the exact priority is likely to change.

Project Timeline and Potential Milestones

  1. Implementation Phase a. CTV-only Vault Prototype i. Finish prototype functionality ii. Build out PoC CLI UI iii. Build out minimal graphical UI to illustrate intended UX iv. Document CTV precomputed state machine design for broad and technical audiences b. Multiparty Eltoo i. Implement two party Eltoo in LDK (CTV+CSFS only) ii. Extend two party Eltoo to Naive Multiparty Eltoo in LDK as much as practicable. If LDK implementation proves impractical, move multiparty PoC outside of LDK. iii. Refine PoC implementation and documentation for Multiparty Eltoo with bounded settlement (CTV+CSFS+IK+PAIRCOMMIT only) 1. Document precomputed settlement state machine design along with computationally enhanced version of protocol iv. Document implementations and include on-chain efficiency comparisons with other implementations c. Apply CTV+CSFS to Ark i. Implement hArk in bark ii. Explore Erk
  2. Exploratory/Research phase a. Exhibit other possible Eltoo protocols (documentation and/or PoC) i. Explore potential efficiency improvements in offline party tolerance using precomputed state machines (vs. form in channel factory paper) ii. Coinpools without OP_EVICT 1. Explore strategies to optimize efficiency of eviction, exit, and splicing 2. Explore coinpools as a potentially attractive (chainspace efficient) way to manage payouts non-custodially for decentralized miners like Braidpool iii. Explore further applications of (rebindable) settlement state machine 1. Limited penalty support with watchtowers 2. Document and/or implement improved (linear) computational complexity bounded settlement state machine b. Explore other possible Ark designs i. Potentially implement an Erk PoC if it seems valuable c. Explore other possible CTV Vault improvements i. CSFS for deleted key recursion ii. Add CSFS offline key delegation iii. Explore any other key management improvements facilitated by CSFS d. Ongoing: Explore and document other design potential enabled by LNHANCE

Personal Github

https://github.com/Ademan

Other Contact Details

nostr:nprofile1qyd8wumn8ghj7ur4wfshv6tyvyhxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3xamnwvaz7tm0venxx6rpd9hzuur4vghsz9nhwden5te0wfjkccte9ekk7um5wgh8qatz9uqsuamnwvaz7tmwdaejumr0dshsqgpvkvxrvsut449z55g8hjv0tn47dgpznvz4fkx0h5wfn23uclkwcyyqnl6n

https://twitter.com/Ademan555

References

  • Adam Jonas
  • Antoine Poinsot
  • Brandon Black - Can attest to general Bitcoin concept proficiency
  • Instagibbs - Can attest to general Bitcoin concept proficiency

Prior Contributions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment