From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 11 Oct 2026 08:36:38 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xFvbJ-0000Tj-CI for bitcoindev@gnusha.org; Sun, 11 Oct 2026 08:36:38 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-6dd94f8fa25sf1960732eaf.2 for ; Sun, 11 Oct 2026 08:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1791732991; x=1792337791; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=uQPpA2Uy8u9R3IrfUlCCs+gQ1A4xSeOQsMEOhSkClBQ=; b=JdIeG6Tpoz8LnyKLQ4hk4LLaxjQ7t+Kc+3PwtcDqRl8IHQmfJL0vEtG/lk7QWTHBMI yevsdW5k+fvSbiMmbC31JgGS67BQe3Kp/zRHthFczqpQ59PZsf5XR00QjaM3k6pYSpFq UwfXAoCBNMFX8yNE2WlHMgdn9WUJRNunfPRs4fVsjTsRJsWlwmefPO84CGF41sDGzW7O r0mNOROXJ3oxu5CnRglXv6974H2BykimKaM6y13WYeth1m0njOUdlNWdgRzhiLhmxAFV EStswMZCdK5pyuPxXNKGfPhyylMZrSrysjs6aphkygCjJnt6SQ4cOS/VHVMmquWjHT4V cF4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791732991; x=1792337791; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=uQPpA2Uy8u9R3IrfUlCCs+gQ1A4xSeOQsMEOhSkClBQ=; b=C+j/3QtZm3e+mQWSZWu2U5LmeMdgtOe3nU3nwW7Gl712iiWbv6VsdX7nhmacsOCU/f GmC9cLzADCjI/jQp6Gn1aby2xEmG661MKClfkgj6EJdzrjKnlT08639iYBTYojDHEXIM iRh7QUgCWA6Dvo3v8+tIPVSm2xg8FaqNRLwrnATPXQIS9pwcbpvTkpGWImqULShFHrNZ W5i2ewtDFSbaqg34AxvvX6Cc801wYVa6+HF2Ps+gTXZnWadZm3T36uiqjyhWcQ0dOHnG /nRqhLyXUTxkoij+zw6m/SNEftfDRvgcefTqVpAMIs7LvQ/cNX3rfjOYyRh/s0YkwIob /0uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791732991; x=1792337791; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=uQPpA2Uy8u9R3IrfUlCCs+gQ1A4xSeOQsMEOhSkClBQ=; b=imOcMv5VvcN7ODqSPOCUJHw77oMUwA7hMPOzqP9dHqYqDT82qkRNr3hTxlxd/AdQzB IYaL8DiGnx02HrvC9C3uRVTuJnFZiWR1F1QYKboIzhqULgl7g+/am8ius380hbpYVeiZ 5mL8PSd+YbOas49F9eruiZhlLuQ7SQhhxRQMfLLXj6XlZsOPyRUgRbeUqyigMpWiKei/ gAJAY2lhFoZPHaX+gFOGdNfphf+DhkQNbRE0sWryHu/D3Yu6nuayrYHMDn/s08Uj0RhZ nNXwF3cyEnyFY8Ez/q/L3z2cybuQz9iYtDoOonXcabyMBKFr03esPJWBHIonnErqaQzu gVXg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBwhDWaDBpmFLoNSjy+1xaSCuCF7I3BU18s7DWfX9cS8t3xDPnpc1Yaj/bjJJWVwDFSi1YmPu+6dYX97@gnusha.org X-Gm-Message-State: AFq9FYJqgu3Pqib0zT3LN4UhxfYbmPcyh9vcpv7bWswRDbbRFyV6G1kp P7ShxWt46o46UuA4xKh1BlXyB/PArl4AGZHhTbLAoCkb7UUcWwe1LlHm X-Received: by 2002:a05:6820:350c:20b0:6f4:80f6:6ae9 with SMTP id 006d021491bc7-6f480f6a5ccmr806517eaf.27.1791732990959; Sun, 11 Oct 2026 08:36:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdetM3Yq+1mGPPnnoF2QzUDi2K+hJch8hwSYsIWVTnwJ0Q==" Received: by 2002:a05:6870:c446:20b0:49e:10a8:1b61 with SMTP id 586e51a60fabf-4a2a8b18ee8ls1926259fac.0.-pod-prod-03-us; Sun, 11 Oct 2026 08:36:23 -0700 (PDT) X-Received: by 2002:a05:6808:518c:b0:4f6:5279:5c83 with SMTP id 5614622812f47-50c42a24b54mr6365323b6e.8.1791732983478; Sun, 11 Oct 2026 08:36:23 -0700 (PDT) Received: by 2002:a05:690c:931b:20b0:8b0:7cd2:a7ee with SMTP id 00721157ae682-8b07cd2bfbbms7b3; Sun, 11 Oct 2026 08:03:02 -0700 (PDT) X-Received: by 2002:a05:690e:1509:b0:675:380d:88bb with SMTP id 956f58d0204a3-6793602f67cmr2250912d50.53.1791730981910; Sun, 11 Oct 2026 08:03:01 -0700 (PDT) Date: Sun, 11 Oct 2026 08:03:01 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n@googlegroups.com> Subject: [bitcoindev] Lichen: L2s In CHannels ENforced on bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_36346_1353406777.1791730981584" X-Original-Sender: ekaggata@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_36346_1353406777.1791730981584 Content-Type: multipart/alternative; boundary="----=_Part_36347_713188824.1791730981584" ------=_Part_36347_713188824.1791730981584 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, The one-sentence version: L2s funded via co-owned 2 of 2 contracts with a= =20 single hub entity, without trusting it. I'll summarize here by copying the= =20 abstract of the paper [1], followed by a sort of Q&A; I think that's best= =20 way to convey the idea. A contract with a hub lets a user hold the hub=E2=80=99s tokens on a layer = 2 and=20 withdraw them as bitcoin without trusting the hub for honesty or liveness.= =20 The L2 tokens are collateralised by the bitcoin in the user-hub multisig=20 output, and if the hub refuses a withdrawal, or cannot answer because it is= =20 offline, it is enforced on Bitcoin. The only assumptions are those of the= =20 layer 2 itself, kept apart from the hub. No change to Bitcoin=E2=80=99s con= sensus=20 is required. A withdrawal is a claim that a program, the withdrawal=20 statement, ran on some input and produced an output: the statement is=20 proved with RISC Zero and wrapped in Groth16, and a disputed claim is=20 settled on Bitcoin by BitVMX [5], whose interactive search over the=20 execution of a RISC-V program, here a Groth16 verifier, is the technical=20 core of the design. Withdrawals are executed cooperatively in the channel = =E2=80=94=20 with overwhelming likeliness because the statement is deterministically=20 verifiable in milliseconds =E2=80=94 or, otherwise, a refused one is played= as=20 BitVMX=E2=80=99s on-chain search, pre-signed once per contract. The trustle= ssness=20 gain is paid for with liquidity (with receiving ability only contingent on= =20 offered =E2=80=9Cinbound=E2=80=9D from the hub, as in Lightning). The hub (= but not user)=20 must also stay live during normal operation, since an offline hub loses=20 disputes by timeout. The design is built and measured on regtest: a real=20 proof of the withdrawal statement is accepted by BitVMX=E2=80=99s unpatched= Groth16=20 verifier in 478 million steps, implying about 22=E2=80=9325 transactions of= 8-ary=20 search on chain in the dispute=E2=80=99s worst case. Here is my 'Q&A' approach which I hope will address the first things you'd= =20 think of: *One central hub is dangerous! If the hub disappears, the user gets the money. The hub cannot Sybil attack= =20 users by printing tokens fictitiously; the honest users' money is all=20 backed. The only remaining risks are inherent to the L2 itself (is it a=20 validity rollup or a quorum? Does it inherit finality from Bitcoin or is=20 finality weaker? Etc.) *Bridges usually mean you can only withdraw a fixed size utxo, meaning=20 operators and relying on swaps. Surely that applies here? No. The withdrawal amount is encoded in bits in the bitcoin transaction=20 witness, in dispute. This allows us to withdraw arbitrary amounts via=20 multiple outputs of certain denominations. *Don't these constructions usually require a 1 of n honesty assumption from= =20 a signing committee? Not here: we avoid this by the LN-GAP trick: the contract is a bilateral=20 contract between the hub and each user; the presigning happens between=20 them, just as in Lightning. *But if a bunch of users open channels with a hub, they can just .. pay=20 each other through the channels? A correct critique, partly, *if* the L2 ledger doesn't do anything but=20 plain payments. Even then, you would avoid receiver liveness being needed,= =20 avoid routing and other minor things. But the real answer is: the L2 can=20 offer more functionality. It can use zcash style shielded notes, allowing= =20 very high privacy while staying in the L2. It can also (in a different=20 ``lichen'' on a different hub) offer rich smart contracting, etc. *But this an IOU/ hub's token, so it's not actually bitcoin. Incorrect with a crucial caveat. See the first point: every sat is=20 redeemable via the user-hub contracts, *without* the hub's permission,=20 one-to-one, so these are actually bitcoin *but only as long as you have=20 liquidity to receive them*. A new user on L2 without a contract with the=20 hub, or a user holding a balance on L2 far in excess of their inbound=20 liquidity in their own contract, is holding *credit*, and has no such=20 guarantee. But that's their choice. *But still, a single central hub feels like bad design. Why not multiple=20 hubs? It's because of what these L2 tokens are. They are fungible,=20 *enforceable*claims on the hub's money; they are minted by the hub itself,= =20 just on its own say-so. If you had hub 1 and hub 2, those claims are not=20 transferrable trustlessly to the hubs themselves. If hub 2 prints a billion= =20 sats out of nothing and users accept it on the L2 they can redeem it with= =20 hub1, leaving hub1 out of pocket. From this line of thinking we see an=20 interesting comparison with ecash servers: the hub can print as much as it= =20 likes, but it cannot steal/``rug''. *So what's the catch? The negatives are twofold: one is liquidity, and this is easy to=20 understand as the analog of the inbound liquidity pain point in Lightning,= =20 because it's basically the same thing. Such a hub *can* give no inbound=20 liquidity to a user: they get tokens on L2 to spend, but they cannot=20 (safely) receive. If they receive, it's just credit that someone else will= =20 hopefully buy from them. But the design does not assume that, of course, it= =20 allows receiving up to a ``cap'': the user negotiates that extra potential= =20 receiving amount (inbound liquidity) when it sets up the contract with the= =20 hub. The second negative is very concrete, and is a design decision rather= =20 than an absolute requirement: we use BitVMX's bisection (in fact 8-ary not= =20 binary) to enforce that the ZKP is valid, on-chain. In the worst case this= =20 is 20-25 transactions and may require watchtower design to be easy enough= =20 for users to fully rely on. In a correctly built implementation this is=20 exceptionally rare because the incorrect party (trivially established) is= =20 guaranteed to pay all the fees (up to its reserve), and lose money. A lot more detail in [1] of course. And that repo has a "full"=20 proof-of-concept demo (includes the entire L2 inclusion proof to STARK to= =20 Groth16 verification of STARK; it's the groth16 verifier that goes into the= =20 on-chain dispute). I think this design is genuinely interesting. Certainly more limited than a= =20 completely generic L2 (not in functionality; in scale), but also more=20 practically achievable (in fact I don't think anything stops someone=20 instantiating lichen fully, right now [2]). I guess, many ways to look at= =20 it. Feedback welcome. (Oh, one more thing: why BitVMX's version of these things, with its=20 multiple onchain rounds? it's mainly because it can actually be built. I=20 don't know the actual current status of various schemes like BitVM3, BABE,= =20 Glock and its descendants, PIPES and so on; of these, maybe BABE is the=20 most interesting alternative, for Lichen specifically? Not sure). Cheers, AdamISZ/waxwing [1] the paper is at=20 https://github.com/AdamISZ/lichen/blob/master/papers/lichen-draft.pdf=20 [2] contingent on being confident in all the tricky details of implementing= =20 BitVMX's dispute game. No small matter, you can easily "do" it by telling= =20 an LLM to do it, but there's a lot of moving parts that need checking=20 carefully. I speak from experience, and I will probably have more such=20 experience soon ... --=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/= 9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n%40googlegroups.com. ------=_Part_36347_713188824.1791730981584 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

The one-sentence version: L2s funded via co-o= wned 2 of 2 contracts with a single hub entity, without trusting it. I'll s= ummarize here by copying the abstract of the paper [1], followed by a sort = of Q&A; I think that's best way to convey the idea.

A contract with a hub lets a user hold the hub=E2=80=99s tokens on a lay= er 2 and withdraw them as bitcoin without trusting the hub for honesty or l= iveness. The L2 tokens are collateralised by the bitcoin in the user-hub mu= ltisig output, and if the hub refuses a withdrawal, or cannot answer becaus= e it is offline, it is enforced on Bitcoin. The only assumptions are those = of the layer 2 itself, kept apart from the hub. No change to Bitcoin=E2=80= =99s consensus is required. A withdrawal is a claim that a program, the wit= hdrawal statement, ran on some input and produced an output: the statement = is proved with RISC Zero and wrapped in Groth16, and a disputed claim is se= ttled on Bitcoin by BitVMX [5], whose interactive search over the execution= of a RISC-V program, here a Groth16 verifier, is the technical core of the= design. Withdrawals are executed cooperatively in the channel =E2=80=94 wi= th overwhelming likeliness because the statement is deterministically verif= iable in milliseconds =E2=80=94 or, otherwise, a refused one is played as B= itVMX=E2=80=99s on-chain search, pre-signed once per contract. The trustles= sness gain is paid for with liquidity (with receiving ability only continge= nt on offered =E2=80=9Cinbound=E2=80=9D from the hub, as in Lightning). The= hub (but not user) must also stay live during normal operation, since an o= ffline hub loses disputes by timeout. The design is built and measured on r= egtest: a real proof of the withdrawal statement is accepted by BitVMX=E2= =80=99s unpatched Groth16 verifier in 478 million steps, implying about 22= =E2=80=9325 transactions of 8-ary search on chain in the dispute=E2=80=99s = worst case.

Here is my 'Q&A' approach which I hope will address t= he first things you'd think of:


*One central hub is dang= erous!

If the hub disappears, the user gets the money. The hub cannot= Sybil attack users by printing tokens fictitiously; the honest users' mone= y is all backed. The only remaining risks are inherent to the L2 itself (is= it a validity rollup or a quorum? Does it inherit finality from Bitcoin or= is finality weaker? Etc.)


*Bridges usually mean you can only w= ithdraw a fixed size utxo, meaning operators and relying on swaps. Surely t= hat applies here?

=C2=A0No. The withdrawal amount is encoded in bits = in the bitcoin transaction witness, in dispute. This allows us to withdraw = arbitrary amounts via multiple outputs of certain denominations.

*Don't these constructions usually require a 1 of n honesty assumption fro= m a signing committee?

Not here: we avoid this by the LN-GAP trick: t= he contract is a bilateral contract between the hub and each user; the pres= igning happens between them, just as in Lightning.

*But if a bun= ch of users open channels with a hub, they can just .. pay each other throu= gh the channels?

A correct critique, partly, *if* the L2 ledger doesn= 't do anything but plain payments. Even then, you would avoid receiver live= ness being needed, avoid routing and other minor things. But the real answe= r is: the L2 can offer more functionality. It can use zcash style shielded = notes, allowing very high privacy while staying in the L2. It can also (in = a different ``lichen'' on a different hub) offer rich smart contracting, et= c.

*But this an IOU/ hub's token, so it's not actually bitcoin.<= /p>

Incorrect with a crucial caveat. See the first point: every sat is re= deemable via the user-hub contracts, *without* the hub's permission, one-to= -one, so these are actually bitcoin *but only as long as you have liquidity= to receive them*. A new user on L2 without a contract with the hub, or a u= ser holding a balance on L2 far in excess of their inbound liquidity in the= ir own contract, is holding *credit*, and has no such guarantee. But that's= their choice.


*But still, a single central hub feels like bad = design. Why not multiple hubs?

It's because of what these L2 tokens a= re. They are fungible, *enforceable*claims on the hub's money; they are min= ted by the hub itself, just on its own say-so. If you had hub 1 and hub 2, = those claims are not transferrable trustlessly to the hubs themselves. If h= ub 2 prints a billion sats out of nothing and users accept it on the L2 the= y can redeem it with hub1, leaving hub1 out of pocket. From this line of th= inking we see an interesting comparison with ecash servers: the hub can pri= nt as much as it likes, but it cannot steal/``rug''.

*So what's = the catch?

=C2=A0The negatives are twofold: one is liquidity, and thi= s is easy to understand as the analog of the inbound liquidity pain point i= n Lightning, because it's basically the same thing. Such a hub *can* give n= o inbound liquidity to a user: they get tokens on L2 to spend, but they can= not (safely) receive. If they receive, it's just credit that someone else w= ill hopefully buy from them. But the design does not assume that, of course= , it allows receiving up to a ``cap'': the user negotiates that extra poten= tial receiving amount (inbound liquidity) when it sets up the contract with= the hub. The second negative is very concrete, and is a design decision ra= ther than an absolute requirement: we use BitVMX's bisection (in fact 8-ary= not binary) to enforce that the ZKP is valid, on-chain. In the worst case = this is 20-25 transactions and may require watchtower design to be easy eno= ugh for users to fully rely on. In a correctly built implementation this is= exceptionally rare because the incorrect party (trivially established) is = guaranteed to pay all the fees (up to its reserve), and lose money.

A= lot more detail in [1] of course. And that repo has a "full" proof-of-conc= ept demo (includes the entire L2 inclusion proof to STARK to Groth16 verifi= cation of STARK; it's the groth16 verifier that goes into the on-chain disp= ute).

I think this design is genuinely interesting. Certainly more li= mited than a completely generic L2 (not in functionality; in scale), but al= so more practically achievable (in fact I don't think anything stops someon= e instantiating lichen fully, right now [2]). I guess, many ways to look at= it. Feedback welcome.

(Oh, one more thing: why BitVMX's version of t= hese things, with its multiple onchain rounds? it's mainly because it can a= ctually be built. I don't know the actual current status of various schemes= like BitVM3, BABE, Glock and its descendants, PIPES and so on; of these, m= aybe BABE is the most interesting alternative, for Lichen specifically? Not= sure).

Cheers,

AdamISZ/waxwing

[1] the paper is at https= ://github.com/AdamISZ/lichen/blob/master/papers/lichen-draft.pdf

[2]= contingent on being confident in all the tricky details of implementing Bi= tVMX's dispute game. No small matter, you can easily "do" it by telling an = LLM to do it, but there's a lot of moving parts that need checking carefull= y. I speak from experience, and I will probably have more such experience s= oon ...

--
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/9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n%40googlegroups.com.
------=_Part_36347_713188824.1791730981584-- ------=_Part_36346_1353406777.1791730981584--