Author: Greg Sanders 2022-10-20 13:42:26
Published on: 2022-10-20T13:42:26+00:00
In a Bitcoin-dev discussion, Greg Sanders proposed Ephemeral Anchors as a solution to package limit pinning in V3 transactions. The current V3 transaction rules solve some forms of bip125 rule#3 and rule#5 pinning attacks, but package limit pinning is still an issue. With V3 transactions, the package limit of a V3 package is restricted to one parent and one child. If a parent transaction includes two outputs that can be immediately spent by separate parties, this allows one party to disallow a spend from the other. Sanders proposed two solutions, the second being Ephemeral Anchors. Ephemeral Anchors are outputs marked with `OP_TRUE` as outputs that must be spent in a V3 package. This ensures that any other output in the same parent transaction must directly double-spend prior spends of the ephemeral anchor. The proposal has several implications, including allowing any value to be spent on the ephemeral anchor and anyone being able to bump the transaction without any transaction key material. It also allows multi-party fee bumping, making it possible to safely splice directly into new channels, statechains, custodial wallet accounts, cold wallets, etc., without requiring other wallets to support arbitrary scripts. Change outputs can no longer be pinned, and RBF/CPFP becomes robust. Batched payouts become less painful. There are open questions about whether 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-06-16T02:00:40.120032+00:00