Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E8057C002D for ; Thu, 27 Oct 2022 09:37:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C971960597 for ; Thu, 27 Oct 2022 09:37:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C971960597 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=NIhpzeRd X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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_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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvh22Dqx6ya8 for ; Thu, 27 Oct 2022 09:37:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 96B316006A Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by smtp3.osuosl.org (Postfix) with ESMTPS id 96B316006A for ; Thu, 27 Oct 2022 09:37:13 +0000 (UTC) Received: by mail-yb1-xb33.google.com with SMTP id y72so1128926yby.13 for ; Thu, 27 Oct 2022 02:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=To9AxH5ztWMk70ummW/wiXWntvoFC0iIb9ruTFaR3GI=; b=NIhpzeRdMcnC/ksQt5SO0KvGZMTzJaeK4Q2YdeoinSI693hE4v9HRsSs7bwUonAANh PKYzpwL3+R8DZ4o7FAbwA8+YxynzYtzfgvrS5+LrbvWIFQ6YnWqpVZMVNzLu0898wTGi BWDhP6lcQMmJ7N9Lm4JmahE39cZ//EmtVS0dMnsGZK7h1+sp1BZX/Qb74NMAHZCzUys5 /bXoXIf/KAkr69awwfKQaatMgl5lJYzKirIiDZXldntKpnWJjzuYtDUacJGYjhW4+DRJ uyoQLPix2iyWscekk+JLfbw8g2Zk82eyNTWLbkal0l5P/mmDX0zvZN4CIwATiwvBSbZm 5CHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=To9AxH5ztWMk70ummW/wiXWntvoFC0iIb9ruTFaR3GI=; b=HmTZUM5VThyDW2SwdkDzmuy2WtcMvgTwy/2zxrf/5X0yKZRJj+N8xJVkYjxIf8Xob5 8/n9ak1EiNoMMWMF5C9MVGcJwHWER+GV01m0KbmcRoKsk7qZaLvrxXtwJEa7Iq3oE2zn lEFoiZC7Yrh6Jl590PZATBnAitt7nmIBqE+RKcjnWqSNnd2lFPMamMwwEMyDCGc8KLka J1adIJHWUfqjR9XlBVxYwtaPkmh2p0UkWgNMuCxnI3j32XEhtuezh3Ij8D6sq455Uo/O 5xTfYJPRGhhzcJuExwZhQUvLRhUYw0lBcHff7D5At1kn2449SBJLO9GxvDcFjAqYbYl7 zTTw== X-Gm-Message-State: ACrzQf0RzuxFUKHq18iKO9ftvyqIb9bIEtdE4wj/RFAfn36EMPziGU3D 2mHlhqfvu4cjp8ICWdEP2Hnq+wAcUyVFBm8DRLRQjMAG3GqRmfM3 X-Google-Smtp-Source: AMsMyM7ZTeaAgLFxHjwD2z/6gzFDi5JJcVpTygV7nmYRo7kuRvGU9bZU/D3w6WAjcM+LtCj9fbOWa7w9EQ4pdLrALSI= X-Received: by 2002:a25:4942:0:b0:6bd:29b0:3ed8 with SMTP id w63-20020a254942000000b006bd29b03ed8mr44718153yba.79.1666863432369; Thu, 27 Oct 2022 02:37:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= Date: Thu, 27 Oct 2022 11:37:01 +0200 Message-ID: To: Greg Sanders , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c68ce005ec00e243" X-Mailman-Approved-At: Thu, 27 Oct 2022 09:49:52 +0000 Cc: Jeremy Rubin 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: Thu, 27 Oct 2022 09:37:16 -0000 --000000000000c68ce005ec00e243 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 unde= r > the current consensus regime and ephemeral anchors. The child will just b= e > 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 vaul= ts >> 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 the= n >> multiple users with a vested interest of expedited confirmation could al= l >> "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 so= me >> way we could (possibly later) amend the ephemeral anchor interface to al= low >> 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 mi= ner, >>> 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 f= or >>> v3? That might help with e.g. anonymity set, as well as potentially kee= p >>> 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 implicati= on >>>>> 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-Septembe= r/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 b= e made >>>>> and propagated, it costs the expected amount of fees to do so. This i= s 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 me= mpool >>>>> due to the existing mempool package it is being added to already bein= g too >>>>> large in count or vsize. >>>>> >>>>> Zooming into the V3 simplified scenario for sake of discussion, thoug= h >>>>> 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 t= o >>>>> 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 vers= ion >>>>> with their anchor and package RBF the other commitment transaction sa= fely. >>>>> >>>>> 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 t= o >>>>> an existing transaction in the mempool, the parent will be detected a= nd >>>>> 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 th= e 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 i= s >>>>> paying "enough" to bump spends from the same parent, it knocks its si= bling >>>>> 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 thr= ough. >>>>> >>>>> 2) Ephemeral Anchors (my real policy-only proposal) >>>>> >>>>> Ephemeral Anchors is a term which means an output is watermarked as a= n >>>>> output that MUST be spent in a V3 package. We mark this anchor by bei= ng the >>>>> bare script `OP_TRUE` and of course make these outputs standard to re= lay >>>>> 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 r= elax >>>>> 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 o= f 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 n= ew >>>>> channels, into statechains, your custodial wallet account, your cold >>>>> wallet, wherever, without requiring other wallets to support arbitrar= y >>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be mini= script >>>>> 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-Septembe= r/018168.html) >>>>> proposal without consensus changes. As long as someone gets a fully s= igned >>>>> 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-Octobe= r/002240.html) >>>>> is superseded by this logic, as we are not restricted to two immediat= ely >>>>> spendable output scenarios. In its place, robust multi-party fee bump= ing 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 painf= ul. >>>>> 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-February= /015717.html), >>>>> even if LN/L2 discussion has largely overtaken it due to HTLC theft r= isks. >>>>> >>>>> 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 dire= ctly to >>>>> fees, and add their own additional fees on top, otherwise miners h= ave >>>>> incentive to make the smallest utxo burn transaction to claim thos= e 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 requireme= nts. >>>>> 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=E2=80=99m punting fo= r 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 > --000000000000c68ce005ec00e243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Greg.

I find this proposal super interesting, and IIUC= something that seems fairly=C2=A0"safe" to allow (assuming V3).<= /div>

For LN having the commitment=C2=A0transaction pay = a non-zero fee is a cause for a lot of complexity in the channel state mach= ine. Something like this would remove a lot of edge cases and add more flex= ibility around adding HTLCs.

Thanks!
- Johan

On Thu, Oct 20, 2022 at 3:42 PM Greg Sa= nders via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
So it doesn&#= 39;t look like I'm ignoring a good question:

No soli= d noninteractive ideas, unless we get some very flexible sighash softfork. = Interactively, I think you can get collaborative fee bumps under the curren= t consensus regime and ephemeral=C2=A0anchors. The child will just be built= with inputs from different people.

On Wed, Oct 19, 2022 at 11:12 AM J= ames O'Beirne <james.obeirne@gmail.com> wrote:
I'm also very ha= ppy to see this proposal, since it gets us closer to having a mechanism tha= t 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" con= straint, multiple uncoordinated parties can collaboratively bump a tx's= feerate. A simple example would be a batch withdrawal from an exchange cou= ld be created with a low feerate, and then multiple users with a vested int= erest of expedited confirmation could all "chip in" to raise the = feerate with multiple sponsor transactions.

H= aving 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 th= is 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 a= gree it does capture much of the spirit of sponsors w.r.t. how they might b= e used for V3 protocols.

The only dr= awbacks I see=C2=A0is they don't work for lower tx version contracts, s= o 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 th= ey won't enforce it (pass the buck onto the future bitcoiners). The Eph= emeral UTXO concept can be a consensus rule (see=C2=A0https://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 lightnin= g, is there any sense in requiring these outputs for v3? That might help wi= th e.g. anonymity set, as well as potentially keep the v3 surface smaller.<= /div>

On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
> does that effectivel= y 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 V= 3/ephemeral anchor restrictions on size, version, etc.

On Tue, Oct 18,= 2022 at 11:47 AM Arik Sosman via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hi Greg,

Tha= nk you very much for sharing your proposal!

I thin= k there's one thing about the second part of your proposal that I'm= missing. Specifically, assuming the scenario of a v3 transaction with thre= e outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction s= pends A and OP_TRUE, does that effectively mark output B as unspendable onc= e the child gets confirmed? If so, isn't the implication therefore that= to safely spend a transaction with an ephemeral anchor, all outputs must b= e spent? Thanks!

Best,
Arik

On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bit= coin-dev wrote:

Hello Everyone,


Following up on the "V3 Transaction&q= uot; discussion here https://lists.li= nuxfoundation.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 r= eplacement is to be made and propagated, it costs the expected amount of fe= es to do so. This is a great start. What's left in this subset of pinni= ng is *package limit* pinning. In other words, a fee-paying transaction can= not 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 di= scussion, 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 include= s two outputs which can be immediately spent by separate parties, this allo= ws one party to disallow a spend from the other. In Gloria's proposal f= or 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 protoco= ls 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 m= empool, the parent will be detected and removed from the package proposal. = You are then left with a single V3 child transaction, which is then propose= d 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 chil= d.


I have two proposed s= olutions, 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 mea= ns 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.<= /span>


Also as a simplifying assumption,= we require the parent transaction with such an output to be 0-fee. This ma= kes mempool reasoning simpler in case the child-spend is somehow evicted, g= uaranteeing 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 p= olicy 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 MUS= T directly double-spend prior spends of the ephemeral anchor. This causes t= he 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 cust= odial wallet account, your cold wallet, wherever, without requiring other w= allets to support arbitrary scripts. Also it hurts that 1 CSV time locked s= cripts may not be miniscript compatible to begin with...


= c) *Anyone* can bump the transaction, withou= t 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 s= omeone gets a fully signed parent, they can execute a bump with minimal wal= let tooling. If a transaction author doesn=E2=80=99t want a =E2=80=9Csponso= r=E2=80=9D, do not include the output.

d) Lightning Carve-out(https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002= 240.html)=C2=A0 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.


<= span style=3D"font-size:11pt">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 l= ot less painful. 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-= February/015717.html), even if LN/L2 discuss= ion has largely overtaken it due to HTLC theft risks.<= br>


Open Question(s):

<= div>

  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 f= ees on top, otherwise miners have incentive to make the smallest utxo burn = transaction to claim those funds. They just confirmed your parent transacti= on 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.




Hopefull= y this gives people something to consider as we move forward in thinking ab= out 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 li= ke ANYONECANPAY is still broken. We need a more complex solution, which I= =E2=80=99m punting for the sake of progress.

_______________________________________________
bitcoin-dev mailing list

=
_______________________________________________
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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000c68ce005ec00e243--