Adam Gibson’s October 4 LN-GAP proposal explores a broader use for Lightning-style channels: two parties could run a multi-step contract offchain and settle a disagreement through a bounded sequence of Bitcoin transactions. Its central addition is an external committee that records whether participants published their moves on time. Gibson’s announcement
The September-dated draft paper proposes working within Bitcoin’s existing consensus rules. But its security model includes an honest-majority assumption for that committee, called a venue. That qualification matters as much as the promise of fewer onchain transactions. LN-GAP draft paper
Why an absent message creates a problem
Bitcoin already supports more elaborate spending conditions than a simple signature check. Andrew Poelstra’s 2024 technical article describes using one-time signatures to make game states readable by Bitcoin Script. In a tic-tac-toe construction, participants can prepare transactions covering moves, winning conditions and timeouts. The same general technique can extend to more complicated games. Poelstra’s Script analysis
That earlier work also identifies a practical limit: publishing a complete game transcript is more reasonable for a short game than a long one. Splitting computation into steps and narrowing disputes can help, but a design still needs a way to bring an uncooperative participant’s interaction to an enforceable conclusion. Transaction-tree discussion
Gibson targets the case where a participant stops responding. A signed illegal move supplies evidence; an alleged missing message does not establish when it should have arrived. His venue attests to publication and timing without interpreting the contract’s meaning. Publication needs one willing committee member, while a threshold majority must attest that a move missed its deadline. Original proposal
The distinction is useful beyond games. The difficulty is enforcing a deadline without moving every subsequent interaction onto Bitcoin’s blockchain. A contract can have clearly written rules and still need reliable evidence that someone failed to act.
A small dispute sequence carries a trust condition
The repository’s chess example illustrates the intended path. After a force-close publishes the channel commitment, one player claims that the other did not make a valid move. The other can rebut with the published move; the claimant can then identify a specific rule violation. That example uses three transactions after the commitment, regardless of the game’s length. LN-GAP demonstration documentation
The paper separates control of the money from trust in evidence. Venue members do not independently hold the participants’ funds. Nevertheless, a malicious majority collaborating with one participant can take the other’s stake through false timing attestations or by enabling a late response. Noncustodial committee membership therefore does not eliminate counterparty-and-committee risk. Draft security analysis, sections 8–9
Gibson also warns that participants depend heavily on staying available: remaining offline too long can cause a loss. His suggested applications include storage contracts that require periodic proof from a provider. These are proposed uses, rather than evidence of services already operating. Announcement and application discussion
What the prototype actually establishes
The repository explicitly warns against production use with real money. Its browser demonstrations run on a local regtest network, with five venue members and one channel between the players. They do not connect to mainnet, testnet or signet. Routing, venue fee payments and fidelity bonds are among the missing pieces. The author also discloses that the codebase is AI-generated. Project status and caveats
Those disclosures materially limit the conclusion. This article reviews the published design and documentation; it does not report an independent code audit, reproduced benchmark or live deployment test. A working demonstration, as described by its author, cannot establish security under production network conditions.
Analysis of the practical tradeoffs
The proposal’s significance is the tradeoff it makes explicit. A bounded transaction count is a useful design target, but it is only one measure of a dispute’s cost. Transaction size, fee conditions, preparation work and response deadlines would also matter to anyone evaluating a real application.
Committee selection deserves equal attention. An assessment should ask how participants identify genuinely independent members, what evidence exposes false attestations, and what happens when members become unavailable together. Describing a committee as noncustodial does not answer those questions.
For now, LN-GAP is a research proposal with a concrete prototype and clearly stated missing components. The next meaningful evidence would be independent review, adversarial testing and demonstrated recovery under failures. Evaluations should measure the difficult exits as carefully as normal operation: who must respond, how quickly, and what resources they need when cooperation stops. Those results would help establish where the contract model is useful, and whether its extra assumptions are acceptable for a particular application.