I really thought we had hit rock bottom in terms of Bitcoiners making irrational and ridiculous arguments against Bitcoin improvements, in order to paint themselves as some sort of righteous underdog fighting corruption and incompetence from within.
Boy, was I wrong.
So, a few things to explain first. With Lightning Channels, you need to decide the fee upfront for a one-sided close transaction. Since the effective UTXO is a multisig, both sides of the channel must pre-sign the transactions used by both to close the channel unilaterally. Lightning’s entire security is based on having these. If you ever needed to use one, for example because your counterparty is uncooperative, you can’t exactly count on them to resign to one at a higher rate if you needed it.
This led to problems when closing tariffs unilaterally. If the commissions were high and have decreased since you opened your channel, you will be paying money you didn’t need. If commissions were low and then increased, you can’t guarantee that your channel will close in a timely manner. You can’t replace with commission (RBF) because your counterparty has to sign and you can’t use Child-Pays-For-Parent (CPFP) because all your outputs are time-locked, so nothing you spend on them will be valid until After the first transaction actually confirms and more blocks pass.
For this reason, anchor outputs were created. They were special outputs that exist without time locks for the sole purpose of being able to spend on a secondary transaction to increase lightning close transaction fees. This however added further capital inefficiency, requiring the use of a non-negligible amount of satoshi to create these outputs.
Insert ephemeral anchors, relying on v3 transaction forwarding and packet forwarding (forwarding transactions into the mempool as groups). The idea is to have an output of value 0 spendable with OP_TRUE (which means anyone can spend it). Transactions that have a rate of 0 and include a temporary anchor will be forwarded to the mempool until there is a secondary transaction that spends the ephemeral anchor output with an appropriate fee.
This allows Lightning channels to sign one-sided closing transactions without fees, and anyone who needs to use them can simply spend the ephemeral anchor output to set the required fee at that time. This greatly simplifies zip transactions and eliminates the capital inefficiencies of existing anchor outputs. An additional advantage is that whoever can charge a transaction with an ephemeral anchor, not just with the channel (or other contract) owners.
The ephemeral anchor never even creates the 0 UTXO value in the UTXO set, because it will only be forwarded together with a transaction that instantly spends it in the same block.
So why is this a problem? Or an attack? I have no idea, it’s an amazing simplification that essentially any second-layer protocol, or Bitcoin-based contract in general, that uses pre-signed transactions will benefit greatly from. It doesn’t bloat the UTXO set because, as the name says, the outputs used are ephemeral. They are not actually created permanently.
The only arguments I’ve seen are “spam!” Or “The core developers are removing the dust limit!” (A restriction on minimum value transaction outputs must be conveyed, and they are not removing it for anything other than ephemeral anchors, which duty be immediately spent by a child to be fostered).
I think we’re at a point where we need to seriously consider when it’s time to push back against criticism or complaints regarding technical topics in this space. Or where legitimate criticism ceases to be legitimate and becomes irrational and illogical crusades against or for personalities instead of reasoned criticism. Because this reaction against ephemeral anchors is indisputably the latter.
All rational criticism should be welcome in an open source protocol like Bitcoin, but it’s time to stop pandering to irrational tribalism without logical basis as if it amounts to legitimate criticism. It is not, it is simply a waste of time and a denial of service attack against the Bitcoin enhancement process.
This article is a Take. The opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.