[bitcoindev] Lichen: L2s In CHannels ENforced on bitcoin

[bitcoindev] Lichen: L2s In CHannels ENforced on bitcoin

[waxwing/ AdamISZ]

[-- 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 --]

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

['Dustin Ray' via Bitcoin Development Mailing List]

[-- 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 --]

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

[waxwing/ AdamISZ]

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

Hi Dustin,

In short, yes, I think it *is* responsible! To advocate for my position: I 
think it is irresponsible to *not* promote versions of bitcoin payment 
systems that give users a crucial advantage 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 know that many others share this 
perspective.

> The CRS from RiscZero is DL vulnerable

Well, Groth16 in general is dependent not only on ECDLP but on the stronger 
assumptions behind using pairings (something like q-DLOG and etc. , 
details, but: stronger in 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 the trapdoor/toxic waste would be a simple way to 
execute the attack, *if* it was broken. [1]

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

1/ the trivial point: Bitcoin currently relies on ECDLP, so the question of 
whether some system '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 - the 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 down 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' 
proposals/projects (think: BitVM(N,X), Glock, BABE, PIPEsv2 and others), as 
well as *many* other similar projects in cryptocurrency more generally, are 
using either Groth16, or (in case of PIPEs) experimental WE constructs, or 
similar, is because it's exceptionally difficult to get the properties you 
need: full on compactness (in this case literally O(1) and concretely 
small) in communication and exceptionally cheap verification for an 
unlimited size of offchain computation. The cost is, no doubt, tremendous: 
a trusted setup, 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 doesn't Risc0 do that?): it's pretty 
simple, STARKS are too big. A single 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 future "figures that out", but, uh, I 
certainly haven't! Groth16 is always 3 curve points, like 100-200 *bytes* 
depending on your compression serialization. That, we can winternitz-sign 
and shove into the witness.

Perhaps new succinct verification systems will be dreamt up; I certainly 
couldn't claim that something like lichen can "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 *arbitrary* computation with the number of 
rounds being logarithmic in the number of computation steps.

[1] Then there's the risk that's specific to the CRS for any Groth16 
instantiation - the trusted 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 cryptography! - anyway, sidetrack.

Cheers,
AdamISZ/waxwing
On Sunday, October 11, 2026 at 8:50:51 PM 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 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 le...@anchorage.com, and 
> deleting the message and any attachment(s) from your system. Please refer 
> to 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/4463542b-5553-4b3c-8c7f-3ce7edb7bb1fn%40googlegroups.com.

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