Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF2B7C002D for ; Tue, 18 Oct 2022 15:51:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7C6BD40467 for ; Tue, 18 Oct 2022 15:51:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7C6BD40467 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=IEOj6a7/ 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0MYVHtK10p3 for ; Tue, 18 Oct 2022 15:51:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 79392402DC Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by smtp2.osuosl.org (Postfix) with ESMTPS id 79392402DC for ; Tue, 18 Oct 2022 15:51:44 +0000 (UTC) Received: by mail-ed1-x52a.google.com with SMTP id z97so21119206ede.8 for ; Tue, 18 Oct 2022 08:51:44 -0700 (PDT) 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=2rNoUswizAatCnc6RkyPMp8R3zTaYIGSeYp8hwiZas4=; b=IEOj6a7/gib9R5BQGKL8uYMw/Gw4MNGcsNvvr9K5Vs+etA7ROqKrXOAym13Kzq0gn3 s8cxyQttsCm41KJ1yhswHDGeLeVpVoDJAC2i1jdU54Hp7KwTKTHi/aC36MhOLDO55gqb 9nPEAD/72gE+8rydliAlZwdEZfId5zg+BC4VDbSaGauwtb/b59E7FDRIbQ4WhyoebhCC 1FwgLPot/9fdczPQN/QZpyYo494YqzXmnCk5N6m0BjaT87hWhJ8eZSaqtmWCEOlbfwdY Z82ZBtv4A0E3egwuyBlqE/REqvyYcGOI2pqg/r7iAj4aHgq6Q3bqOrm4GIfH1CENE2UZ dMUw== 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=2rNoUswizAatCnc6RkyPMp8R3zTaYIGSeYp8hwiZas4=; b=vyhquKqvomEhhhbDC5GzlQaGPVNNiay7eap3wwdlWH9fPWK5Wzfx1FmuNsaZrLO3fd YAWzEVfJC5pGF4YNShIZeVYpgPLjR99UakOa00KlG5OmqbPbe4XsE30gVO+c96jIvE1E sebu6hJx2LjC0Ft0WXnJsfgF/xuV/mIGAw9WcPFx8btHUoNggKxuP/gh3cyEPVZ1waHc 2ZfbPKNRvvUmT4e72o8YanmwLVmBObTQIY44Ag30ePVWQY0r4Qs3jno4O+QtLC27wdt3 pnK1l3uBma4vLRq4/ZmkO+0Tpet5pxgHsD4DcKIFquoJRHV1Q6cPITJcAPLUtSOdE6Gq /96w== X-Gm-Message-State: ACrzQf1aRgYO57s79oggtEhH2w6OFINwoahWqhrB5D3JbsUMnsScC5tZ CDYGJWC1wLEqQ6q4tUbEC2J7uGmz0LnB0MejKAjJm7Hy X-Google-Smtp-Source: AMsMyM5l+8rPHbRwuX3bPsb0g3VRmDnRp/VyGAy7x0eQnzJm6B1zkoUF8NLWDRkqjG0g/IelveKX2fnEEwAzWvLEEzM= X-Received: by 2002:a50:ed86:0:b0:458:e1da:af2 with SMTP id h6-20020a50ed86000000b00458e1da0af2mr3112503edr.364.1666108302363; Tue, 18 Oct 2022 08:51:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Tue, 18 Oct 2022 11:51:30 -0400 Message-ID: To: Arik Sosman , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000085137005eb51119f" 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: Tue, 18 Oct 2022 15:51:46 -0000 --00000000000085137005eb51119f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 thr= ee > 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 tha= t > 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/02= 0937.html > , I would like to elaborate a bit further on some potential follow-on wor= k > 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 grea= t > 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 b= e > 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 o= n > 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 i= n > other protocols like duplex payment channels, eltoo? What about multi par= ty > 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 chi= ld > transaction, which is then proposed for entry into the mempool. In the ca= se > 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 siblin= g > 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 t= he > 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 we= ll. > > 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 simplicit= y.. > > 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 smar= t > 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 miniscri= pt > 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/01= 8168.html) > proposal without consensus changes. As long as someone gets a fully signe= d > 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 n= ot include the output. > > d) Lightning Carve-out( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/00= 2240.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 output= s > 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 wa= s > 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/015= 717.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 t= o > fees, and add their own additional fees on top, otherwise miners have > incentive to make the smallest utxo burn transaction to claim those fu= nds. > 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 i= n > that transaction. Therefore something like ANYONECANPAY is still broken. = We > need a more complex solution, which I=E2=80=99m punting for the sake of p= rogress. > _______________________________________________ > 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 > --00000000000085137005eb51119f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> does that effectively mark output B as unspendable on= ce the child gets confirmed?

Not at all. It's a norm= al spend like before, since the parent has been confirmed. It's complet= ely unrestricted, not being bound to any V3/ephemeral anchor restrictions o= n 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 ephemera= l anchor OP_TRUE. If a child transaction spends A and OP_TRUE, does that ef= fectively mark output B as unspendable once the child gets confirmed? If so= , isn't the implication therefore that to safely spend a transaction wi= th 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 Ever= yone,


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 potenti= al follow-on work that would make pinning severely constrained in many setu= ps].


V3 transactions may s= olve bip125 rule#3 and rule#5 pinning attacks under some constraints[0]. Th= is 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 i= n this subset of pinning is *package limit* pinning. In other words, a fee-= paying transaction cannot enter the mempool due to the existing mempool pac= kage it is being added to already being too large in count or vsize.=


Zooming into the V3 simplified s= cenario 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 pare= nt transaction includes two outputs which can be immediately spent by separ= ate parties, this allows one party to disallow a spend from the other. In G= loria'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 parti= cipant can spend their version with their anchor and package RBF the other = commitment transaction safely.


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= pace:pre-wrap">What if there's only one version of the commitment transaction, su= ch as in other protocols like duplex payment channels, eltoo? What about mu= lti party payments?


In th= e package RBF proposal, if the parent transaction is identical to an existi= ng 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 memp= ool and takes the one child slot. This would solve it, but is a new evictio= n paradigm that would need to be carefully worked through.


2) Ephemeral Anchors (my real policy-only = proposal)


Ephemeral Anch= ors is a term which means an output is watermarked as an output that MUST b= e spent in a V3 package. We mark this anchor by being the bare script `OP_T= RUE` and of course make these outputs standard to relay and spend with empt= y witness data.


= Also as a = simplifying assumption, we require the parent transaction with such an outp= ut to be 0-fee. This makes mempool reasoning simpler in case the child-spen= d is somehow evicted, guaranteeing the parent will be as well.


Implications:
=


a) If the ephemeral anchor MUST be spent, we can a= llow *any* value, even dust, even 0, without worrying about bloating the ut= xo set. We relax this policy for maximum smart contract flexibility and spe= cification simplicity..


= b) Since this anchor MUST be spent, any spending of other outputs in the sa= me parent transaction MUST directly double-spend prior spends of the epheme= ral anchor. This causes the 1 block CSV timelock on outputs to be removed i= n these situations. This greatly magnifies composability of smart contracts= , as now we can do things like safely splice directly into new channels, in= to 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 w= ith...


c) *Anyone* can bum= p the transaction, without any transaction key material. This is essentiall= y achieving Jeremy's Transaction Sponsors (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Se= ptember/018168.html) proposal without consen= sus changes. As long as someone gets a fully signed parent, they can execut= e 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/lig= htning-dev/2019-October/002240.html)=C2=A0 i= s superseded by this logic, as we are not restricted to two immediately spe= ndable output scenarios. In its place, robust multi-party fee bumping is po= ssible.


e) This also benef= its more traditional wallet scenarios, as change outputs can no longer be p= inned, 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 =E2=80=9Cpinning=E2=80=9D in the first plac= e(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 a= re worried about? Wallets should toss all the value directly to fees, and a= dd their own additional fees on top, otherwise miners have incentive to mak= e the smallest utxo burn transaction to claim those funds. They just confir= med your parent transaction anyways, so do we care?

  2. SIGHASH_GROU= P like constructs would allow uncommitted ephemeral anchors to be added at = spend time, depending on spending requirements. SIGHASH_SINGLE already allo= ws this.



=

Hopefully this gives people something to consider as we mov= e forward in thinking about mempool design within the constraints we have t= oday.



Greg<= /span>


0: With V3 transactions wh= ere you have "veto power" over all the inputs in that transaction= . Therefore something like ANYONECANPAY is still broken. We need a more com= plex 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
--00000000000085137005eb51119f--