The current minimum fee is still $0.03. Less with segwit.
There are technical solutions to the fee problems on channel cloasure during a fee bull market. Simply CPFP the closing TXN out of the mempool. Yes, this solution is technical, and yes most don't know how to do it, but it is a good solution that will work.
That works for a mutual close (actually, for a mutual close, both nodes negotiate what they both believe to be a reasonable fee, so no need to CPFP). However, for a unilateral close, the output is encumbered with an `OP_CSV` constraint, meaning it cannot be CPFP'ed trivially: you cannot attach a child until the transaction is confirmed for some number of blocks, but getting it confirmed *is* the issue. Anchor commitments adds "anchor outputs", one for each node, which are not `OP_CSV` encumbered and can thus be CPFP'ed, but increases the size of unilateral closes; this is the best solution so far known.
The article is about so much more, so we may be a little bit too fixated on only one issue.
Still (and I don't this well enough) this seems to present UI issues, because your channel capacity is reduced by onchain fee fluctuations, so don't we now have to also include any extra "capacity" provisioned by the (anticipated) CPFP or anchor transactions?
Indeed, we have to reserve some funds onchain for CPFPing anchors.
Onchain fees remain a massive headache in Lightning design, and are probably *the* biggest headache. I'd argue they are the root cause of all the headaches in Lightning.
* Every HTLC instantiated on the commitment transaction needs some blockspace allocation in case it ever has to be dropped onchain. That implies **onchain** fees. Lots of forwarding node operators wring their hands and weep every time a channel they opened is dropped onchain with a few HTLCs on it, it really hurts their forwarding business. If the current ***onchain*** feerates are high, the cost of having an HTLC on the commitment tx increases, limiting the number of HTLCs that a channel can transport at the same time. This remains true even post-anchor-commitments: HTLCs still take up blockspace and still cost *something* to instantiate onchain, so each channel will ***still*** have some limit on the number of HTLCs it can properly host, that changes dynamically depending on onchain feerates. Larger channels help avoid this, but larger channels means that if the peer you are large-channeled with goes offline that locks up more liquidity.
* Some of the pinning attacks involve lowballing the commitment tx fee during a low-onchain-fee period, then going offline when the onchain fees go high so the victim has to drop them with a low feerate and is then unable to get it confirmed. Then when the victim drops it onchain, you take advantage of the fact that your own output is unencumbered with an `OP_CSV` and attach a bunch of even-lower-feerate txes to pin it on the mempool, unable to confirm. Anchor commitments at least helps with this.
Jack Mallers proposed before an economic mechanism to help hedge against onchain fees changing, a derivatives market on onchain fee**rates**. This effectively allows a node to have an "insurance policy" to reduce its liability in case it has to do onchain fee changes (similar mechanisms exist already to provide insurance for farmers, they purchase put options on grain so if the cost of grain becomes lower than expected, they earn money from the put option to offset the reduction in income from the outright sale of grain). This tends to imply that channels have an ongoing cost to maintain, though, as if your channel is not closed, you have to continuously purchase more options that time out at later times when your channel *might* close.
Both `OP_CHECKSEQUENCEVERIFY` and `OP_CHECKLOCKTIMEVERIFY` for lightning are coded in blocks not epoch. This means TXNs with either of these OP codes are allowed into the mempool once the required blocktime is reached. It is simple to add a `blocknotify=<cmd>` line in your `bitcoin.conf` with the simple `cmd`
if blocknum_for_hash(%s) >= my_blocknum:
It's not "simple" but it's one config line and two lines of python. I'm certain any wallet developer could craft a PR for this to r/Electrum in an afternoon.
`OP_CHECKLOCKTIMEVERIFY` can be CPFP'ed, but *not* `OP_CHECKSEQUENCEVERIFY`, which is what encumbers outputs of a unilateral commitment transaction without any HTLCs. The block counter starts ticking when the commitment transaction is confirmed, as I mentioned, so this does not work for the general case where there are no HTLCs on a commitment transaction.
Since the point of CPFP is to get a parent transaction confirmed, and the `OP_CSV` counter starts ticking ***after*** confirmation, you can't use an output with `OP_CSV` to CPFP, so your proposal will simply not work, full stop.
Secondly, if you hold a preimage for the hash in an HTLC, you need to get tranactions confirmed **before** the `OP_CLTV` timeout, else the counterparty might get the timelocked branch confirmed and (if you are a forwarding node) you can be liable for a payout without getting a payin. This cannot be trivially CPFPed either since the current Lightning needs a two-stage transaction system for HTLCs, which is described in detail in BOLT#3 (though you might need to do more digging for the rationales).
So no, there is no current easy way to ***generally*** CPFP a unilateral close of a Lightning transaction.
Without high on-chain fees, using Lightning isn't really an attractive proposition, as there's just more complexity for very little benefit, just to save on a few dollars here and there.
There was a small window where Bitcoin could have blossomed as a tool for payments, but it got stifled, and the culture very much changed to focus more on investing. The average Bitcoiner now just buys coins on an exchange, and either keeps them on there, or moves them to their own wallet. That's generally the extent of their interaction with the blockchain. These types of users aren't really interested in spending their coins often, and the few times they do, doing it onchain is so much simpler, as they're spending from savings in a normal wallet and don't want to have to fund a separate balance on a hot LN wallet, open a channel, and then worry about liquidity issues. Spending BTC is also not ideal tax wise in a lot of jurisdictions.
I can't really see Lightning getting massive onboarding anytime soon, at least not in the next 5 years. Especially once native Segwit and Schnorr signatures take off and we get to squeeze out a bit more capacity onchain. Lightning is relying on an imagined tidal wave of incoming adoption in order to actually be relevant, but such a wave of consumers are likely going to see Bitcoin as an investment first and foremost, not as a payment tool, so they will have zero interest in using Lightning.
Some people in the Bitcoin community are deluded and want to have their cake and eat it too. Pushing Bitcoin as an investment, and encouraging to never sell, and HODL, and these wild theories about BTC going to $250k next year while at the same time hoping Lightning takes off as a highly popular payment tool for merchants online are two ideas fundamentally at odds with each other. It's possible to have BTC succeed both as an investment and a payment tool, but that requires a massive culture shift in the community and means promoting BTC more as a utility rather than as a stock ticker that's going to give you x10 returns.
> Especially once native Segwit and Schnorr signatures take off and we get to squeeze out a bit more capacity onchain.
Schnorr provides a constant factor saving. Going from 6 tx/s to 12 tx/s (just a made up 2x factor) isn't enough. If tx fees in times of congestion go from 50 USD to 25 USD, it is still too high.
The off-chain logic which is enforced on-chain is a fine concept. If it can be stable and reliable enough, it would provide much more of an efficiency improvement than Schnorr ever can.
> massive onboarding anytime soon
The author actually prefers onboarding be at a slow measured pace to allow the tech to mature! I think a large part of the article is indeed about the technical and social challenges of onboarding lots of people.
Are you pushing for adoption at all costs?
Do you ever fear promoting the wrong aspects of bitcoin, if we fail to understand this novel technology? Do you feel that there could be a possibility of bitcoin getting destroyed in that process?