Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4B72DC002D for ; Tue, 8 Nov 2022 14:54:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 18BC240382 for ; Tue, 8 Nov 2022 14:54:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 18BC240382 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Mja6S4sG4_9F for ; Tue, 8 Nov 2022 14:54:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6670F40363 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6670F40363 for ; Tue, 8 Nov 2022 14:54:52 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id 1777FC0011; Tue, 8 Nov 2022 14:54:46 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 08 Nov 2022 15:54:46 +0100 From: email@yancy.lol To: Peter Todd In-Reply-To: <0A6B5781-EBC6-4D98-8AE8-43436B5F73EA@petertodd.org> References: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> <0A6B5781-EBC6-4D98-8AE8-43436B5F73EA@petertodd.org> Message-ID: <8c13eebc9baf1e347ce3327d5fc34060@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_616f88a50eca45d239d6ecbb5840f2ff" X-Mailman-Approved-At: Tue, 08 Nov 2022 18:30:39 +0000 Cc: Bitcoin Protocol Discussion , Anthony Towns Subject: Re: [bitcoin-dev] On mempool policy consistency 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, 08 Nov 2022 14:54:54 -0000 --=_616f88a50eca45d239d6ecbb5840f2ff Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Peter, It sounds like there are two attack vectors; neither of which require full-rbf (correct me if I'm wrong). 1) Bob has staked liquidity in a payment channel with Alice who later double spends the same inputs (at a very low feerate) resulting in a stalemate where neither can spend the UTXOs. The TX that creates the payment channel with Bob will never be mined since the mining pool sees the double spend? 2) Alice spams the network with a double spend wide enough that the double spend makes it into a block before the remainder of the network sees the first spend. In that case of 1), what if Bob required a opt-in rbf? Wouldn't that solve the issue? Bob could just create a replacement transaction with enough fee to get back his UTXO? For 2) it seems to me that neither full-rbf or opt-in rbf resolves this, although it's a probabilistic attack and requires spamming many nodes. Cheers, -Yancy On 2022-11-07 15:32, Peter Todd wrote: > On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev > wrote: > AJ/Antoine et al > > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to > solve that problem if they have only opt-in RBF available? > Assuming Alice is a well funded advisory, with enough resources to spam > the network so that enough nodes see her malicious transaction first, > how does full-rbf solve this vs. opt-in rbf? First of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress. With full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative. *) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better. But those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely. --=_616f88a50eca45d239d6ecbb5840f2ff Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= Peter,
=  
= It sounds like there are two attack vectors; neither of which require full-= rbf (correct me if I'm wrong).
=  
= 1) Bob has staked liquidity in a payment channel with Alice who later doubl= e spends the same inputs (at a very low feerate) resulting in a stalemate w= here neither can spend the UTXOs.  The TX that creates the payment cha= nnel with Bob will never be mined since the mining pool sees the double spe= nd?
=  
= 2) Alice spams the network with a double spend wide enough that the double = spend makes it into a block before the remainder of the network sees the fi= rst spend.
=  
= In that case of 1), what if Bob required a opt-in rbf?  Wouldn't that = solve the issue?  Bob could just create a replacement transaction with= enough fee to get back his UTXO?
=  
= For 2) it seems to me that neither full-rbf or opt-in rbf resolves this, al= though it's a probabilistic attack and requires spamming many nodes.
=  
= Cheers,
= -Yancy
=  
= On 2022-11-07 15:32, Peter Todd wrote:
On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-= dev
<bitco= in-dev@lists.linuxfoundation.org> wrote:

AJ/Antoine et al

What should folks wanting to do coinjoins/dualfunding/= dlcs/etc do to
solve that problem if they have only opt-in RBF availab= le?

Assuming Alice is a well funded advisory, with enough resources to sp= am the network so that enough nodes see her malicious transaction first, ho= w does full-rbf solve this vs. opt-in rbf?

First of all, to make things clear, remember that the attacks weretalking about are aimed at _preventing_ a transaction from getting
= mined. Alice wants to cheaply broadcast something with low fees that
w= on't get mined soon (if ever), that prevents a protocol from making
fo= rward progress.

With full-rbf, who saw what transaction first do= esn't matter: the
higher fee paying transaction will always(*) replace= the lower fee
one. With opt-in RBF, spamming the network can beat out= the
alternative.

*) So what's the catch? Well, due to limi= tations in today's mempool
implementation, sometimes we can't fully ev= aluate which tx pays the
higher fee. For example, if Alice spams the n= etwork with very _large_
numbers transactions spending that input, the= current mempool code
doesn't even try to figure out if a replacement = is better.

But those limitations are likely to be fixable. And e= ven right now,
without fixing them, Alice still has to use a lot more = money to pull
off these attacks with full-rbf. So full-rbf definitely = improves the
situation even if it doesn't solve the problem completely= =2E
--=_616f88a50eca45d239d6ecbb5840f2ff--