Version 3 transactions solve the issue with what is commonly dubbed BIP125 rule#3 pinning: A large, low fee-rate transaction enters the mempool, and becomes economically prohibitive to remove from the mempool via today’s RBF rules. By limiting the size of a child transaction in a parent-child relationship to 1 KvB, we can bound this economic damage to a small multiple which depends upon what an “honest” CPFP’ing child transaction would look like given a users’ wallet utxo makeup. In essence, it is a “RBF carveout” policy.
Ephemeral anchors are a special type of output that are watermarked (by policy only) via a short static output script. These, along with a few policy ground rules, enable a new, more general “CPFP Carveout” which can sidestep package limit pinning. It also allows relaxation of output script requirements, increasing smart contract composability.
Lighting Network BOLT03 for some “light” reading about how to avoid package limit pinning(poorly) with today’s mempool policies. See option_anchors scripts, with 1 OP_CHECKSEQUENCEVERIFY OP_DROP as the canonical widget to avoid pinning.
<LarryRuane> Hope you don't mind a very basic question, something I've wondered for a while... the BIP says "Ephemeral anchors of any satoshi value are standard for relay" -- is there ever a difference between standardness for *relay* versus *mempool accept*? Or are those always the same?
<instagibbs> LarryRuane great question! Sometimes things can be standard for mempool entry but not propagate for various racey reasons... hopefully not super important for EA
<LarryRuane> concept ACK, but (probably questionable to say this) mainly because I know many very smart people have worked on it! I believe we can all be influenced in that way
<DaveBeer> lost myself in study of package RBF, version 3 and ephemeral anchors, need deeper understanding of problem to review, here mostly to lurk & learn
<glozow> Anchor outputs suck: they're tiny little outputs that often don't get spent and hang out in utxo set, you need 1 for each party and CPFP carve out only works for 2 party.
<instagibbs> right, today there are two dusty outputs per commitment transaction, and lots of pinning vectors. If we adopt V3 transactions we can already do a lot better.
<glozow> I have a question. IIUC one motivation for OP_CSV 1 is we don't want any unconfirmed descendants to be added to these outputs, we only want unconfirmed children added to the anchor outputs. Are there other reasons to have the 1 block relative timelock?
<lightlike> If one parties CPFP's their anchor up to the mempool package size limit in order to pin the tx, the other party can use "one more" tx for their anchor, even though that exceeds the limit by 1.
<instagibbs> but in practice, that is really hairy, because mempools are not synced, so generally speaking you should be trying to bump your version only
<instagibbs> So for LN with EA, we would get rid of the dusty values in the single anchor, and relax all the scripts required for the spec. This makes splicing much more powerful
<lightlike> Is it a problem, that when the child is replaced by different parties CPFP'ing, each party needs to contribute the fees for the entire package (not just the delta) because the parent is always 0 fee?
<instagibbs> so for splicing, you want to be able to send funds to arbitrary destinations, even if counter-party doesn't know what the underlying script is
<instagibbs> but even if you wanted to doxx your script showing the 1 block CSV is in the script(handwave), things like LN funding outputs are incompatible!
<instagibbs> Another use-case I like to mention is that it allows a separation of "custodied" funds from fee funds. This is helpful in business settings or custodial settings
<glozow> because the only reason it's ephemeral is it's spent immediately by the child that it can't live without. Otherwise it's just "potentially dust anchors."
<glozow> In order for dust to enter the utxo set this way, a miner basically has to modify their node so they can mine a 0 fee tx on its own. seems not impossible, but pretty unlikely
<LarryRuane> more general question, there seem to be many policy (standardness) restrictions that are not consensus restrictions... is that mainly because if it's consensus, then we can't remove the restriction (should it be discovered to be necessary) without needed a hardfork?
<instagibbs> This question is mostly asking why that particular script and not something else? We already talked about wsh(OP_TRUE) being possible today, half answered at least
<michaelfolkson> Assuming policy changes are adopted gradually rather than instantly there would be a window where these transactions/package with an ephemeral anchor wouldn't be propagated until adoption had lift-off
<instagibbs> michaelfolkson correct, as with any policy relaxation, you'll need some large minority of the network plus some miners to update to accept it
<glozow> ok and whats the usage of -blockmintxfee? Just to exercise the logic that the parent needs to be bumped? So ephemeral delta takes care of minrelay, and then blockmintxfee stops it from getting mined before the child comes in?
<michaelfolkson> It would be nice to get all the required eltoo policy changes in with sufficient adoption before a APO soft fork was considered. With the lag in adoption n all