pull down to refresh

=LN, all the others will fail at their bridge for rug risk

Not clear what you're claiming there. If you take my recent Lichen, which is just a way to do stuff like bitvm-ish stuff today, you have cryptographic enforcement of whatever the L2 risk is on L1. As per my paper (see v0.5 of my paper from the repo https://github.com/AdamISZ/lichen) the fundamental mass exit risk is exactly the same as the mass exit risk on Lightning, with the difference that the risk is more acute because the L1 transaction space usage is higher. So it takes a smaller number of simultaneous Lichen exits to overwhelm L1's capacity than LN. But that is a quantitative difference, not a qualitative one. Both elevate censorship resistance to a security-of-funds requirement.

On the other hand, things like ecash and a federated sidechain both have risks of a different quality (and also statechain) which is that you're trusting some or other privileged entities not to behave badly. This is simply not true in Glock, BABE, Lichen, BitVM3 and others (I could also say PIPEsv2 but it is too far from practical today): the exit is enforced by cryptography, not trust.

I was mostly pointing to the potentially viable (due to tx size, maybe) sidechain / sequencers that are taking a bridge in (rather than an L1 deposit.) All these are trustmebro on the intake over LN first, and in the case of ecash/fedi, they're also trustmebro on the non-existing (or did this change recently?) unilateral exit.

The way I see BitVM(-ish) solutions today is that these are not products yet. Maybe I missed something new that is important tho - so please do correct me if I am wrong.

Do you use Lichen for production? This morning I bought 3 zucchini, 5kg of potato and half a dozen of Kakifruit using LN. I only ate some of the potato thus far, they were yum tho. Should I use Lichen instead?

reply
104 sats \ 0 replies \ @AdamISZ 5h
Should I use Lichen instead?

I literally invented [1] it a month ago. Give me a chance! lol

I've been testing it on testnet instances with a couple people but it's way too early to firm it up into a solid thing.

[1] caveat: "invented" claims too much: it's actually about practicality, the core tech was already invented, except for a couple of tweak ideas I added, so exactly to your point, as a modification to all these high-falutin' technical ideas like BABE and Glock which I personally perceive as not (yet) being structured so people could use them in everyday life scenarios.

So if you look at it from that point of view, I hope you can see why I find it unfair for you to accuse it of being impractical as an idea! I mean you'd have to actually read the paper and get into it, to develop an opinion, and I 100% understand not doing that as it's too much of a time commitment to a new thing, but yeah.

But you already ceded the important point: the issue with BitVM-ish approaches is just that they're not practical, yet, and who knows when they will be: we agree on that. The core idea of having it be trustless via cryptography, while difficult, is not non-existent.

reply