[bitcoindev] Lichen: L2s In CHannels ENforced on bitcoin

[waxwing/ AdamISZ <ekaggata@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7613 bytes --]

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 ...

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

[-- Attachment #1.2: Type: text/html, Size: 7882 bytes --]