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

From: Greg Sanders <gsanders87@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Date: Fri, 27 Jan 2023 09:05:20 -0500	[thread overview]
Message-ID: <CAB3F3DvToF_fia+X5SQi-L=BDYGLpzr8nNHqjtFBUjLMbyPE9Q@mail.gmail.com> (raw)
In-Reply-To: <CAB3F3DtrSFPmperGJJAUDZj7vt9aHgvkc0b5Pts3+mq5fTuWXA@mail.gmail.com>

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

Hello again dev,

Due to the interest in the proposal and the prodding of certain folks, I've
written up a short draft BIP of the Ephemeral Anchors idea here:
https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki

The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been
refreshed on top of the latest V3 proposal, but the BIP itself is
unaffected.

Cheers,
Greg

On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders <gsanders87@gmail•com> wrote:

> Small update.
>
> A bit ago I went ahead and implemented ephemeral anchors on top of the V3
> proposal to see what the complexity looks like:
> https://github.com/bitcoin/bitcoin/pull/26403
>
> Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
> the value that is used elsewhere.
>
> Please let me know if you have any early feedback on this!
>
> Greg
>
> On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders <gsanders87@gmail•com> wrote:
>
>> So it doesn't look like I'm ignoring a good question:
>>
>> No solid noninteractive ideas, unless we get some very flexible sighash
>> softfork. Interactively, I think you can get collaborative fee bumps under
>> the current consensus regime and ephemeral anchors. The child will just be
>> built with inputs from different people.
>>
>> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne <james.obeirne@gmail•com>
>> wrote:
>>
>>> I'm also very happy to see this proposal, since it gets us closer to
>>> having a mechanism that allows the contribution to feerate in an
>>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>>> and other contracting protocols.
>>>
>>> One possible advantage of the sponsors interface -- and I'm curious for
>>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>>> collaboratively bump a tx's feerate. A simple example would be a batch
>>> withdrawal from an exchange could be created with a low feerate, and then
>>> multiple users with a vested interest of expedited confirmation could all
>>> "chip in" to raise the feerate with multiple sponsor transactions.
>>>
>>> Having a single ephemeral output seems to create a situation where a
>>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>>> way we could (possibly later) amend the ephemeral anchor interface to allow
>>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>>> ephemeral anchors that would allow this?
>>>
>>>
>>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>>> Excellent proposal and I agree it does capture much of the spirit of
>>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>>
>>>> The only drawbacks I see is they don't work for lower tx version
>>>> contracts, so there's still something to be desired there, and that the
>>>> requirement to sweep the output must be incentive compatible for the miner,
>>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>>> The Ephemeral UTXO concept can be a consensus rule (see
>>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>>> a cleanup one can punt.
>>>>
>>>> One question I have is if V3 is designed for lightning, and this is
>>>> designed for lightning, is there any sense in requiring these outputs for
>>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>>> the v3 surface smaller.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>>> > 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
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>

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