hampus on Nostr: Is it Lightning's time to shine now when the onchain transaction fee is so high? Well ...
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?
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?