Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6FC4C002D for ; Fri, 27 Jan 2023 14:05:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id AC5EA41D5A for ; Fri, 27 Jan 2023 14:05:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AC5EA41D5A Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=SvRw7OK5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1U4qw_5LWEY for ; Fri, 27 Jan 2023 14:05:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AAA9E41D2D Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by smtp4.osuosl.org (Postfix) with ESMTPS id AAA9E41D2D for ; Fri, 27 Jan 2023 14:05:34 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id me3so13983978ejb.7 for ; Fri, 27 Jan 2023 06:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=yKx9CeQtCv0e5An9NbD/k6yqhk4/vh+lvlG36sUkjFg=; b=SvRw7OK5fKSrW3GEfYs6ytnypqHZ5lfFHlbMpXBDiH3UeqJ5CxMi4Lu2NYstkw9wpq kMkFcp70qaOhSpnaEpveF3W1lggen8VFaW+qllHvQqPRgK+LTD/OUIS6xuHDbTxSHUHA Iy21tpA1Acr67Aopm/H7zuNHtDyuxTmxFW8Nd5Ad/Lpx+F6oBfZFvbHflCxv6tDVqZiL tYAZ1ig0ji4vl849HmU4zBF74xaRc4r+XhssPHc+UHyi2jDR1FaVd1l7ZfpIbjDZs9zD mGw2ds7wsPRqdj3/qBF5HgKTZbzfzRIHcKUfLyZUd9SGhixco8qiQ2jIlrZPPrarLba1 JUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yKx9CeQtCv0e5An9NbD/k6yqhk4/vh+lvlG36sUkjFg=; b=2tkCMCh2RaH+lsatVhetObRktn1viEWhedV0m8Kx/Ng82FQUuUnr+tpkwnYH32eodD GWIvf6G6mL74I0U0FGv6n86VOEL/PBkPS08yxQeowq6H9+3uRJhFkRFgt0PgCe07XJ5L vUbDsP6R7PKBurs42T0NXGQeJY9XYWjo0x84wQ7LhhU8gv4G50w9+S3QJ7YlT89KK/xt 9fSPYSopGgatygLphKqmpucd65huv+kojH4mvg0l6hQ5ySY4uggKn7sUFIbpS1bDkKQE xoqDqOcjTuxxSV2NJi91pRYODxcYvrGIV5ss3p5OA5jktdwYxQ/lWTmGf4vYvWPQVpff xHCg== X-Gm-Message-State: AO0yUKWMWcawcuxr8hCiOmtygeYrbKRIcmzLYXf75xFXN85oc7ge3o48 DpH9o8Dk6xpCVV3yCjoYsSqJZJF7yGS3Ot8sGFIRNPYhn+M= X-Google-Smtp-Source: AK7set+38nyEz+ztXbMMbvFYO26uk7C7IJE9gZRz2RtRAe0MYAKZ2JBnmawQiZOAt1pcle1aUa8OJ4JF8lEJKOQT0EE= X-Received: by 2002:a17:906:c449:b0:878:4ee0:7ded with SMTP id ck9-20020a170906c44900b008784ee07dedmr1820267ejb.9.1674828332107; Fri, 27 Jan 2023 06:05:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Fri, 27 Jan 2023 09:05:20 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000cb8ff605f33f5b5e" Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2023 14:05:38 -0000 --000000000000cb8ff605f33f5b5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-ephemeralancho= rs.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 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 cam= p > 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 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 und= er >> 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 >> 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 vau= lts >>> 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 th= en >>> multiple users with a vested interest of expedited confirmation could a= ll >>> "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 s= ome >>> way we could (possibly later) amend the ephemeral anchor interface to a= llow >>> 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 th= e >>>> requirement to sweep the output must be incentive compatible for the m= iner, >>>> or else they won't enforce it (pass the buck onto the future bitcoiner= s). >>>> 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 ke= ep >>>> 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 bee= n >>>>> 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 tha= t >>>>>> 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 implicat= ion >>>>>> therefore that to safely spend a transaction with an ephemeral ancho= r, 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-Septemb= er/020937.html >>>>>> , I would like to elaborate a bit further on some potential follow-o= n 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 m= empool >>>>>> due to the existing mempool package it is being added to already bei= ng 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 ver= sion >>>>>> with their anchor and package RBF the other commitment transaction s= afely. >>>>>> >>>>>> What if there's only one version of the commitment transaction, such >>>>>> as in other protocols like duplex payment channels, eltoo? What abou= t 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 detect= ed and >>>>>> removed from the package proposal. You are then left with a single V= 3 child >>>>>> transaction, which is then proposed for entry into the mempool. In t= he case >>>>>> of another parent output already being spent, this is simply rejecte= d, >>>>>> 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 it= s >>>>>> 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 w= orked >>>>>> 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 simple= r in >>>>>> case the child-spend is somehow evicted, guaranteeing the parent wil= l 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 arbitra= ry >>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be min= iscript >>>>>> compatible to begin with... >>>>>> >>>>>> c) *Anyone* can bump the transaction, without any transaction key >>>>>> material. This is essentially achieving Jeremy's Transaction Sponsor= s ( >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Septemb= er/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=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D,= do not include the output. >>>>>> >>>>>> d) Lightning Carve-out( >>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Octob= er/002240.html) >>>>>> is superseded by this logic, as we are not restricted to two immedia= tely >>>>>> spendable output scenarios. In its place, robust multi-party fee bum= ping 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 pain= ful. >>>>>> This was one of the motivating use cases that created the term =E2= =80=9Cpinning=E2=80=9D in >>>>>> the first place( >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Februar= y/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 mine= rs have >>>>>> incentive to make the smallest utxo burn transaction to claim tho= se funds. >>>>>> They just confirmed your parent transaction anyways, so do we car= e? >>>>>> 2. >>>>>> >>>>>> SIGHASH_GROUP like constructs would allow uncommitted ephemeral >>>>>> anchors to be added at spend time, depending on spending requirem= ents. >>>>>> 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 toda= y. >>>>>> >>>>>> >>>>>> 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=E2=80=99m punting f= or 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 >>>> >>> --000000000000cb8ff605f33f5b5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello again dev,

Due to the inter= est in the proposal and the prodding of certain folks, I've written up = a short draft BIP of the Ephemeral Anchors idea here:=C2=A0https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephem= eralanchors.mediawiki

The pull request at=C2=A0https://github.com/bit= coin/bitcoin/pull/26403 has been refreshed on top of the latest V3 prop= osal, 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 ep= hemeral anchors on top of the V3 proposal to see what the complexity looks = like:=C2=A0https://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!

G= reg

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 si= ghash softfork. Interactively, I think you can get collaborative fee bumps = under the current consensus regime and ephemeral=C2=A0anchors. The child wi= ll just be built with inputs from different people.

On Wed, Oct 19, 20= 22 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 "unauthentic= ated" way, which seems to be a very helpful feature for vaults and oth= er contracting protocols.

One possible advantage o= f the sponsors interface -- and I'm curious for your input here Greg --= is that with sponsors, assuming we relaxed the "one sponsor per spons= oree" constraint, multiple uncoordinated parties can collaboratively b= ump a tx's feerate. A simple example would be a batch withdrawal from a= n exchange could be created with a low feerate, and then multiple users wit= h 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 w= here a single UTXO has to shoulder the burden of CPFPing a package. Is ther= e some way we could (possibly later) amend the ephemeral anchor interface t= o allow for this kind of collaborative sponsoring? Could you maybe see &quo= t;chained" ephemeral anchors that would allow this?

=

On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
Excellent proposal and I agree it does capture much of the spir= it of sponsors w.r.t. how they might be used for V3 protocols.

The only drawbacks I see=C2=A0is they don't work for lower tx version= contracts, so there's still something to be desired there, and that th= e requirement to sweep the output must be incentive compatible for the mine= r, or else they won't enforce it (pass the buck onto the future bitcoin= ers). The Ephemeral UTXO concept can be a consensus rule (see=C2=A0https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediat= e UTXO") we add later on in lieu of managing them by incentive, so may= be it's a cleanup one can punt.

One question I have is if V= 3 is designed for lightning, and this is designed for lightning, is there a= ny sense in requiring these outputs for v3? That might help with e.g. anony= mity 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 confirm= ed. It's completely unrestricted, not being bound to any V3/ephemeral a= nchor restrictions on size, version, etc.

On Tue, Oct 18, 2022 at 11:4= 7 AM Arik Sosman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:
<= div>
Hi Greg,

Thank you very m= uch for sharing your proposal!

I think there's= one thing about the second part of your proposal that I'm missing. Spe= cifically, 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 O= P_TRUE, does that effectively mark output B as unspendable once the child g= ets confirmed? If so, isn't the implication therefore that to safely sp= end a transaction with an ephemeral anchor, all outputs must be spent? Than= ks!

Best,
Arik

On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrot= e:

Hel= lo Everyone,


Following up = on the "V3 Transaction" discussion here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-S= eptember/020937.html , I would like to elaborate a bit further on some = potential follow-on work that would make pinning severely constrained in ma= ny setups].


V3 transaction= s 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 co= sts 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 memp= ool package it is being added to already being too large in count or vsize.=


Zooming into the V3 simpl= ified scenario for sake of discussion, though this problem exists in genera= l today:


V3 transactions r= estrict the package limit of a V3 package to one parent and one child. If t= he parent transaction includes two outputs which can be immediately spent b= y separate parties, this allows one party to disallow a spend from the othe= r. In Gloria's proposal for ln-penalty, this is worked around by reduci= ng 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 hones= t 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 transact= ion, such as in other protocols like duplex payment channels, eltoo? What a= bout 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 remove= d from the package proposal. You are then left with a single V3 child trans= action, which is then proposed for entry into the mempool. In the case of a= nother parent output already being spent, this is simply rejected, regardle= ss 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 th= e mempool and takes the one child slot. This would solve it, but is a new e= viction 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 MU= ST 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.<= /span>


Implications:


<= span style=3D"font-size:11pt">a) If the ephemeral anchor MUST be spent, we = can allow *any* value, even dust, even 0, without worrying about bloating t= he utxo set. We relax this policy for maximum smart contract flexibility an= d 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 eph= emeral anchor. This causes the 1 block CSV timelock on outputs to be remove= d in these situations. This greatly magnifies composability of smart contra= cts, as now we can do things like safely splice directly into new channels,= into statechains, your custodial wallet account, your cold wallet, whereve= r, without requiring other wallets to support arbitrary scripts. Also it hu= rts that 1 CSV time locked scripts may not be miniscript compatible to begi= n with...


c) *Anyone* ca= n bump the transaction, without any transaction key material. This is essen= tially achieving Jeremy's Transaction Sponsors (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= 20-September/018168.html) proposal without c= onsensus changes. As long as someone gets a fully signed parent, they can e= xecute a bump with minimal wallet tooling. If a transaction author doesn=E2= =80=99t want a =E2=80=9Csponsor=E2=80=9D, do not include the output.=


d) Lightning Carve-out(https://lists.linuxfoundation.org/pipermail= /lightning-dev/2019-October/002240.html)=C2= =A0 is superseded by this logic, as we are not restricted to two immediatel= y 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 motiva= ting use cases that created the term =E2=80=9Cpinning=E2=80=9D 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 th= eft risks.


Open Question(= s):


  1. If we allow non-zero value in ephemeral outputs, does this open up a ME= V 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. SIGHAS= H_GROUP like constructs would allow uncommitted ephemeral anchors to be add= ed at spend time, depending on spending requirements. SIGHASH_SINGLE alread= y allows this.


=

_______________________________= ________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000cb8ff605f33f5b5e--