Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

From: Greg Sanders <gsanders87@gmail•com>
To: Arik Sosman <linuxfoundation@arik•io>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Date: Tue, 18 Oct 2022 11:51:30 -0400	[thread overview]
Message-ID: <CAB3F3DvH3FnK8krykbcRVKc-z8F4yjt9mzYHevpYxaWkH4w9tw@mail.gmail.com> (raw)
In-Reply-To: <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 7655 bytes --]

> 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
>

[-- Attachment #2: Type: text/html, Size: 19107 bytes --]