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?
Published at
2023-05-06 17:25:59Event JSON
{
"id": "361440eb3b55e57acef69fe0ccb9eebd0e2a5065e4f6ecd27f2263f616b32b11",
"pubkey": "65594f279a789982b55c02a38c92a99b986f891d2814c5f553d1bbfe3e23853d",
"created_at": 1683393959,
"kind": 1,
"tags": [],
"content": "Is it Lightning's time to shine now when the onchain transaction fee is so high?\n\nWell yes, partly.\nBut please understand that Lightning ceases to work if the fees are too high!\n\nTo understand why, let’s go back to the saying that “Lightning is just Bitcoin transactions”.\nYes, this is true. Lightning in the end relies on normal Bitcoin transactions.\nSo by knowing this, you should have already realized why Lightning under a high onchain fee market is fragile, but let me explain:\n\nThe primary problem I’m referring to is the economical viability to sweep HTLCs.\nAn HTLC is the thing that gets added as an output to your lightning commitment transaction when you are doing Lightning payment.\nIt gets cleared out by making a new commitment transaction once the payment has goes through.\n\nBut 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.\nUnder normal circumstances you would never have to force-close and redeem this onchain, but it _can_ happen.\n\nHow 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.\n\nThis was already the case for all smaller payments (21 sats and so on) including virtually _all_ zaps here on nostr.\nBut for smaller micro-transactions it’s not a big deal if a payments gets lost, because no one would cry over 21 sats.\nBut if it’s about 210 000 sats, then we’re in a BIG problem if this isn’t secure and trustless.\n\nWe 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.\nMy favorite solution is a Lightning Network deployed over multiple Drivechains, fully interoperable, but I’m open for more suggestions. What do you think? ",
"sig": "2584687e5bc3b1c75230882febe8428ce098758ceaefd81c34e84fd557cacb1a27c0eee8a5acfac6d1e9596287c09c761b8aa079b3abec0bfda67b12b7f87450"
}