I really thought that we had seen the bottom in terms of Bitcoiners making irrational and ridiculous arguments against improvements to Bitcoin, in order to paint themselves as some kind of righteous underdog fighting against corruption and incompetence from the inside. Boy was I wrong. So, some things to explain first. With Lightning channels, you have to decide your fee-rate for a unilateral close transaction ahead of time. Because the actual UTXO is a multisig, both parties to the channel have to sign the transactions either side uses to close the channel unilaterally ahead of time. The entire security of Lightning is based on having these. If you ever needed to use one, say because your counterparty is being non-cooperative, you can’t exactly count on them to resign one at a higher fee-rate if you needed it. This led to problems during unilateral fee closures. If fees were high and came down since you opened your channel, you pay money you didn’t need to. If fees were low and went up, you can’t guarantee that your channel closes in a timely manner. You can’t Replace-By-Fee(RBF) because your counterparty needs to sign, and you can’t use Child-Pays-For-Parent(CPFP) because all of your outputs are timelocked, so nothing spending them will be valid until after the first transaction actually confirms and multiple blocks pass. Because of this, anchor outputs were created. They were special outputs that exist without timelocks for the sole purpose of being able to spend in a child transaction to fee-bump the Lightning close transaction. These added more capital inefficiency though, requiring a non-negligible amount of satoshis be used to create these outputs. Enter ephemeral anchors, building on the v3 transaction relay and package relay (relaying transactions in the mempool as groups). The idea is to have a 0 value output spendable with OP_TRUE(meaning anyone can spend it). Transactions that have a fee-rate of 0, and include an ephemeral anchor, will be relayed in the mempool as long as there is a child transaction spending the ephemeral anchor output with an appropriate fee-rate. This allows Lightning channels to sign unilateral closure transactions with no fees, and anyone who needs to use them can simply spend the ephemeral anchor output to set whatever fee-rate is required at the time. This greatly simplifies Lightning closure transactions, and removes capital inefficiencies of existing anchor outputs. An added bonus is that anyone can fee bump a transaction with an ephemeral anchor, not just the channel (or other contract) owners. The ephemeral anchor never even creates the 0 value UTXO in the UTXO set, because it will only be relayed along with a transaction that instantly spends it in the same block. So why is this a problem? Or an attack? I have no clue, it’s an amazing simplification that essentially any second layer protocol, or contract built on Bitcoin in general, that uses pre-signed transactions will benefit greatly from. It causes no bloat of the UTXO set, because as is in the name, the outputs used are ephemeral. They aren’t actually permanently created. The only arguments I’ve seen are “spam!” Or “Core developers are removing the dust limit!” (A restriction on the minimum value transaction outputs must have to be relayed, and they aren’t removing it for anything but ephemeral anchors, which must be immediately spent by a child to be relayed). I think we are at a point where we have to seriously consider when it is time to dismiss criticism or complaints surrounding technical subject matter in this space. Or where legitimate criticisms stop being that, and become irrational and illogical crusades against or for personalities instead of reasoned criticism. Because this backlash against ephemeral anchors is incontrovertibly the latter. All rational criticism should be welcomed in an open source protocol like Bitcoin, but it's time to stop humoring irrational tribalism with no logical basis as if it is equivalent to legitimate criticism. It’s not, it’s purely a waste of time and a Denial of Service attack against the process of improving Bitcoin. This article is a Take . Opinions expressed are entirely the author's and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
