Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CEE48C002D for ; Wed, 30 Nov 2022 15:32:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 87E2B4009E for ; Wed, 30 Nov 2022 15:32:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 87E2B4009E 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=qdwuOCKE 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 b71ihJ0BK7r8 for ; Wed, 30 Nov 2022 15:32:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C7FC4013E Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8C7FC4013E for ; Wed, 30 Nov 2022 15:32:51 +0000 (UTC) Received: by mail-ej1-x635.google.com with SMTP id td2so28120778ejc.5 for ; Wed, 30 Nov 2022 07:32:51 -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=/r7Os/HDqhe4tkSBT2j/kFlHASgGvg/3xOUCB4A0vcg=; b=qdwuOCKEWDYVBGezXyiBafNRP/nQ3rtPDlPRy+CfZH7YTHDu6EJLScVzucwVMK1J0x AtdboGtddnJstJqLStwc8AlDNiiQc233hTXREPHIqSQDndxhlpcT1b3qwvcIn6YwHxUT 3iJWiY3vTuyXSdGssN9vAAdG6iL3guL+vaGphK2kgdbb0eNQCkwVZcNxG/JZ2v4OaVPv sTEuha9vjc2Qme6R77nHKCbMqGTvgvbIaNyWSS/XxxiEiFSSppkFF+WnU5djHfromXCG sSZgK7DuWAGs/2mEnT//9JGlhRiGn2g4kQrYKUQ3FNkzzn36mVoOx1HUIwYDpwVukUDB L9dA== 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=/r7Os/HDqhe4tkSBT2j/kFlHASgGvg/3xOUCB4A0vcg=; b=XR+3jX8rLiE71thDhs9IuhzZy6LdRNH8/3B41nlGtuO3g5yksPfXR2hkJuGt/Tfdpm eIjGtACUIl7yhSs/5XR7TYSU8aC/ba/khxgLdQdxDPaiZf+mh44DNAX29Nm00IWV+WOn 86KcwWDQiPePGLP9pWVEbhQ/Lq+JaRkFBadvK7RxoPqA4Bux/pFFHCcLHWiRR9gb+Cy5 0ILB5uYkF8jWACHtPqUw+30ged3pTcOP09R/CQWiT/7M2HDb2P76ddFRnMjCTzzaYKtQ gIsHCA3VWTIWuolWj/YM8BrSiFyQNZysaswwRDxA7MUt6tCnlwBYhVcdVT6KAB8T79MU Fkqg== X-Gm-Message-State: ANoB5pkAn5KGuUnDdAT7W0mLCpnrwc8Gwd7YFrGa6xNZkKjOon9qfFzM l00Ig+Rj1wdaaT1InK1RGONhreJhgWEU1GQHb/d3PsYoNBU= X-Google-Smtp-Source: AA0mqf4ng0Aunii5zh4CTHfY9rLMuRqs88EyLRSVoGjFLXqtjPiZudgJdmXx5yMJW8KmGFgMte4nezJQSZNWpZjbjnM= X-Received: by 2002:a17:906:4e04:b0:78d:9b4f:44ee with SMTP id z4-20020a1709064e0400b0078d9b4f44eemr35896185eju.679.1669822369234; Wed, 30 Nov 2022 07:32:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Wed, 30 Nov 2022 10:32:36 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000002804ca05eeb1d1b2" 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: Wed, 30 Nov 2022 15:32:55 -0000 --0000000000002804ca05eeb1d1b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 >>> >> --0000000000002804ca05eeb1d1b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small update.

A bit ago I went ah= ead and implemented ephemeral anchors on top of the V3 proposal to see what= the complexity looks like:=C2=A0https://github.com/bitcoin/bitcoin/pull/26403

<= /div>
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 so= lid noninteractive ideas, unless we get some very flexible sighash softfork= . Interactively, I think you can get collaborative fee bumps under the curr= ent consensus regime and ephemeral=C2=A0anchors. The child will just be bui= lt 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 t= hat allows the contribution to feerate in an "unauthenticated" w= ay, which seems to be a very helpful feature for vaults and other contracti= ng protocols.

One possible advantage of the sponso= rs interface -- and I'm curious for your input here Greg -- is that wit= h sponsors, assuming we relaxed the "one sponsor per sponsoree" c= onstraint, multiple uncoordinated parties can collaboratively bump a tx'= ;s feerate. A simple example would be a batch withdrawal from an exchange c= ould be created with a low feerate, and then multiple users with a vested i= nterest of expedited confirmation could all "chip in" to raise th= e feerate with multiple sponsor transactions.

Having a single ephemeral output seems to create a situation where a singl= e UTXO has to shoulder the burden of CPFPing a package. Is there some way w= e could (possibly later) amend the ephemeral anchor interface to allow for = this kind of collaborative sponsoring? Could you maybe see "chained&qu= ot; ephemeral anchors that would allow this?

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

The only d= rawbacks I see=C2=A0is they don't work for lower tx version contracts, = so there's still something to be desired there, and that the requiremen= t to sweep the output must be incentive compatible for the miner, or else t= hey won't enforce it (pass the buck onto the future bitcoiners). The Ep= hemeral UTXO concept can be a consensus rule (see=C2=A0https://rubi= n.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.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">One question I have is if V3 is designed= for lightning, and this is designed for lightning, is there any sense in r= equiring 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.linuxfounda= tion.org> wrote:
> does that effectively mark output B as unspen= dable 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 restri= ctions on size, version, etc.

On Tue, Oct 18, 2022 at 11:47 AM Arik So= sman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
<= div>
Hi Greg,

Thank you very much for shar= ing your proposal!

I think there's one thing a= bout the second part of your proposal that I'm missing. Specifically, a= ssuming 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 confirme= d? If so, isn't the implication therefore that to safely spend a transa= ction with an ephemeral anchor, all outputs must be spent? Thanks!

Best,
Arik

On T= ue, 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/piper= mail/bitcoin-dev/2022-September/020937.html , I would like to elaborate= a bit further on some potential follow-on work that would make pinning sev= erely 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 mad= e 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* p= inning. In other words, a fee-paying transaction cannot enter the mempool d= ue to the existing mempool package it is being added to already being too l= arge 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 p= arent and one child. If the parent transaction includes two outputs which c= an be immediately spent by separate parties, this allows one party to disal= low a spend from the other. In Gloria's proposal for ln-penalty, this i= s worked around by reducing the number of anchors per commitment transactio= n to 1, and each version of the commitment transaction has a unique party&#= 39;s key on it. The honest participant can spend their version with their a= nchor and package RBF the other commitment transaction safely.


What if there's only one version o= f the commitment transaction, such as in other protocols like duplex paymen= t channels, eltoo? What about multi party payments?


In the package RBF proposal, if the parent transa= ction is identical to an existing transaction in the mempool, the parent wi= ll be detected and removed from the package proposal. You are then left wit= h 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 st= rongly prefer the latter:


= 1) Expand a carveout for "sibling eviction", where if the new chi= ld is paying "enough" to bump spends from the same parent, it kno= cks 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 w= orked through.


<= span style=3D"font-family:Arial">2) Ephemera= l Anchors (my real policy-only proposal)

<= br>

Ephemeral Anchors is a term which means an output is waterma= rked as an output that MUST be spent in a V3 package. We mark this anchor b= y 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.


Implicat= ions:


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 smar= t contract flexibility and specification simplicity..<= br>


b) Since this anchor MUST be spent, any spendin= g of other outputs in the same parent transaction MUST directly double-spen= d prior spends of the ephemeral anchor. This causes the 1 block CSV timeloc= k on outputs to be removed in these situations. This greatly magnifies comp= osability of smart contracts, as now we can do things like safely splice di= rectly into new channels, into statechains, your custodial wallet account, = your cold wallet, wherever, without requiring other wallets to support arbi= trary 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/p= ipermail/bitcoin-dev/2020-September/018168.html) proposal without consensus changes. As long as someone gets a fully si= gned parent, they can execute a bump with minimal wallet tooling. If a tran= saction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D, do not inc= lude the output.


d) Lightn= ing Carve-out(https://lists.linuxfo= undation.org/pipermail/lightning-dev/2019-October/002240.html= )=C2=A0 is superseded by this logic, as we are not restric= ted to two immediately spendable output scenarios. In its place, robust mul= ti-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 sim= ple spends cannot pin you. Batched payouts become a lot 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 discussion has largely over= taken 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 v= alue directly to fees, and add their own additional fees on top, otherwise = miners have incentive to make the smallest utxo burn transaction to claim t= hose funds. They just confirmed your parent transaction anyways, so do we c= are?

  2. SIGHASH_GROUP like constructs would allow uncommitted ephem= eral anchors to be added at spend time, depending on spending requirements.= SIGHASH_SINGLE already allows this.



Hopefully this gives people som= ething to consider as we move forward in thinking about mempool design with= in the constraints we have today.



Greg


0: With V3 transactions where you have "veto power" over all th= e inputs in that transaction. Therefore something like ANYONECANPAY is stil= l broken. We need a more complex solution, which I=E2=80=99m punting for th= e sake of progress.

_________= ______________________________________
bitcoin-dev mailing li= st
https://lists.linuxfoundation.org/mailman/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
--0000000000002804ca05eeb1d1b2--