From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 01 Nov 2026 01:10:54 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xNRaV-000163-NP for bitcoindev@gnusha.org; Sun, 01 Nov 2026 01:10:53 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-70b97cf79cdsf2248314eaf.1 for ; Sun, 01 Nov 2026 01:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1793524245; x=1794129045; 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:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=6ucy22JHOqYq5NeU1oJE/uH8zDb0aQ+Wg5p8eIuF91Q=; b=Ov5LIeTR0fCc5ta8ac9K7xcIAHgmTdbfoAXr9PIzqlOlhxSWE3NXSNqg0i+MdKPZpp iHBBEu0D7dPw5672TNZBu+2iLsKGx0nluW6FQly2pBs7NufKsGr+Pg0y4JxeCAsuY4eo evSlZMUZUxpuh6oXVlvDzlGR0RJ3Errew4MRK2OvCJOkwz9dO4B2IjymNoklyuf7i5qY 9Th/qi/IfwWbPi1x9Lcq4+v2n4DnDK+Z37oobOA0+5QwyBjssNGTYP0IgVG2PDaL4IqB UE/W96OBvztn+8Vxw5D6FpRIg4xyEnUPihJKZijuamVkBBr2mx2adJ6H8Np+o0hg6p7g 4KiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793524245; x=1794129045; 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:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=6ucy22JHOqYq5NeU1oJE/uH8zDb0aQ+Wg5p8eIuF91Q=; b=ElulB2Vu2dox/aqa2C3oMhZPptfR4qSMSmKLhNALnDUCcXBvRnx0LZDzJzLAp09IMy 6DqADVRpYvbWiusbwkEWSdyDHR6I0e48l2RpA0WjBdNy1ddivog2yLA240XaPGwMJfPR JauE2zwBD5MXg3Kr7cU0ezA/v7HBTfmcPol/cv7i8K+i84IPJ5CzLS7uyCL/JJO91XY5 eE2We8kSZPkRhh+yW7P3PbKTdMo71kXfqI/Yut4b/ld6/PprdNTWPpN1Zqg9fu76hxma hG3Okj691bFhE5imePvyUl7SVQzPsKfGL1E82nIThvs9UYiMJN4DbV9XZKvV9tYxJvZJ jflA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793524245; x=1794129045; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6ucy22JHOqYq5NeU1oJE/uH8zDb0aQ+Wg5p8eIuF91Q=; b=h6vTBQCfHMAphUjE8W7kmX3oGAZnWE/TAYOOrvY695fFHiYJ6KS8EH+etgmOTFw7tE /FDaAqKxwrV2AjmK//5lOIrHI2lN2wn5GTyWjTP7xf9C+23iPAP9NYg8Dz39RWkoAa5j hN6S6/0jm5QLvcJ/N05oczM1/fTVBRtrIm7Xf0tGj8ubKksrxNg76QJK7naGX37vkw/V fNW2+uUpmJrtaoBkN63Vjm06NCCBGVV3UPrAn08oQB4QuUcpatUF3MFzg7V4XbrugRTx OxPUfRaNSGQ5czxEpYnI+Dg9JD+Z+2v4tZYUym6mPKBMdIjX812uVb/e3x48iq4Qf3I3 T5Hw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBw77AE215l4jHXqCKdvUEx7oRtiEte7m4r+wVi9oiiimg1cJnIbenZbyphE0jIrmVEMeMaG7EACtQMH@gnusha.org X-Gm-Message-State: AFq9FYIEcoZ+ahvz5gg3L9RrChDRxPynNH2rd4u9+EFX746o2k+ZjuTL sWyi+N4iXntfyi3VvFsV1BtIeQ4Uxqkz86E/9sR9VcIwVYvskqe9lhDt X-Received: by 2002:a05:6820:2218:b0:714:b768:31e4 with SMTP id 006d021491bc7-714f24f7a0amr3900325eaf.1.1793524245126; Sun, 01 Nov 2026 01:10:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddPLtL7gftaO7v+1NCK4NPFclSvxi5QNcO9B0nRAW2rNw==" Received: by 2002:a05:6820:c217:b0:70e:177b:eb56 with SMTP id 006d021491bc7-714f0e3836cls2470479eaf.2.-pod-prod-09-us; Sun, 01 Nov 2026 01:10:38 -0800 (PST) X-Received: by 2002:a05:6808:118a:b0:4f4:3790:65fd with SMTP id 5614622812f47-5640de0e9fdmr4982942b6e.29.1793524238807; Sun, 01 Nov 2026 01:10:38 -0800 (PST) Received: by 2002:a05:690c:a58d:b0:8a6:990a:8ca5 with SMTP id 00721157ae682-8b2b49dc994ms7b3; Sat, 31 Oct 2026 23:24:05 -0700 (PDT) X-Received: by 2002:a05:690c:9d:b0:8b0:cd30:ce86 with SMTP id 00721157ae682-8b2b678b122mr36612117b3.78.1793514244648; Sat, 31 Oct 2026 23:24:04 -0700 (PDT) Date: Sat, 31 Oct 2026 23:24:04 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn@googlegroups.com> References: <9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n@googlegroups.com> <3c10a867-fc2a-4b28-ab5b-75d8de050c3bn@googlegroups.com> <4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn@googlegroups.com> Subject: [bitcoindev] Re: Lichen: L2s In CHannels ENforced on bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_106029_191802302.1793514244318" 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_106029_191802302.1793514244318 Content-Type: multipart/alternative; boundary="----=_Part_106030_1361569006.1793514244318" ------=_Part_106030_1361569006.1793514244318 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wanted to update on this a bit since it's changed significantly in the=20 last few weeks: By using a tweak [1] it's possible to apply BABE instead of BitVMX to the= =20 onchain dispute, drastically reducing both the number of transactions in a= =20 full dispute (around 4 to 5 instead of 20-25) and the onchain cost (now=20 around 30kvb not 200). The EC scalar mult garbled circuit needs the user to= =20 store 240MB [2] but it's otherwise pretty cheap. BABE fits particularly=20 well with Lichen (a single, one off prove-disprove in the contract=20 pre-signing) and it makes it more reasonable with regard to any *mass exit= =20 risk* (which I didn't discuss in the OP; it's clearly the biggest concern= =20 if you deal with very large or long timescale disputes), such that a system= =20 like this with a single hub could reasonably support 10s of thousands=20 instead of perhaps only thousands of users. (Remember that, mass exit risk= =20 aside, the main bottleneck is the "LSP" style liquidity requirement on the= =20 hub entity). All of this is implemented in the codebase; I'm deploying a hub right now= =20 on mutinynet. The latest version of the paper [3] is cleaned up a lot to focus on the=20 pure lichen design as a 2 of 2 contract that enforces outcomes with a=20 "verification gadget" for whatever the L2 proves --- so that's now BABE by= =20 default as per above, though BitVMX still exists in the code too --- while= =20 a subsidiary paper [4] is there for those who want to see what the=20 codebase implements as an L2 (a sequencer, validity proofs, shielded notes,= =20 anchored in bitcoin for finality - all of this implemented but very rough= =20 around the edges!) There's nothing stopping anyone attaching Lichen to an entirely different= =20 L2 as long as you have state to verify: a signing quorum may be simplest,= =20 maybe some kind of proof of work or proof of stake consensus (with the work= =20 and stake being external to bitcoin), maybe an ethereum smart contract for= =20 example? I chose the cleanest thing I could think of: state updates proven= =20 valid, finality established with posting to bitcoin, and then the sequencer= =20 that bundles state updates being the hub (after all you never know if it=20 isn't!) so that a specific kind of proof-counterproof is needed to succeed= =20 in exiting from the maximally malicious hub; again, more detail on that in= =20 [4], but it's just an idiosyncratic choice I made because I thought it was= =20 interesting! Cheers, AdamISZ/waxwing [1] https://delvingbitcoin.org/t/variable-payout-amounts-for-babe-as-applie= d-to-lichen/2963 [2] This is based on using Glock's adaptors-based verifiable secret sharing= =20 to do a 10 of 78 cut and choose instead of the 1000s in the base BABE=20 design. Not my idea of course, not only Glock, but the BABE paper itself,= =20 suggests it. And maybe a lot less than 240MB with the recent Duty Free Bits= =20 research? I don't know, that's only speculation for now. [3] https://github.com/AdamISZ/lichen/blob/master/papers/lichen-v0.4.1.pdf [4] https://github.com/AdamISZ/lichen/blob/master/papers/lichen-built-v0.1.= 1.pdf=20 - this one is all AI written. It just exists to document how the "example= =20 L2" is built out, as a reference. The most interesting part is how you can= =20 guarantee exit even if the L2's operator - which here, *is* the hub, is=20 malicious. I think that still needs some careful examination, not least=20 around data availability, but it's already quite a strong model. On Monday, October 12, 2026 at 9:27:39=E2=80=AFPM UTC+9 waxwing/ AdamISZ wr= ote: > Hi Dustin, > > In short, yes, I think it *is* responsible! To advocate for my position: = I=20 > think it is irresponsible to *not* promote versions of bitcoin payment=20 > systems that give users a crucial advantage of freedom via privacy, in wa= ys=20 > that are practical, as well perhaps more functionality, more payment spee= d,=20 > if such a system can be built. I know that many others share this=20 > perspective. > > > The CRS from RiscZero is DL vulnerable > > Well, Groth16 in general is dependent not only on ECDLP but on the=20 > stronger assumptions behind using pairings (something like q-DLOG and etc= .=20 > , details, but: stronger in that the systems is more exposed to a potenti= al=20 > classical attack, but for quantum I guess it makes no difference). You're= =20 > right, afaik, that using the trapdoor/toxic waste would be a simple way t= o=20 > execute the attack, *if* it was broken. [1] > > So I see two general points I want to make about this:=20 > > 1/ the trivial point: Bitcoin currently relies on ECDLP, so the question= =20 > of whether some system 'attached' to it should be reliant on ECDLP only= =20 > becomes relevant once Bitcoin is no longer reliant on it. We're probably= =20 > some way off from that. A side system/L2 can use stronger assumptions=20 > reasonably and logically - the idea is that users are of course not force= d=20 > to take any interest in that system, they can simply not use it. The use = of=20 > such a system can be shut down voluntarily by groups of users, without a= =20 > consensus upgrade on L1, so it's safer, also, in that specific sense. > > 2/ The reason a whole bunch of 'do a surprisingly difficult thing in=20 > Bitcoin itself so that we can connect it to another system trustlessly'= =20 > proposals/projects (think: BitVM(N,X), Glock, BABE, PIPEsv2 and others), = as=20 > well as *many* other similar projects in cryptocurrency more generally, a= re=20 > using either Groth16, or (in case of PIPEs) experimental WE constructs, o= r=20 > similar, is because it's exceptionally difficult to get the properties yo= u=20 > need: full on compactness (in this case literally O(1) and concretely=20 > small) in communication and exceptionally cheap verification for an=20 > unlimited size of offchain computation. The cost is, no doubt, tremendous= :=20 > a trusted setup, pairings assumptions which are stronger than anything on= =20 > bitcoin itself, etc. > > To avoid the specific DL style dependencies, you might think, why not go= =20 > STARK only; why don't we do that (why doesn't Risc0 do that?): it's prett= y=20 > simple, STARKS are too big. A single STARK is not O(1) communication, but= =20 > with recursion it kinda sorta is. But we might be looking at 100kB-200kB = of=20 > proof size. You can't feed in a block that big into Script and have it be= =20 > signed (imagine megabytes and megabytes of data). I would not be in the= =20 > least surprised if someone in future "figures that out", but, uh, I=20 > certainly haven't! Groth16 is always 3 curve points, like 100-200 *bytes*= =20 > depending on your compression serialization. That, we can winternitz-sign= =20 > and shove into the witness. > > Perhaps new succinct verification systems will be dreamt up; I certainly= =20 > couldn't claim that something like lichen can "just slot those in", if th= ey=20 > are, but it might be true: because at the end of the day the current desi= gn=20 > (with BitVMX) can arbitrate an *arbitrary* computation with the number of= =20 > rounds being logarithmic in the number of computation steps. > > [1] Then there's the risk that's specific to the CRS for any Groth16=20 > instantiation - the trusted setup, separate but also something to pay=20 > attention to for sure: I took the time to look into the one behind=20 > RiscZero's instantiation, it's quite an interesting interaction between= =20 > human identities and cryptography! - anyway, sidetrack. > > Cheers, > AdamISZ/waxwing > On Sunday, October 11, 2026 at 8:50:51=E2=80=AFPM UTC-3 Dustin Ray wrote: > >> >> Hi AdamISZ/waxwing >> >> Overall this is an interesting proposal. On Groth16, is it responsible t= o=20 >> advocate for deploying additional PQ-vulnerable infrastructure to bitcoi= n=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= wrote: >> >>> Hi list, >>> >>> The one-sentence version: L2s funded via co-owned 2 of 2 contracts with= =20 >>> a single hub entity, without trusting it. I'll summarize here by copyin= g=20 >>> the abstract of the paper [1], followed by a sort of Q&A; I think that'= s=20 >>> best way to convey the idea. >>> >>> A contract with a hub lets a user hold the hub=E2=80=99s tokens on a la= yer 2 and=20 >>> withdraw them as bitcoin without trusting the hub for honesty or livene= ss.=20 >>> The L2 tokens are collateralised by the bitcoin in the user-hub multisi= g=20 >>> output, and if the hub refuses a withdrawal, or cannot answer because i= t is=20 >>> offline, it is enforced on Bitcoin. The only assumptions are those of t= he=20 >>> layer 2 itself, kept apart from the hub. No change to Bitcoin=E2=80=99s= consensus=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 technica= l=20 >>> core of the design. Withdrawals are executed cooperatively in the chann= el =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 pl= ayed as=20 >>> BitVMX=E2=80=99s on-chain search, pre-signed once per contract. The tru= stlessness=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 h= ub (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 rea= l=20 >>> proof of the withdrawal statement is accepted by BitVMX=E2=80=99s unpat= ched Groth16=20 >>> verifier in 478 million steps, implying about 22=E2=80=9325 transaction= s 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=20 >>> you'd 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 i= s=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 i= s=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 transactio= n=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 bilatera= l=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 need= ed,=20 >>> avoid routing and other minor things. But the real answer is: the L2 ca= n=20 >>> offer more functionality. It can use zcash style shielded notes, allowi= ng=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 th= e=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 multipl= e=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 itse= lf,=20 >>> just on its own say-so. If you had hub 1 and hub 2, those claims are no= t=20 >>> transferrable trustlessly to the hubs themselves. If hub 2 prints a bil= lion=20 >>> sats out of nothing and users accept it on the L2 they can redeem it wi= th=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 Lightni= ng,=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 w= ill=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 potent= ial=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 rat= her=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 t= his=20 >>> is 20-25 transactions and may require watchtower design to be easy enou= gh=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=20 >>> than a completely generic L2 (not in functionality; in scale), but also= =20 >>> more practically achievable (in fact I don't think anything stops someo= ne=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, BA= BE,=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 m= ore=20 >>> such experience soon ... >>> >> >> This message is intended only for the named recipient(s) above. It may= =20 >> contain legally privileged or confidential information. If you are not t= he=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 th= e=20 >> sender by replying to this e-mail with a copy to le...@anchorage.com,=20 >> and deleting the message and any attachment(s) from your system. Please= =20 >> refer to https://www.anchorage.com/privacy-policy >> > --=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/= eed59d04-8620-4b04-b97e-48d2432e74fbn%40googlegroups.com. ------=_Part_106030_1361569006.1793514244318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wanted to update on this a bit since it's changed significantly in the la= st few weeks:

By using a tweak [1] it's possible to ap= ply BABE instead of BitVMX to the onchain dispute, drastically reducing bot= h the number of transactions in a full dispute (around 4 to 5 instead of 20= -25) and the onchain cost (now around 30kvb not 200). The EC scalar mult ga= rbled circuit needs the user to store 240MB [2] but it's otherwise pretty c= heap. BABE fits particularly well with Lichen (a single, one off prove-disp= rove in the contract pre-signing) and it makes it more reasonable with rega= rd to any *mass exit risk* (which I didn't discuss in the OP; it's clearly = the biggest concern if you deal with very large or long timescale disputes)= , such that a system like this with a single hub could reasonably support 1= 0s of thousands instead of perhaps only thousands of users. (Remember that,= mass exit risk aside, the main bottleneck is the "LSP" style liquidity req= uirement on the hub entity).

All of this is impl= emented in the codebase; I'm deploying a hub right now on mutinynet.
<= div>
The latest version of the paper [3] is cleaned up a lo= t to focus on the pure lichen design as a 2 of 2 contract that enforces out= comes with a "verification gadget" for whatever the L2 proves --- so that's= now BABE by default as per above, though BitVMX still exists in the code t= oo --- while a subsidiary paper [4]=C2=A0 is there for those who want to se= e what the codebase implements as an L2 (a sequencer, validity proofs, shie= lded notes, anchored in bitcoin for finality - all of this implemented but = very rough around the edges!)

There's nothing stoppin= g anyone attaching Lichen to an entirely different L2 as long as you have s= tate to verify: a signing quorum may be simplest, maybe some kind of proof = of work or proof of stake consensus (with the work and stake being external= to bitcoin), maybe an ethereum smart contract for example? I chose the cle= anest thing I could think of: state updates proven valid, finality establis= hed with posting to bitcoin, and then the sequencer that bundles state upda= tes being the hub (after all you never know if it isn't!) so that a specifi= c kind of proof-counterproof is needed to succeed in exiting from the maxim= ally malicious hub; again, more detail on that in [4], but it's just an idi= osyncratic choice I made because I thought it was interesting!
Cheers,
AdamISZ/waxwing

[1]=C2=A0https://delvingbitcoin.org/t/variable-payout-amounts-for-babe-as-= applied-to-lichen/2963

[2] This is based on usin= g Glock's adaptors-based verifiable secret sharing to do a 10 of 78 cut and= choose instead of the 1000s in the base BABE design. Not my idea of course= , not only Glock, but the BABE paper itself, suggests it. And maybe a lot l= ess than 240MB with the recent Duty Free Bits research? I don't know, that'= s only speculation for now.

[3]=C2=A0https://git= hub.com/AdamISZ/lichen/blob/master/papers/lichen-v0.4.1.pdf

[4]=C2=A0https://github.com/AdamISZ/lichen/blob/master/papers/l= ichen-built-v0.1.1.pdf - this one is all AI written. It just exists to docu= ment how the "example L2" is built out, as a reference. The most interestin= g part is how you can guarantee exit even if the L2's operator - which here= , *is* the hub, is malicious. I think that still needs some careful examina= tion, not least around data availability, but it's already quite a strong m= odel.
On Monday, October 12, 2026 at 9:27:39=E2=80=AFPM UTC+9 waxwing/ AdamISZ = wrote:
H= i Dustin,

In short, yes, I think it *is* responsib= le! To advocate for my position: I think it is irresponsible to *not* promo= te versions of bitcoin payment systems that give users a crucial advantage = of freedom via privacy, in ways that are practical, as well perhaps more fu= nctionality, more payment speed, if such a system can be built. I know that= many others share this perspective.

> The CRS from = RiscZero is DL vulnerable

Well, Groth16 in general is de= pendent not only on ECDLP but on the stronger assumptions behind using pair= ings (something like q-DLOG and etc. , details, but: stronger in that the s= ystems is more exposed to a potential classical attack, but for quantum I g= uess it makes no difference). You're right, afaik, that using the trapd= oor/toxic waste would be a simple way to execute the attack, *if* it was br= oken. [1]

So I see two general points I want to ma= ke about this:=C2=A0

1/ the trivial point: Bitcoin= currently relies on ECDLP, so the question of whether some system 'att= ached' to it should be reliant on ECDLP only becomes relevant once Bitc= oin is no longer reliant on it. We're probably some way off from that. = A side system/L2 can use stronger assumptions reasonably and logically - th= e idea is that users are of course not forced to take any interest in that = system, they can simply not use it. The use of such a system can be shut do= wn voluntarily by groups of users, without a consensus upgrade on L1, so it= 's safer, also, in that specific sense.

2/ The= reason a whole bunch of 'do a surprisingly difficult thing in Bitcoin = itself so that we can connect it to another system trustlessly' proposa= ls/projects (think: BitVM(N,X), Glock, BABE, PIPEsv2 and others), as well a= s *many* other similar projects in cryptocurrency more generally, are using= either Groth16, or (in case of PIPEs) experimental WE constructs, or simil= ar, is because it's exceptionally difficult to get the properties you n= eed: full on compactness (in this case literally O(1) and concretely small)= in communication and exceptionally cheap verification for an unlimited siz= e of offchain computation. The cost is, no doubt, tremendous: a trusted set= up, pairings assumptions which are stronger than anything on bitcoin itself= , etc.

To avoid the specific DL style dependencies= , you might think, why not go STARK only; why don't we do that (why doe= sn't Risc0 do that?): it's pretty simple, STARKS are too big. A sin= gle STARK is not O(1) communication, but with recursion it kinda sorta is. = But we might be looking at 100kB-200kB of proof size. You can't feed in= a block that big into Script and have it be signed (imagine megabytes and = megabytes of data). I would not be in the least surprised if someone in fut= ure "figures that out", but, uh, I certainly haven't! Groth16= is always 3 curve points, like 100-200 *bytes* depending on your compressi= on serialization. That, we can winternitz-sign and shove into the witness.<= /div>

Perhaps new succinct verification systems will be = dreamt up; I certainly couldn't claim that something like lichen can &q= uot;just slot those in", if they are, but it might be true: because at= the end of the day the current design (with BitVMX) can arbitrate an *arbi= trary* computation with the number of rounds being logarithmic in the numbe= r of computation steps.

[1] Then there's the r= isk that's specific to the CRS for any Groth16 instantiation - the trus= ted setup, separate but also something to pay attention to for sure: I took= the time to look into the one behind RiscZero's instantiation, it'= s quite an interesting interaction between human identities and cryptograph= y! - anyway, sidetrack.

Cheers,
AdamISZ/waxwing=
On = Sunday, October 11, 2026 at 8:50:51=E2=80=AFPM UTC-3 Dustin Ray wrote:
<= /div>

Hi AdamISZ/waxwing
=
Overall this is an interesting proposal. On Groth16, is it responsible = to advocate for deploying additional PQ-vulnerable infrastructure to bitcoi= n right now? The CRS from RiscZero is DL vulnerable and if it falls to a Qu= antum 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 wax= wing/ AdamISZ wrote:
H= i list,

The one-sentence version: L2s funded via co-owne= d 2 of 2 contracts with a single 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=A0le...@anch= orage.com, and deleting the message and any attachment(s) from your sys= tem. Please refer to=C2=A0https://www.anchorage.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/eed59d04-8620-4b04-b97e-48d2432e74fbn%40googlegroups.com.
------=_Part_106030_1361569006.1793514244318-- ------=_Part_106029_191802302.1793514244318--