This might be unpopular, but I feel like adding my perspective as a somewhat experience node runner.
Currently, fee rates are very high and it doesn't seem like they'll go down anytime soon. Unilateral (force) closes still happen, and paying 500k sats to close a channel with a capacity of 1M sats isn't uncommon (https://iris.to/note1vnxv4jyf3as6lnmze7uf7dcgpwsltapjg6jjm2rjeczpmld78lpqd4lagx).
Some node runners pay high fees for bilateral (coop) closes, and I don't think this is intentional in most cases. Example from my logs, where my node suggested 16k sats and my peer (who has to pay the fee!) suggested 54k sats instead:
CHCL: Ideal fee for closure of ChannelPoint(xxx:1) is: 16405 sat (max_fee=82025 sat) CHCL: ChannelPoint(xxx:1): shutdown response received, entering fee negotiation CHCL: ChannelPoint(xxx:1): computing fee compromise, ideal=16405, last_sent=0, remote_offer=54183 CHCL: ChannelPoint(xxx:1): proposing fee of 54183 sat to close chan CHCL: ChannelPoint(xxx:1) fee of 0.00054183 BTC accepted, ending negotiation
Having unreliable (offline) peers and peers that spam HTLCs increase the risk of unilateral closes, where every unresolved HTLC adds to the cost of the close transaction. Here's an example with five unresolved HTLCs, causing the close transaction to cost 254k sats: https://mempool.space/tx/7693a6eac81086c6bf3df78371aee74a2b1fa0eb587dfe6011f7cca53b2235ac
That being said, I'm confident that most node runners make use of this information and adjust things. Some might stop running a node, others might start using tools like https://github.com/lightningequipment/circuitbreaker, others might be more selective regarding their peers and channel sizes. In the end I hope that the routing experience on the lightning network is improved compared to the current state, and that setup guides and maintenance tools take high fee rates into consideration to warn/prepare future node runners.
My only disagreement comes from force closures due to issues in lightning implementations not agreeing on a “fair” fee rate. These are expensive bugs whose cost are suffered by the node runners. To near no fault of their own, a massive expense occurs only due to higher fees in the base layer and a difference in how that propagates to the lightning node compared to their peer. The fix, of course, is to improve the implementations and how they come to an agreed upon base chain fee (many smart people are working on this). This clouds whatever benefits having higher fees on the base layer may proved in giving a clearer market of opening and closing channels/node runners tuning their setup with settings.
reply
You mean coop closes?
reply
No, since these are not manual closes but ones that occur due to the nodes thinking the other is lying
reply
Ah, I see. I think that's not an issue with anchor channels anymore, right?
reply
I believe you’re correct, but I’d have to double check
reply
That seems likely. Improvement usually results from a response to a challenge.
It's got to be ugly bootstrapping a small node right now, but if it weren't ugly we wouldn't be motivated to develop coinpools, Ark, and the like.
reply
Both of those high fee examples were CPFP.
reply
reply
That's why they were extremely high
reply
Yes, but I still don't see the point of your comment.
reply
You're over exaggerating the fee.
If someone uses CPFP in a high fee environment its going to be huge.
reply
You know that CPFP is part of how anchor channels work, right?
reply
Mmm, no I didn't...
My bad
reply
I've been thinking a lot about this. It is too risky to open channels with a potential force close being so large. Here are some some tools I think we could build to make it less risky for us node runners. What do you think?
Implement dynamic fee adjustment algorithms in your node to respond to network fee fluctuations more efficiently. These algorithms automatically adjust the fees based on current network conditions, potentially reducing costs in periods of lower demand.
Integrate fee prediction services into your node's operation to provide more accurate estimates of future fee trends, aiding in better decision-making. These services analyze past and current fee data to forecast future trends, allowing you to make informed decisions about when to open or close channels.
Employ Multi-Path Payments (MPP) to reduce the need for large channels and potentially lower the costs associated with closing these channels. MPP allows a single payment to be split across multiple channels, facilitating efficient use of your channel capacity and reducing the frequency of channel closures.
Participate in payment channels that use anchor outputs, if available, to allow for more flexibility with fee structures and reduce closure costs. Anchor outputs offer a mechanism to adjust fees after transactions have been made, providing more control over closure costs.
Engage in channel lease strategies, where you rent out liquidity to others, to provide a revenue stream that might offset high closure fees. By leasing channel capacity to others, you earn fees that can help balance the costs incurred from your own channel operations.
Explore off-chain solutions or layer 3 protocols to provide alternative ways to transact without incurring high on-chain fees. These solutions allow transactions to be settled off the main blockchain, potentially reducing the need for costly on-chain transactions.
Build a network with other node operators for mutual support and sharing strategies to gain insights into effective practices for managing fees and channels. Networking with peers lets you learn from their experiences and share successful strategies, benefiting the optimization of your own node's operations.
reply
One option might be a positive incentive for LN mainnet txs that apply a further fee discount for well formed, distinguishable LN channel opens and closes. The incentive model has always been about lower fees for newer, more efficient tx formats, it can be encouraged to create more channels if the txs did not have to compete with non-protocol json spam.
Right now I am not opening or closing new channels, and am highly concerned about loss of funds for something out of my control. This high fee period has shocked me to the core re lighting security and fund safety, and I have lost 100ks of sats so far. I have my doubts about this particular L2 implementation if the macro L1 conditions make it highly unsafe for business.
reply
I agree
reply