Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 311FEC002D for ; Tue, 18 Oct 2022 15:40:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C77AE823CF for ; Tue, 18 Oct 2022 15:40:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C77AE823CF Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=arik.io header.i=@arik.io header.a=rsa-sha256 header.s=fm1 header.b=o26NkmBB; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=J6Okiycg X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2q_oJbVnJNL for ; Tue, 18 Oct 2022 15:40:57 +0000 (UTC) X-Greylist: delayed 00:06:58 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D267281A64 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by smtp1.osuosl.org (Postfix) with ESMTPS id D267281A64 for ; Tue, 18 Oct 2022 15:40:56 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4F008320092E for ; Tue, 18 Oct 2022 11:33:53 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute2.internal (MEProxy); Tue, 18 Oct 2022 11:33:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arik.io; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1666107232; x=1666193632; bh=a5TVldxbiS 9Cojd+PbC0uevVTcuG4+KKf8fLnySMbh0=; b=o26NkmBBSoNp6ZR/MK4s/jqJ0r RobI9x6Pi01pKYHHRYxbRKE1Xb/nzmHP1v5r4+HJpqwUDNVghYR/gZ43v+BSYI0X 6eSo6nxcI2ArtDnQ0AEwOFl8w/PHleC4eyOaLvGVCRIQBQh5ohwaJmvC1xuVFh0y TGCU0YA1jKMX84f0Q3n3iRKjWEnZUqWsCAf84ZnARcyhcUy/4sYB4sLMNVQzPwqk w4DM+sdmyuu1gytAyxKBjFItJJhGq0+514D9H40oMUte86fOjNWQaM5ghn2yQwoE 3qtcGE6AOUEB8z62nhUfPuR2rYyiy8hQvhoKdmHvS5zQT40sPrgwQOY+TOiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666107232; x=1666193632; bh=a5TVldxbiS9Cojd+PbC0uevVTcuG 4+KKf8fLnySMbh0=; b=J6OkiycggLWi1I5LlD3v8OO1+iP3BHC7KYixTHIyNcDN qwPyDemAOzO7bICsB4ZRR+OC3ugWRZXz+j1eFrUubzkrdcgmDT1RQJSkeM72GwmU EpbcQRNFv43oPxbQxzZB96Z/zIGKKVxcmjzaUlM5PmD5Uhy3ZMU3CWyFK5/TJYoM KAzhonkXmIK0p2KyNXMxh+/cDdMzCoZBl/JsyjeTLegv/ReLw+f9EQSvY0JrboKL vyQVnGgRE79y6c3ZpH4E6elqHjK1KyncpAaY3JVK4gOrEzb95oeb2Bu3o67r12+U tQc9d1bfsjWw8dqgsP2yg9G57knnICrwMj4wO7kdbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelvddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftehrihhkucfuohhsmhgrnhdfuceolhhinhhugihfohhu nhgurghtihhonhesrghrihhkrdhioheqnecuggftrfgrthhtvghrnhepheeiueduuddtff eiffegfeeiffehtedtledtgfeihfelhfetudffkeehheefhfdunecuffhomhgrihhnpehl ihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheplhhinhhugihfohhunhgurghtihhonhesrghrihhk rdhioh X-ME-Proxy: Feedback-ID: i2359471f:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE817BC0083; Tue, 18 Oct 2022 11:33:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 18 Oct 2022 08:33:32 -0700 From: "Arik Sosman" To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=777b826cc2484de1bc0722d4ad4851e5 X-Mailman-Approved-At: Tue, 18 Oct 2022 15:46:58 +0000 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:40:59 -0000 --777b826cc2484de1bc0722d4ad4851e5 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 transa= ction spends A and OP_TRUE, does that effectively mark output B as unspe= ndable once the child gets confirmed? If so, isn't the implication there= fore that to safely spend a transaction with an ephemeral anchor, all ou= tputs must be spent? Thanks! Best, Arik On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote: > Hello Everyone, >=20 >=20 > Following up on the "V3 Transaction" discussion here https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html , I wo= uld like to elaborate a bit further on some potential follow-on work tha= t would make pinning severely constrained in many setups]. >=20 >=20 > V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks und= er 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 mempo= ol due to the existing mempool package it is being added to already bein= g too large in count or vsize. >=20 >=20 > Zooming into the V3 simplified scenario for sake of discussion, though= this problem exists in general today: >=20 >=20 > V3 transactions restrict the package limit of a V3 package to one pare= nt and one child. If the parent transaction includes two outputs which c= an be immediately spent by separate parties, this allows one party to di= sallow a spend from the other. In Gloria's proposal for ln-penalty, this= is worked around by reducing the number of anchors per commitment trans= action 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. >=20 >=20 > What if there's only one version of the commitment transaction, such a= s in other protocols like duplex payment channels, eltoo? What about mul= ti party payments? >=20 >=20 > 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 c= hild transaction, which is then proposed for entry into the mempool. In = the case of another parent output already being spent, this is simply re= jected, regardless of feerate of the new child. >=20 >=20 > I have two proposed solutions, of which I strongly prefer the latter: >=20 >=20 > 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 sibl= ing 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. >=20 >=20 > 2) Ephemeral Anchors (my real policy-only proposal) >=20 >=20 > 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. >=20 >=20 > Also as a simplifying assumption, we require the parent transaction wi= th such an output to be 0-fee. This makes mempool reasoning simpler in c= ase the child-spend is somehow evicted, guaranteeing the parent will be = as well. >=20 >=20 > Implications: >=20 >=20 > a) If the ephemeral anchor MUST be spent, we can allow *any* value, ev= en dust, even 0, without worrying about bloating the utxo set. We relax = this policy for maximum smart contract flexibility and specification sim= plicity.. >=20 >=20 > b) Since this anchor MUST be spent, any spending of other outputs in t= he same parent transaction MUST directly double-spend prior spends of th= e ephemeral anchor. This causes the 1 block CSV timelock on outputs to b= e removed in these situations. This greatly magnifies composability of s= mart contracts, as now we can do things like safely splice directly into= new channels, into statechains, your custodial wallet account, your col= d wallet, wherever, without requiring other wallets to support arbitrary= scripts. Also it hurts that 1 CSV time locked scripts may not be minisc= ript compatible to begin with... >=20 >=20 > c) *Anyone* can bump the transaction, without any transaction key mate= rial. This is essentially achieving Jeremy's Transaction Sponsors (https= ://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168= .html) proposal without consensus changes. As long as someone gets a ful= ly signed parent, they can execute a bump with minimal wallet tooling. I= f a transaction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D,= do not include the output. >=20 >=20 > d) Lightning Carve-out(https://lists.linuxfoundation.org/pipermail/lig= htning-dev/2019-October/002240.html) is superseded by this logic, as we= are not restricted to two immediately spendable output scenarios. In it= s place, robust multi-party fee bumping is possible. >=20 >=20 > e) This also benefits more traditional wallet scenarios, as change out= puts 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. Th= is was one of the motivating use cases that created the term =E2=80=9Cpi= nning=E2=80=9D in the first place(https://lists.linuxfoundation.org/pipe= rmail/bitcoin-dev/2018-February/015717.html), even if LN/L2 discussion h= as largely overtaken it due to HTLC theft risks. >=20 >=20 > Open Question(s): >=20 >=20 > 1. If we allow non-zero value in ephemeral outputs, does this open up= a MEV we are worried about? Wallets should toss all the value directly = to fees, and add their own additional fees on top, otherwise miners have= incentive to make the smallest utxo burn transaction to claim those fun= ds. They just confirmed your parent transaction anyways, so do we care? >=20 > 2. SIGHASH_GROUP like constructs would allow uncommitted ephemeral an= chors to be added at spend time, depending on spending requirements. SIG= HASH_SINGLE already allows this. >=20 >=20 >=20 >=20 > Hopefully this gives people something to consider as we move forward i= n thinking about mempool design within the constraints we have today. >=20 >=20 >=20 > Greg >=20 >=20 > 0: With V3 transactions where you have "veto power" over all the input= s in that transaction. Therefore something like ANYONECANPAY is still br= oken. We need a more complex solution, which I=E2=80=99m punting for the= sake of progress. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 --777b826cc2484de1bc0722d4ad4851e5 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

Thank you very much for sharing your proposal!

I think there's one thing about the second part o= f your proposal that I'm missing. Specifically, assuming the scenario of= a v3 transaction with three outputs, A, B, and the ephemeral anchor OP_= TRUE. If a child transaction spends A and OP_TRUE, does that effectively= mark output B as unspendable once the child gets confirmed? If so, isn'= t the implication therefore that to safely spend a transaction with an e= phemeral anchor, all outputs must be spent? Thanks!

Best,
Arik

On Tue, Oct 1= 8, 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-de= v/2022-September/020937.html , I would like to elaborate a bit furth= er on some potential follow-on work that would make pinning severely con= strained in many setups].


V3 transactions may s= olve 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 cos= ts the expected amount of fees to do so. This is a great start. What's l= eft 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 f= or 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 all= ows 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 p= er commitment transaction to 1, and each version of the commitment trans= action has a unique party's key on it. The honest participant can spend = their version with their anchor and package RBF the other commitment tra= nsaction safely.


What if there's only one versi= on 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 ide= ntical to an existing transaction in the mempool, the parent will be det= ected and removed from the package proposal. You are then left with a si= ngle V3 child transaction, which is then proposed for entry into the mem= pool. 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 evictio= n", where if the new child is paying "enough" to bump spends from the sa= me parent, it knocks its sibling out of the mempool and takes the one ch= ild slot. This would solve it, but is a new eviction paradigm that would= need to be carefully worked through.

<= br>

2) Epheme= ral Anchors (my real policy-only proposal)

<= div>

Ephe= meral Anchors is a term which means an output is watermarked as an outpu= t that MUST be spent in a V3 package. We mark this anchor by being the b= are script `OP_TRUE` and of course make these outputs standard to relay = and spend with empty witness data.


=

Also as a si= mplifying assumption, we require the parent transaction with such an out= put 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 ephem= eral 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 m= aximum smart contract flexibility and specification simplicity..<= /span>


b) Since this anchor MUST be spent, any spending of ot= her outputs in the same parent transaction MUST directly double-spend pr= ior spends of the ephemeral anchor. This causes the 1 block CSV timelock= on outputs to be removed in these situations. This greatly magnifies co= mposability of smart contracts, as now we can do things like safely spli= ce directly into new channels, into statechains, your custodial wallet a= ccount, your cold wallet, wherever, without requiring other wallets to s= upport arbitrary scripts. Also it hurts that 1 CSV time locked scripts m= ay not be miniscript compatible to begin with...


c) *Anyone* can bump the transaction, without any transaction key mate= rial. This is essentially achieving Jeremy's Transaction Sponsors (https:= //lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.= html) proposal without consensus changes. As long as someone gets a f= ully 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 rest= ricted to two immediately spendable output scenarios. In its place, robu= st 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 spend= s cannot pin you. Batched payouts become a lot less painful. This was on= e 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-de= v/2018-February/015717.html), even if LN/L2 discussion has largely ov= ertaken it due to HTLC theft risks.

Open Questi= on(s):


  1. If we allow non-zero val= ue in ephemeral outputs, does this open up a MEV we are worried about? W= allets should toss all the value directly to fees, and add their own add= itional fees on top, otherwise miners have incentive to make the smalles= t utxo burn transaction to claim those funds. They just confirmed your p= arent 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 requi= rements. SIGHASH_SINGLE already allows this.

    3. <= /ol>



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



Greg<= /span>


= 0: With V3 transactions where you have "veto po= wer" over all the inputs in that transaction. Therefore something like A= NYONECANPAY is still broken. We need a more complex solution, which I=E2= =80=99m punting for the sake of progress.

_______________________________________________
bitcoin-dev mailing list


<= /html> --777b826cc2484de1bc0722d4ad4851e5--