Published on: 2022-10-19T13:22:08+00:00
In an email thread discussing efficient mempool design within the constraints of existing Lightning Network protocols, Greg Sanders proposed a policy change called Ephemeral Anchors. This policy involves watermarked outputs that must be spent in V3 packages, with the anchor being marked by the bare script `OP_TRUE`. The proposal has several implications, including allowing any value (even dust) to be included without bloating the UTXO set, and enabling anyone to bump the transaction without key material.Sanders pointed out that V3 transactions may solve rule #3 and #5 pinning attacks under some constraints, but they don't address package limit pinning. He suggested two solutions: expand a carveout for "sibling eviction" or implement Ephemeral Anchors. With sibling eviction, a new child that pays enough to bump spends from the same parent would knock its sibling out of the mempool and take the one child slot. However, this mechanism might lead participants to overbid far beyond the top mempool block fees.Ephemeral Anchors would allow for more robust multi-party fee bumping, superseding the Lightning Carve-out. Change outputs would no longer be pinned, and RBF/CPFP would become more robust. The proposal also magnifies composability of smart contracts by removing the 1 block CSV timelock on outputs in certain situations.However, there are still open questions about whether allowing non-zero value in ephemeral outputs would open up MEV concerns, and whether SIGHASH_GROUP-like constructs would enable uncommitted ephemeral anchors to be added at spend time.Gloria proposed a solution for ln-penalty, reducing the number of anchors per commitment transaction to 1 and each version of the commitment transaction has a unique party's key on it worked around the problem. Antoine Riard suggested that package relay should be included in addition to package RBF, otherwise if Lightning transactions are still relayed one by one, the version of the commitment transaction won't replace the counterparties's commitments sleeping in network mempools. If non-zero value is allowed in ephemeral outputs, it could modify the incentives games of the channels counterparties.The author of an email to the Bitcoin-dev mailing list has elaborated on potential follow-up work related to V3 transactions and pinning attacks. While V3 transactions may solve some pinning attacks, they do not solve package limit pinning, which occurs when a fee-paying transaction cannot enter the mempool due to the existing mempool package being too large.The proposed solution is Ephemeral Anchors, which marks an output as one that must be spent in a V3 package. If this anchor must be spent, then anyone can bump the transaction without any transaction key material. This proposal also benefits more traditional wallet scenarios as change outputs can no longer be pinned, and RBF/CPFP becomes robust. Open questions include whether allowing non-zero value in ephemeral outputs opens up a MEV and whether SIGHASH_GROUP-like constructs would allow uncommitted ephemeral anchors to be added at spend time, depending on spending requirements.
Updated on: 2023-08-02T08:07:07.237735+00:00