Hi Greg, Thank you very much for sharing your proposal!
I think there's one thing about the second part of your proposal that I'm missing. Specifically, assuming the scenario of a v3 transaction with three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction spends A and OP_TRUE, does that effectively mark output B as unspendable once the child gets confirmed? If so, isn't the implication therefore that to safely spend a transaction with an ephemeral anchor, all outputs must be spent? Thanks! Best, Arik On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote: > Hello Everyone, > > > Following up on the "V3 Transaction" discussion here > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html > , I would like to elaborate a bit further on some potential follow-on work > that would make pinning severely constrained in many setups]. > > > V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under some > constraints[0]. This means that when a replacement is to be made and > propagated, it costs the expected amount of fees to do so. This is a great > start. What's left in this subset of pinning is *package limit* pinning. In > other words, a fee-paying transaction cannot enter the mempool due to the > existing mempool package it is being added to already being too large in > count or vsize. > > > Zooming into the V3 simplified scenario for sake of discussion, though this > problem exists in general today: > > > V3 transactions restrict the package limit of a V3 package to one parent and > one child. If the parent transaction includes two outputs which can be > immediately spent by separate parties, this allows one party to disallow a > spend from the other. In Gloria's proposal for ln-penalty, this is worked > around by 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. > The honest participant can spend their version with their anchor and package > RBF the other commitment transaction safely. > > > What if there's only one version of the commitment transaction, such as in > other protocols like duplex payment channels, eltoo? What about multi party > payments? > > > In the package RBF proposal, if the parent transaction is identical to an > existing transaction in the mempool, the parent will be detected and removed > from the package proposal. You are then left with a single V3 child > transaction, which is then proposed for entry into the mempool. In the case > of another parent output already being spent, this is simply rejected, > regardless of feerate of the new child. > > > I have two proposed solutions, of which I strongly prefer the latter: > > > 1) Expand a carveout for "sibling eviction", where if the new child is paying > "enough" to bump spends from the same parent, it knocks its sibling out of > the mempool and takes the one child slot. This would solve it, but is a new > eviction paradigm that would need to be carefully worked through. > > > 2) Ephemeral Anchors (my real policy-only proposal) > > > Ephemeral Anchors is a term which means an output is watermarked as an output > that MUST be spent in a V3 package. We mark this anchor by being the bare > script `OP_TRUE` and of course make these outputs standard to relay and spend > with empty witness data. > > > Also as a simplifying assumption, we require the parent transaction with such > an output to be 0-fee. This makes mempool reasoning simpler in case the > child-spend is somehow evicted, guaranteeing the parent will be as well. > > > Implications: > > > a) If the ephemeral anchor MUST be spent, we can allow *any* value, even > dust, even 0, without worrying about bloating the utxo set. We relax this > policy for maximum smart contract flexibility and specification simplicity.. > > > b) Since this anchor MUST be spent, any spending of other outputs in the same > parent transaction MUST directly double-spend prior spends of the ephemeral > anchor. This causes the 1 block CSV timelock on outputs to be removed in > these situations. This greatly magnifies composability of smart contracts, as > now we can do things like safely splice directly into new channels, into > statechains, your custodial wallet account, your cold wallet, wherever, > without requiring other wallets to support arbitrary scripts. Also it hurts > that 1 CSV time locked scripts may not be miniscript compatible to begin > with... > > > c) *Anyone* can bump the transaction, without any transaction key material. > This is essentially achieving Jeremy's Transaction Sponsors > (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html) > proposal without consensus changes. As long as someone gets a fully signed > parent, they can execute a bump with minimal wallet tooling. If a transaction > author doesn’t want a “sponsor”, do not include the output. > > > d) Lightning > Carve-out(https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html) > is superseded by this logic, as we are not restricted to two immediately > spendable output scenarios. In its place, robust multi-party fee bumping is > possible. > > > e) This also benefits more traditional wallet scenarios, as change outputs > can no longer be pinned, and RBF/CPFP becomes robust. Payees in simple spends > cannot pin you. Batched payouts become a lot less painful. This was one of > the motivating use cases that created the term “pinning” in the first > place(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html), > even if LN/L2 discussion has largely overtaken it due to HTLC theft risks. > > > Open Question(s): > > > 1. If we allow non-zero value in ephemeral outputs, does this open up a MEV > we are worried about? Wallets should toss all the value directly to fees, and > add their own additional fees on top, otherwise miners have incentive to make > the smallest utxo burn transaction to claim those funds. They just confirmed > your parent transaction anyways, so do we care? > > 2. SIGHASH_GROUP like constructs would allow uncommitted ephemeral anchors > to be added at spend time, depending on spending requirements. SIGHASH_SINGLE > already allows this. > > > > > Hopefully this gives people something to consider as we move forward in > thinking about mempool design within the constraints we have today. > > > > Greg > > > 0: With V3 transactions where you have "veto power" over all the inputs in > that transaction. Therefore something like ANYONECANPAY is still broken. We > need a more complex solution, which I’m punting for the sake of progress. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
