pull down to refresh

I've been around the Lightning scene for a few years now, and consider myself to have a pretty good idea of how things are going, and how the current ordinal stuff is affecting lightning with high-price channels, costly force closes etc
I'm full-on Bitcoin-only (have been for many years), but I've always felt like it's worth being one foot behind and just observing how L2 protocols progressed. Admittedly, I got into Lightning pretty early from a technical standpoint as I wanted to understand the ins and outs - But I left Liquid on the side (for some reason felt it wasn't as accessible).
I'm looking for info on how Liquid is doing in contrast. What are its challenges, are there any benefits under the current climate etc With services like Boltz.hq, I would imagine Liquid would have a wider adoption by now given it intially set out to do what Lightning does.
Any must-see/follow resources or educated opinions are welcome.
given it intially set out to do what Lightning does.
Liquid can't make instant payments the way Lightning does. But given Liquid's extended covenant support, it can be a better platform for Lightning than Bitcoin itself. For example, John Law's timeout trees rely on capabilities that Liquid has but Bitcoin mainnet doesn't (yet?). Now the problem with this is of course that Liquid doesn't need help with scaling up (yet?).
It is possible that fedimints would eat Liquid's lunch, in fact, Liquid could be seen as a proto-mint. But fedimints are new and complicated and untested.
reply
This is really interesting, I need to dig a bit deeper to fully understand what you mean with
(Liquid) can be a better platform for Lightning than Bitcoin itself
I also need to look further into developments like timeout trees.
Why would you say Liquid doesn't need help with scaling? Like I mentioned in OP, I feel it's not as accessible and perhaps I just haven't looked further but it seems pretty tightened with Blockstream's hand, it doesn't seem as accessible as running an LN Node.
If that IS what you mean, that's fair, though I wouldn't call it scaled in anyway in that case. But like you said, it's not trustless, so maybe I'm just wanting to combine permissionless with scalability.
reply
Have a look at channel factories too: another idea that the mainnet lacks necessary opcodes to support properly.
I think Liquid is accessible enough with consumer-oriented wallets like Sideswap. What I meant by the need for scaling is what happens now on the mainnet: the throughput capacity is pushed, causing the fees to skyrocket. Liquid is still very far from being used at maximal capacity. Therefore people are not doing L2 solutions on top of Liquid (that would be already L3 I guess).
I'm just wanting to combine permissionless with scalability.
Yeah that would be great. I haven't figured out Ark yet, maybe that is what we want. However I'm happy enough to have instant payments done with trust because that's most of the time no more than 100-200 ksat anyway. For a transfer of 10M sats I'm happy enough to wait a minute or ten.
reply
Problem is we can't keep coming up with solutions that just end up centralising infrastructure for convenience.
Bitcoin with a 9 page whitepaper solved a world-class-problem by really taking some time to think about it and managed to remain accessible for the average user to self-host. No intermediaries.
Lightning has become an over-engineered centralised honeypot for bait and switches (look at WoS recently) that no average user wants to help grow, and Liquid as we know just seems so inaccessible infrastructure-wise and I see now it's even more centralised than LN.
reply
Problem is we can't keep coming up with solutions that just end up centralising infrastructure for convenience.
That's pretty much the only thing we can do, which is why we keep doing it.
Bitcoin with a 9 page whitepaper solved a world-class-problem
Yeah but the early discussion about Bitcoin banks with Nick Szabo shows that it was understood early on that the chain itself can't scale up to the whole planet.
Lightning has become an over-engineered
I consider it way under-engineered. Where are John Law's hierarchical channels? They don't need extra opcodes.
centralised honeypot for bait and switches (look at WoS recently)
WoS was holding your money in custody for convenience. That in itself has nothing to do with whether it uses Lightning or SWIFT or whatnot.
that no average user wants to help grow,
Bad, lazy users!! :)
and Liquid as we know just seems so inaccessible infrastructure-wise
It's very accessible unless you try to run a node, and you don't have to do that because only 15 nodes are actually important anyway.
and I see now it's even more centralised than LN.
Yes. It's just one mint after all.
reply
WoS was holding your money in custody for convenience. That in itself has nothing to do with whether it uses Lightning or SWIFT or whatnot.
I understand the point of services like WoS, my point was that they made themselves a target, an easy one at that.
It's very accessible unless you try to run a node, and you don't have to do that because only 15 nodes are actually important anyway. That's exactly my point. The moment self-custody and interaction with the timechain becomes conditioned by external entities, it is not longer accessible from a self-custody PoV.
reply
But there's literally nothing other than Lightning that satisfies your requirements, not just in Bitcoin but also in crypto. Succint ZK-proofs were paraded as a scalability solution but all rollups are centralized and even if you don't have to trust its sequencer it's still an easy target and it can censor users. So we have to make Lightning work because there's barely anything else.
reply
I agree there, and that's what I wanted to say regarding Liquid's 15/16 federated nodes led by corporate entities being the sole backend of the entire Liquid system.
I've been looking into Liquid further these past few days and I'm coming to the conclusion that while it may be necessary for those looking to do various finance-oriented activities (it has a working system for various financial instruments), it is imperative that Lightning (or something that supersedes it in every way) remains alive and well for day-to-day transacting, and that it becomes more necessary than Liquid.
Lightning's most current strength is the fact that it offers both custodial and self-custodial solutions, with increasing accessibility and ease.
But Liquid has designed itself to do things that Bitcoin just cannot on-chain because it wasn't designed to. My preference would still be something like Liquid but with more of a Lightning infrastructure where it's free-for-all to back and run.
But again, the custodial solutions are becoming more and more of an easy target, and in return let down newly onboarded users.
I think we need to shift and make a bigger push for self-custody, with things like Zeus Wallet's embedded LN mobile node.
31 sats \ 1 reply \ @OT 15 Dec 2023
Might have been a small uptick in liquid adoption. You can see 4 or 5 TX in a block these days.
Benefits I see are mainly the cheap fees. Swaps between liquid & LN (bolts/robosats) can be used for consolidating UTXO'S to peg out on chain, or to refill LN channels
reply
These have been my thoughts as well - It seems very circumstantial though.
reply
Lol I just used it today, and the blocks are empty as they always are, there's been some uplift in transactions but hardly any Bitcoin being added to the network, I think most people who have bothered to look at it know it isn't trustless and they're just using it as a temporary movement of funds until you go on-chain
I don't think many people know about it or have exposure to it, I don't see any wallets or exchanges planning on adding it, and maybe fees have to continue to rise and regulation on custodial lightning gets tighter, users who aren't ready to go non-custodial on LN might entertain it
reply
Thanks for the reply. I agree, and I was looking at it as a potential obfuscation method as I use Bisq to buy my BTC, so Bisq -> Liquid -> and then either BTC whirlpooled, or straight to Lightning depending on needs.
reply