From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 11 Oct 2026 16:50:58 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.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 1xG3Jh-0004p5-9K for bitcoindev@gnusha.org; Sun, 11 Oct 2026 16:50:58 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-46788f14fe6sf205176fac.3 for ; Sun, 11 Oct 2026 16:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1791762651; x=1792367451; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:references:in-reply-to:message-id :to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ECiGxTXtDxhn4jMMsW97NsIeKyEbxdGsbLnPJvNrKPY=; b=nmHJGW2vIwlKLUt5nUbFqGofEQj9R/PeHYHSgoDVlCA3Pp2ihK8Tp3A3goSaR5AE7k Llewi9iWTsnwvYiJ7+sOvLrk/K+y4HMgFatwk4jWkNCX4zkNJTATqpfMHKgtdzR5EzuC hABOykvfFcmPbjXvcGEq/jELmNS4KHFqhXjCAR+Ap6M3O/okkz7zU/EWXyEcCelsSpKA r1YGVoHC3x//T8J4+7gigY1ANPV+ABYeLZu46vfqYiMCvXQT7kVxAmGzKljAVZvQqXUE QWrFSlE8uDuY3Tl6wklIdmHwVdTYpT3HlSBe0ewgAN/HAI/+NvWLZPdzijWKWaUBi2oV DzcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791762651; x=1792367451; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:references:in-reply-to:message-id :to:from:date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ECiGxTXtDxhn4jMMsW97NsIeKyEbxdGsbLnPJvNrKPY=; b=zbXZ1vKBzLAOR6VZzdWxJW39Cylm7BulBTnFs3Znv44EaW8edeHlEkKGURM2EfGcVm 1gsUzgX9ez5nM+WclwEk3q3V806+2h2gXTed+7FJv4MkX08I1No2HRGnJl+z98dYlYLn mzNEH21TVFbhDSMncyyH8MzjRe7VBMAwd11ZMh84Hb2CUeLVTGV0CP1r/1FqXD3XAKuL 1C5Z9klbkKyBvdUOLDhTtNjpmsm8I3NnwGQx4VokgLZMZ25iLALHiOntraDsT3Ubz9Y8 IxyD7QBT+6tXFH+IYpaT7uIXESDfCUezixKHvWgLOlNzrNGQh2OjUe9esTExGet7cSan PmZg== X-Forwarded-Encrypted: i=1; AKwUvBwrRJKST8pSJsIYGqJr+34rCCciuwSae1oNTyeQO7eyjvDoihwNmcwWW++wME6F000gWOBGea0NXH3t@gnusha.org X-Gm-Message-State: AFq9FYLofjj0b2uz1tuZTEyol/b5aTXY+0TperLCSgDLHKYy85R2GqQy fUrtQ8XXepfFsAS8BgulL015d0VxTRTwymVsLdoI5OYSijFY8N3cwUD6 X-Received: by 2002:a05:6870:cb95:b0:49d:cae1:d45e with SMTP id 586e51a60fabf-4a2a89bd8b0mr8714579fac.2.1791762651309; Sun, 11 Oct 2026 16:50:51 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcJV3dGCEprVbFB5YWDr2GhLoTJ8zGinBSGYQuhiJA7lw==" Received: by 2002:a05:6871:8705:20b0:47c:a13:eae2 with SMTP id 586e51a60fabf-4a2a98b10d0ls2290416fac.1.-pod-prod-08-us; Sun, 11 Oct 2026 16:50:42 -0700 (PDT) X-Received: by 2002:a05:6808:13d5:b0:4ef:e154:41fb with SMTP id 5614622812f47-50c45c67757mr7413453b6e.1.1791762642519; Sun, 11 Oct 2026 16:50:42 -0700 (PDT) Received: by 2002:a05:690c:8685:20b0:8ae:b617:7167 with SMTP id 00721157ae682-8b07c42d4a3ms7b3; Sun, 11 Oct 2026 16:46:26 -0700 (PDT) X-Received: by 2002:a05:690c:386:b0:8a8:88f1:b4d4 with SMTP id 00721157ae682-8b07ee782admr32556167b3.43.1791762385615; Sun, 11 Oct 2026 16:46:25 -0700 (PDT) Date: Sun, 11 Oct 2026 16:46:25 -0700 (PDT) From: "'Dustin Ray' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <3c10a867-fc2a-4b28-ab5b-75d8de050c3bn@googlegroups.com> In-Reply-To: <9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n@googlegroups.com> References: <9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n@googlegroups.com> Subject: [bitcoindev] Re: Lichen: L2s In CHannels ENforced on bitcoin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_134231_1981198544.1791762385330" X-Original-Sender: dustin.ray@anchorlabs.com X-Original-From: Dustin Ray Reply-To: Dustin Ray 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: -1.0 (-) ------=_Part_134231_1981198544.1791762385330 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi AdamISZ/waxwing Overall this is an interesting proposal. On Groth16, is it responsible to= =20 advocate for deploying additional PQ-vulnerable infrastructure to bitcoin= =20 right now? The CRS from RiscZero is DL vulnerable and if it falls to a=20 Quantum machine, statements are easily forged and under your proposal,=20 funds are at risk. On Sunday, October 11, 2026 at 8:36:31=E2=80=AFAM UTC-7 waxwing/ AdamISZ wr= ote: > 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 th= e=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 laye= r 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 c= onsensus=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 play= ed as=20 > BitVMX=E2=80=99s on-chain search, pre-signed once per contract. The trust= lessness=20 > gain is paid for with liquidity (with receiving ability only contingent o= n=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 unpatch= ed 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=20 > attack users by printing tokens fictitiously; the honest users' money is= =20 > all 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=20 > from 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 billi= on=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 i= t=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 wil= l=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 potentia= l=20 > receiving amount (inbound liquidity) when it sets up the contract with th= e=20 > hub. The second negative is very concrete, and is a design decision rathe= r=20 > than an absolute requirement: we use BitVMX's bisection (in fact 8-ary no= t=20 > binary) to enforce that the ZKP is valid, on-chain. In the worst case thi= s=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 t= he=20 > on-chain dispute). > > I think this design is genuinely interesting. Certainly more limited than= =20 > a 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=20 > implementing BitVMX's dispute game. No small matter, you can easily "do" = it=20 > by telling an LLM to do it, but there's a lot of moving parts that need= =20 > checking carefully. I speak from experience, and I will probably have mor= e=20 > such experience soon ... > --=20 This message is intended only for the named recipient(s) above. It may=20 contain legally privileged or confidential information. If you are not the= =20 intended recipient, you are hereby notified that any use, dissemination,=20 distribution or copying of this e-mail and any attachment(s) is strictly=20 prohibited. If you have received this message in error, please notify the= =20 sender by replying to this e-mail with a copy to=C2=A0legal@anchorage.com= =20 , and deleting the message and any=20 attachment(s) from your system. Please refer to=C2=A0 https://www.anchorage.com/privacy-policy=20 --=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/= 3c10a867-fc2a-4b28-ab5b-75d8de050c3bn%40googlegroups.com. ------=_Part_134231_1981198544.1791762385330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi AdamISZ/waxwing

Overall this is an interesting proposal= . On Groth16, is it responsible to advocate for deploying additional PQ-vul= nerable infrastructure to bitcoin right now? The CRS from RiscZero is DL vu= lnerable and if it falls to a Quantum machine, statements are easily forged= and under your proposal, funds are at risk.


On Sunday, October 11,= 2026 at 8:36:31=E2=80=AFAM UTC-7 waxwing/ AdamISZ wrote:
Hi list,

Th= e one-sentence version: L2s funded via co-owned 2 of 2 contracts with a sin= gle hub entity, without trusting it. I'll summarize 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 a= ddress the first things you'd think of:


*One central h= ub is dangerous!

If the hub disappears, the user gets the money. The = hub cannot Sybil attack users by printing tokens fictitiously; the honest u= sers' money 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 f= rom Bitcoin or is finality weaker? Etc.)


*Bridges usually mean yo= u can only withdraw a fixed size utxo, meaning operators and relying on swa= ps. Surely that applies here?

=C2=A0No. The withdrawal amount is enco= ded 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 as= sumption from a signing committee?

Not here: we avoid this by the LN-= GAP trick: the contract is a bilateral contract between the hub and each us= er; the presigning happens between them, just as in Lightning.

*But = if a bunch of users open channels with a hub, they can just .. pay each oth= er through the channels?

A correct critique, partly, *if* the L2 ledg= er doesn't do anything but plain payments. Even then, you would avoid r= eceiver liveness being needed, avoid routing and other minor things. But th= e real answer is: the L2 can offer more functionality. It can use zcash sty= le shielded notes, allowing very high privacy while staying in the L2. It c= an also (in a different ``lichen'' on a different hub) offer rich s= mart contracting, etc.

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

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


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

It's= because of what these L2 tokens are. They are fungible, *enforceable*claim= s on the hub's money; they are minted by the hub itself, just on its ow= n say-so. If you had hub 1 and hub 2, those claims are not transferrable tr= ustlessly to the hubs themselves. If hub 2 prints a billion sats out of not= hing and users accept it on the L2 they can redeem it with hub1, leaving hu= b1 out of pocket. From this line of thinking we see an interesting comparis= on with ecash servers: the hub can print as much as it likes, but it cannot= steal/``rug''.

*So what's the catch?

=C2=A0The ne= gatives are twofold: one is liquidity, and this is easy to understand as th= e analog of the inbound liquidity pain point in Lightning, because it's= basically the same thing. Such a hub *can* give no inbound liquidity to a = user: they get tokens on L2 to spend, but they cannot (safely) receive. If = they receive, it's just credit that someone else will hopefully buy fro= m them. But the design does not assume that, of course, it allows receiving= up to a ``cap'': the user negotiates that extra potential receivin= g amount (inbound liquidity) when it sets up the contract with the hub. The= second negative is very concrete, and is a design decision rather than an = absolute requirement: we use BitVMX's bisection (in fact 8-ary not bina= ry) to enforce that the ZKP is valid, on-chain. In the worst case this is 2= 0-25 transactions and may require watchtower design to be easy enough for u= sers to fully rely on. In a correctly built implementation this is exceptio= nally rare because the incorrect party (trivially established) is guarantee= d 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-con= cept demo (includes the entire L2 inclusion proof to STARK to Groth16 verif= ication of STARK; it's the groth16 verifier that goes into the on-chain= dispute).

I think this design is genuinely interesting. Certainly mo= re limited than a completely generic L2 (not in functionality; in scale), b= ut also more practically achievable (in fact I don't think anything sto= ps someone instantiating lichen fully, right now [2]). I guess, many ways t= o look at it. Feedback welcome.

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

Cheers,

AdamISZ/waxwing

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

[2] contingen= t on being confident in all the tricky details of implementing BitVMX'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 = carefully. I speak from experience, and I will probably have more such expe= rience soon ...


This message is intended only for the named recipient(s) above. It may cont= ain legally privileged or confidential information. If you are not the inte= nded recipient, you are hereby notified that any use, dissemination, distri= bution or copying of this e-mail and any attachment(s) is strictly prohibit= ed. If you have received this message in error, please notify the sender by= replying to this e-mail with a copy to=C2=A0legal@anchorage.com, and deleting the messag= e and any attachment(s) from your system. Please refer to=C2=A0https://www.anch= orage.com/privacy-policy

--
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/3c10a867-fc2a-4b28-ab5b-75d8de050c3bn%40googlegroups.com.
------=_Part_134231_1981198544.1791762385330--