> does that effectively mark output B as unspendable once the child gets confirmed?
Not at all. It's a normal spend like before, since the parent has been confirmed. It's completely unrestricted, not being bound to any V3/ephemeral anchor restrictions on size, version, etc. On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
