[bitcoindev] Re: Lichen: L2s In CHannels ENforced on bitcoin

["'Dustin Ray' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

[-- Attachment #1: Type: text/plain, Size: 8944 bytes --]


Hi AdamISZ/waxwing

Overall this is an interesting proposal. On Groth16, is it responsible to 
advocate for deploying additional PQ-vulnerable infrastructure 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 your proposal, 
funds are at risk.


On Sunday, October 11, 2026 at 8:36:31 AM UTC-7 waxwing/ AdamISZ wrote:

> Hi list,
>
> The one-sentence version: L2s funded via co-owned 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’s tokens on a layer 2 and 
> withdraw them as bitcoin without trusting the hub for honesty or liveness. 
> The L2 tokens are collateralised by the bitcoin in the user-hub multisig 
> output, and if the hub refuses a withdrawal, or cannot answer because 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’s consensus 
> is required. A withdrawal is a claim that a program, the withdrawal 
> 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 
> settled 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 — 
> with overwhelming likeliness because the statement is deterministically 
> verifiable in milliseconds — or, otherwise, a refused one is played as 
> BitVMX’s on-chain search, pre-signed once per contract. The trustlessness 
> gain is paid for with liquidity (with receiving ability only contingent on 
> offered “inbound” from the hub, as in Lightning). The hub (but not user) 
> must also stay live during normal operation, since an offline hub loses 
> disputes by timeout. The design is built and measured on regtest: a real 
> proof of the withdrawal statement is accepted by BitVMX’s unpatched Groth16 
> verifier in 478 million steps, implying about 22–25 transactions of 8-ary 
> search on chain in the dispute’s worst case.
>
> Here is my 'Q&A' approach which I hope will address the first things you'd 
> think of:
>
>
> *One central hub is dangerous!
>
> If the hub disappears, the user gets the money. The hub cannot Sybil 
> attack users by printing tokens fictitiously; the honest users' 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 from Bitcoin or is 
> finality weaker? Etc.)
>
>
> *Bridges usually mean you can only withdraw a fixed size utxo, meaning 
> operators and relying on swaps. Surely that applies here?
>
>  No. 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 
> 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 user; 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 other through the channels?
>
> A correct critique, partly, *if* the L2 ledger doesn't do anything but 
> plain payments. Even then, you would avoid receiver liveness being needed, 
> avoid routing and other minor things. But the real answer 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, 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 
> redeemable 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 user holding a balance on L2 far in excess of their inbound 
> liquidity in their 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 are. They are fungible, 
> *enforceable*claims on the hub's money; they are minted 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 hub 2 prints a billion 
> sats out of nothing and users accept it on the L2 they can redeem it with 
> hub1, leaving hub1 out of pocket. From this line of thinking we see an 
> interesting comparison with ecash servers: the hub can print as much as it 
> likes, but it cannot steal/``rug''.
>
> *So what's the catch?
>
>  The negatives are twofold: one is liquidity, and this is easy to 
> understand as the 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 from them. But the design does not assume that, of course, it 
> allows receiving up to a ``cap'': the user negotiates that extra potential 
> receiving 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 
> 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 enough 
> 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-concept demo (includes the entire L2 inclusion proof to STARK to 
> Groth16 verification of STARK; it's the groth16 verifier that goes into the 
> on-chain dispute).
>
> I think this design is genuinely interesting. Certainly more limited than 
> a completely generic L2 (not in functionality; in scale), but also more 
> practically achievable (in fact I don't think anything stops someone 
> 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 these things, with its 
> multiple onchain rounds? it's mainly because it can actually 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, maybe 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 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 experience soon ...
>

-- 
This message is intended only for the named recipient(s) above. It may 
contain legally privileged or confidential information. If you are not the 
intended recipient, you are hereby notified that any use, dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this message in error, please notify the 
sender by replying to this e-mail with a copy to legal@anchorage.com 
<mailto:legal@anchorage.com>, and deleting the message and any 
attachment(s) from your system. Please refer to 
https://www.anchorage.com/privacy-policy 
<https://www.anchorage.com/privacy-policy>

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3c10a867-fc2a-4b28-ab5b-75d8de050c3bn%40googlegroups.com.

[-- Attachment #2: Type: text/html, Size: 9691 bytes --]