path: root/63/6c9cf340803786d1e7ae9b0a31618c812b4cab

Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4B72DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <pete@petertodd.org>
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 <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
> <bitcoin-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 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Peter,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
It sounds like there are two attack vectors; neither of which require full-=
rbf (correct me if I'm wrong).</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
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.&nbsp; The TX that creates the payment cha=
nnel with Bob will never be mined since the mining pool sees the double spe=
nd?</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
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.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
In that case of 1), what if Bob required a opt-in rbf?&nbsp; Wouldn't that =
solve the issue?&nbsp; Bob could just create a replacement transaction with=
 enough fee to get back his UTXO?</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
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.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-11-07 15:32, Peter Todd wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-=
dev<br />&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br />AJ/Antoine et al<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">What should folks wanting to do coinjoins/dualfunding/=
dlcs/etc do to<br />solve that problem if they have only opt-in RBF availab=
le?</blockquote>
<br />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?</blockquote>
<br />First of all, to make things clear, remember that the attacks were<br=
 />talking about are aimed at _preventing_ a transaction from getting<br />=
mined. Alice wants to cheaply broadcast something with low fees that<br />w=
on't get mined soon (if ever), that prevents a protocol from making<br />fo=
rward progress.<br /><br />With full-rbf, who saw what transaction first do=
esn't matter: the<br />higher fee paying transaction will always(*) replace=
 the lower fee<br />one. With opt-in RBF, spamming the network can beat out=
 the<br />alternative.<br /><br />*) So what's the catch? Well, due to limi=
tations in today's mempool<br />implementation, sometimes we can't fully ev=
aluate which tx pays the<br />higher fee. For example, if Alice spams the n=
etwork with very _large_<br />numbers transactions spending that input, the=
 current mempool code<br />doesn't even try to figure out if a replacement =
is better.<br /><br />But those limitations are likely to be fixable. And e=
ven right now,<br />without fixing them, Alice still has to use a lot more =
money to pull<br />off these attacks with full-rbf. So full-rbf definitely =
improves the<br />situation even if it doesn't solve the problem completely=
=2E</blockquote>
</div>
</body></html>

--=_616f88a50eca45d239d6ecbb5840f2ff--