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

From: "Johan Torås Halseth" <johanth@gmail•com>
To: Greg Sanders <gsanders87@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Jeremy Rubin <j@rubin•io>
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Date: Thu, 27 Oct 2022 11:37:01 +0200	[thread overview]
Message-ID: <CAD3i26DCm0DjpFwFfzBB=os+Z8ZA=JnK6tQQ_gqu8Ti5S7e8BQ@mail.gmail.com> (raw)
In-Reply-To: <CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>

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

Hi, Greg.

I find this proposal super interesting, and IIUC something that seems
fairly "safe" to allow (assuming V3).

For LN having the commitment transaction pay a non-zero fee is a cause for
a lot of complexity in the channel state machine. Something like this would
remove a lot of edge cases and add more flexibility around adding HTLCs.

Thanks!

- Johan

On Thu, Oct 20, 2022 at 3:42 PM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> 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
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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