Replying to Avatar Hampus

Is it Lightning's time to shine now when the onchain transaction fee is so high?

Well yes, partly.

But please understand that Lightning ceases to work if the fees are too high!

To understand why, let’s go back to the saying that “Lightning is just Bitcoin transactions”.

Yes, this is true. Lightning in the end relies on normal Bitcoin transactions.

So by knowing this, you should have already realized why Lightning under a high onchain fee market is fragile, but let me explain:

The primary problem I’m referring to is the economical viability to sweep HTLCs.

An HTLC is the thing that gets added as an output to your lightning commitment transaction when you are doing Lightning payment.

It gets cleared out by making a new commitment transaction once the payment has goes through.

But the problem here is that if the onchain transaction fee is $100 and the cost of the sweeping an HTLC output is $100, then that means it’s not actually economically possible to redeem these funds.

Under normal circumstances you would never have to force-close and redeem this onchain, but it _can_ happen.

How LN circumvents this problem is by giving the payment amount to miners instead as a substitute for a real HTLC output. Giving the sats to miners means no more bytes are added to the commitment transaction, but it also means that if a force-close happens, these sats will just be given to miners instead.

This was already the case for all smaller payments (21 sats and so on) including virtually _all_ zaps here on nostr.

But for smaller micro-transactions it’s not a big deal if a payments gets lost, because no one would cry over 21 sats.

But if it’s about 210 000 sats, then we’re in a BIG problem if this isn’t secure and trustless.

We need to find a sweet spot for onchain transaction fees and we need more scaling solutions that work together with LN in order to fix this.

My favorite solution is a Lightning Network deployed over multiple Drivechains, fully interoperable, but I’m open for more suggestions. What do you think?

I prefer solving this problem with PTLCs, MuSig2, and CISA. I don't like introducing new blockchains if it can be avoided.

Reply to this note

Please Login to reply.

Discussion

Those things don’t take us that far.

But yes, I agree that we should do things like CISA, as that would make it possible to have more transactions within the current weight unit limit.

Really, it’s a shame that Taproot didn’t include CISA already.

Of course, but considering that CISA still isn't yet ready, I'd prefer to have had all the progress made towards Taproot support over the past two years instead of the perfect soft fork.

The same could be said of PTLCs, of course. Looking into PTLCs some more, it appears it completely solves the problem of HTLC sweeping because it prevents stuck payments. See:

https://suredbits.com/payment-points-part-2-stuckless-payments/

I expect to see development towards PTLCs grow more mature later this year and into next year. In addition to reducing potential fees for channel settlement, they improve receiver privacy, prevent wormhole attacks, and enable asynchronous payments, which are helpful for mobile and web apps.