From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 12 Oct 2026 05:27:46 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.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 1xGF85-0000Q5-2O for bitcoindev@gnusha.org; Mon, 12 Oct 2026 05:27:46 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-82328040dcdsf145292a34.3 for ; Mon, 12 Oct 2026 05:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1791808059; x=1792412859; 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=nJ3f5wlS2C0dolEChnDwClj0rS8VeDVjRaXvSDjF0XA=; b=jkPs1u037TLUzRHwUhSlBiWibUPA+U25fPByKFmPH88Xt6aoHz6Yf2OXrd0FhETrHs jqRJB6uquuOg5UMv70CtDDhA+HK0ZCOymf/NtqltniJMFBJhbQXdro/zUuufS4lKfrak ttVzSYlpluwHHD5tNb90q4e05mtQffDlYsS9x91Ixe8CcjshVBx/Ih4mPxmNUOtggKIu OYdcrM+cOFxk/XOoH80Z24snJw4qRLvVlY38kMucc9CEDBaLJl1xLpgv9OuGboZm1mQC I5Xk6Vje2ew6T1SXg1Kpne9wkYJv/YrX75VYDRv5y1V6mKUSYhPFol9bH6CJk040ERMU Uxsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791808059; x=1792412859; 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=nJ3f5wlS2C0dolEChnDwClj0rS8VeDVjRaXvSDjF0XA=; b=ZEazN71bHiciXFVZhKorBA1VcmQE4n7w/MhFLip1MFjBq3JK5wg3X9A1PWiGXctXu/ wyOpx4Ho1gXVXkN4E/oNpEbNkfGmeRLF3RlF9Blb283lp4SQZSMX3k/ra+6y0JqZMmls mmsg4owr6rozjZgSvE24hueiMD7RNbu+irQuHxsVR4mR5IZXgWvNySMEjUWLfGqd8tOn SohgssjSP9akIlsHnem1jsrmjpHuHFbWeB7vkGgYcT4lidEYJcl98SF9ltFRr5o69JXW LSmYC27e3omD7+jEh36GdkpEoN5Ga4IP3tCMRcm6hytFYxHxnc7Ih++mfwO8IuInrGO+ QMBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791808059; x=1792412859; 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=nJ3f5wlS2C0dolEChnDwClj0rS8VeDVjRaXvSDjF0XA=; b=AM0U1Wj45KrjZlFC9QCgXQfUnqDELruXordqMn5HDEUAt1A0iMM/iaSWv/dHECFflm 7JCRI36IuJGyzzJSQCa9Oh2Htg2O/qOKlgjpuxg9VCDUejf7XxYLPV2Mt09mXzjNtGnu /Biua3Ih0lIBEKQvbVPEntoPp6TfWfnZC0JGWObHFnz3dYhMlSPSeo3puVE7r+SBrU9+ a8YtqpzYUy0bByknv2E1uut8qi/SB3Hl5XDFe1v2wDMXX6arsyUO30PDBO+VsWoWA0c/ TgzaL+piX3Se/vvMUQEtkuVAa0XvEod1rGhCKJHnKTh8yah4pw+3YNF6iod27S24jfLS Nwwg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvByjUbXszX7gNmjM3fuH7dhNtoCT6U4Zj8+DGxFFZFesoE0iQwNbOc9LyDvaCJjiFYYEZNLnE5kowXJ4@gnusha.org X-Gm-Message-State: AFq9FYKEq33elMBWwrpDpkOJkOEWqgp+XGGLiEnn92CnsdEu/Zy4sgY3 cBYu/Vl677/lVoxJM4vQPUjM9En4KtDmuQqqTWP6PSLHT6ti8NSFk6y6 X-Received: by 2002:a05:6820:4a8d:b0:6d5:65a:de01 with SMTP id 006d021491bc7-6ef0d822e95mr8353183eaf.2.1791808058946; Mon, 12 Oct 2026 05:27:38 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdeK+NuJOPne49ts3MiMkp3PE3bLjKzW/14PiWUB7mKNIw==" Received: by 2002:a05:6820:a515:20b0:6d5:d630:801c with SMTP id 006d021491bc7-6eef4bceb68ls2981865eaf.1.-pod-prod-03-us; Mon, 12 Oct 2026 05:27:31 -0700 (PDT) X-Received: by 2002:a05:6808:e88:b0:490:315d:e0d5 with SMTP id 5614622812f47-50c4dfbae9amr7629163b6e.16.1791808051714; Mon, 12 Oct 2026 05:27:31 -0700 (PDT) Received: by 2002:a05:690c:6306:b0:81e:11b4:1172 with SMTP id 00721157ae682-8b07c7752f9ms7b3; Mon, 12 Oct 2026 05:18:29 -0700 (PDT) X-Received: by 2002:a05:690c:dc6:b0:8a7:4207:64dc with SMTP id 00721157ae682-8b07ee1eb2cmr24647617b3.63.1791807508386; Mon, 12 Oct 2026 05:18:28 -0700 (PDT) Date: Mon, 12 Oct 2026 05:18:28 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn@googlegroups.com> In-Reply-To: <3c10a867-fc2a-4b28-ab5b-75d8de050c3bn@googlegroups.com> References: <9dd171c9-e4fa-4b4d-b0d6-33bc46e48b30n@googlegroups.com> <3c10a867-fc2a-4b28-ab5b-75d8de050c3bn@googlegroups.com> Subject: [bitcoindev] Re: Lichen: L2s In CHannels ENforced on bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_143882_1216908097.1791807508055" 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_143882_1216908097.1791807508055 Content-Type: multipart/alternative; boundary="----=_Part_143883_1355140482.1791807508055" ------=_Part_143883_1355140482.1791807508055 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ways= =20 that are practical, as well perhaps more functionality, more payment speed,= =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 stronger= =20 assumptions behind using pairings (something like q-DLOG and etc. ,=20 details, but: stronger in that the systems is more exposed to a potential= =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 to= =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 of= =20 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 forced= =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, are= =20 using either Groth16, or (in case of PIPEs) experimental WE constructs, or= =20 similar, is because it's exceptionally difficult to get the properties you= =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 pretty= =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 they= =20 are, but it might be true: because at the end of the day the current design= =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 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 = wrote: > >> 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 t= he=20 >> abstract of the paper [1], followed by a sort of Q&A; I think that's bes= t=20 >> 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=20 >> withdraw them as bitcoin without trusting the hub for honesty or livenes= s.=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 th= e=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 technical= =20 >> core of the design. Withdrawals are executed cooperatively in the channe= l =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 pla= yed as=20 >> BitVMX=E2=80=99s on-chain search, pre-signed once per contract. The trus= tlessness=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 hu= b (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 unpatc= hed 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=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 is= =20 >> all backed. The only remaining risks are inherent to the L2 itself (is i= t 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 neede= d,=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, allowin= g=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 itsel= f,=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 bill= ion=20 >> sats out of nothing and users accept it on the L2 they can redeem it wit= h=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 Lightnin= g,=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 wi= ll=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 potenti= al=20 >> receiving amount (inbound liquidity) when it sets up the contract with t= he=20 >> hub. The second negative is very concrete, and is a design decision rath= er=20 >> than an absolute requirement: we use BitVMX's bisection (in fact 8-ary n= ot=20 >> binary) to enforce that the ZKP is valid, on-chain. In the worst case th= is=20 >> is 20-25 transactions and may require watchtower design to be easy enoug= h=20 >> for users to fully rely on. In a correctly built implementation this is= =20 >> exceptionally rare because the incorrect party (trivially established) i= s=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 t= o=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 tha= n=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 a= t=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, BAB= E,=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 mo= re=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 th= e=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 le...@anchorage.com, and= =20 > deleting the message and any attachment(s) from your system. Please refer= =20 > 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/= 4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn%40googlegroups.com. ------=_Part_143883_1355140482.1791807508055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dustin,

In short, yes, I think it *is* r= esponsible! To advocate for my position: I think it is irresponsible to *no= t* promote versions of bitcoin payment systems that give users a crucial ad= vantage of freedom via privacy, in ways that are practical, as well perhaps= more functionality, more payment speed, if such a system can be built. I k= now that many others share this perspective.

> The= CRS from RiscZero is DL vulnerable

Well, Groth16 in g= eneral is dependent not only on ECDLP but on the stronger assumptions behin= d using pairings (something like q-DLOG and etc. , details, but: stronger i= n that the systems is more exposed to a potential classical attack, but for= quantum I guess it makes no difference). You're right, afaik, that using t= he trapdoor/toxic waste would be a simple way to execute the attack, *if* i= t was broken. [1]

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

1/ the trivial po= int: Bitcoin currently relies on ECDLP, so the question of whether some sys= tem 'attached' to it should be reliant on ECDLP only becomes relevant once = Bitcoin 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 r= eason a whole bunch of 'do a surprisingly difficult thing in Bitcoin itself= so that we can connect it to another system trustlessly' proposals/project= s (think: BitVM(N,X), Glock, BABE, PIPEsv2 and others), as well as *many* o= ther similar projects in cryptocurrency more generally, are using either Gr= oth16, or (in case of PIPEs) experimental WE constructs, or similar, is bec= ause it's exceptionally difficult to get the properties you need: full on c= ompactness (in this case literally O(1) and concretely small) in communicat= ion and exceptionally cheap verification for an unlimited size of offchain = computation. The cost is, no doubt, tremendous: a trusted setup, pairings a= ssumptions 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 doesn't Risc0 do th= at?): it's pretty simple, STARKS are too big. A single STARK is not O(1) co= mmunication, 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 Scrip= t and have it be signed (imagine megabytes and megabytes of data). I would = not be in the least surprised if someone in future "figures that out", but,= uh, I certainly haven't! Groth16 is always 3 curve points, like 100-200 *b= ytes* depending on your compression serialization. That, we can winternitz-= sign and shove into the witness.

Perhaps new suc= cinct verification systems will be dreamt up; I certainly couldn't claim th= at something like lichen can "just slot those in", if they are, but it migh= t be true: because at the end of the day the current design (with BitVMX) c= an arbitrate an *arbitrary* computation with the number of rounds being log= arithmic in the number of computation steps.

[1]= Then there's the risk that's specific to the CRS for any Groth16 instantia= tion - the trusted setup, separate but also something to pay attention to f= or sure: I took the time to look into the one behind RiscZero's instantiati= on, it's quite an interesting interaction between human identities and cryp= tography! - anyway, sidetrack.

Cheers,
Adam= ISZ/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 to advocate for deploying additional PQ-vulnerable infr= astructure to bitcoin right now? The CRS from RiscZero is DL vulnerable and= if it falls to a Quantum machine, statements are easily forged and under y= our proposal, 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: L= 2s funded via co-owned 2 of 2 contracts with a single hub entity, without t= rusting 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...@anchorage.com, and deleting the message and any att= achment(s) from your system. Please refer to=C2=A0https://www.anchorage.com/pri= vacy-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/4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn%40googlegroups.com.
------=_Part_143883_1355140482.1791807508055-- ------=_Part_143882_1216908097.1791807508055--