Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4DC31C002D for ; Wed, 9 Nov 2022 12:09:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 2835060EB8 for ; Wed, 9 Nov 2022 12:09:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2835060EB8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_RP_RNBL=0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 YoAjxVCqRkfW for ; Wed, 9 Nov 2022 12:09:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9B48160BFA Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9B48160BFA for ; Wed, 9 Nov 2022 12:09:08 +0000 (UTC) Received: from relay9-d.mail.gandi.net (unknown [217.70.183.199]) by mslow1.mail.gandi.net (Postfix) with ESMTP id 75A66CCEFA for ; Wed, 9 Nov 2022 12:05:23 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id 0629AFF810; Wed, 9 Nov 2022 12:05:16 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 09 Nov 2022 13:05:16 +0100 From: email@yancy.lol To: email@yancy.lol, Bitcoin Protocol Discussion In-Reply-To: <8c13eebc9baf1e347ce3327d5fc34060@yancy.lol> References: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> <0A6B5781-EBC6-4D98-8AE8-43436B5F73EA@petertodd.org> <8c13eebc9baf1e347ce3327d5fc34060@yancy.lol> Message-ID: <3ac1efdd9b332410887574f449aa6711@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_915585ee1b2d4de780ff9f941d73bf2f" X-Mailman-Approved-At: Wed, 09 Nov 2022 13:02:06 +0000 Cc: 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: Wed, 09 Nov 2022 12:09:10 -0000 --=_915585ee1b2d4de780ff9f941d73bf2f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > 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. I just realized I made a mistake. RBF will always mine the higher fee transaction, so in this case, full-rbf would prevent a transaction from being pinned. On 2022-11-08 15:54, yancy via bitcoin-dev wrote: > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=_915585ee1b2d4de780ff9f941d73bf2f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= Bob has staked liquidity in a payment channel with Alice who later
dou= ble spends the same inputs (at a very low feerate) resulting in a
stal= emate where neither can spend the UTXOs.
=  
= I just realized I made a mistake.  RBF will always mine the higher fee= transaction, so in this case, full-rbf would prevent a transaction from be= ing pinned.
=  
= On 2022-11-08 15:54, yancy via bitcoin-dev wrote:
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 wh= o later
double spends the same inputs (at a very low feerate) resultin= g in a
stalemate where neither can spend the UTXOs.  The TX that = creates the
payment channel with Bob will never be mined since the min= ing 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 tran= saction with
enough fee to get back his UTXO?

For 2) it se= ems 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
<bitco= in-dev@lists.linuxfoundation.org> wrote:
AJ/Antoine et al
=
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to<= br />solve that problem if they have only opt-in RBF available?
Assumi= ng 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 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
_______________________________________________
bitcoin-dev m= ailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev
--=_915585ee1b2d4de780ff9f941d73bf2f--