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
