path: root/69/bd00b70fc638bdb67ead61da09cb6464599c85

Return-Path: <email@yancy.lol>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4DC31C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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
 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
>> <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.
> _______________________________________________
> 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

<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'>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Bob has staked liquidity in a payment channel with Alice who later<br />dou=
ble spends the same inputs (at a very low feerate) resulting in a<br />stal=
emate where neither can spend the UTXOs.</div>
</blockquote>
<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">=
I just realized I made a mistake.&nbsp; RBF will always mine the higher fee=
 transaction, so in this case, full-rbf would prevent a transaction from be=
ing pinned.</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-08 15:54, yancy via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Peter, <br /><br />It sounds like there are two attack=
 vectors; neither of which require<br />full-rbf (correct me if I'm wrong).=
 <br /><br />1) Bob has staked liquidity in a payment channel with Alice wh=
o later<br />double spends the same inputs (at a very low feerate) resultin=
g in a<br />stalemate where neither can spend the UTXOs. &nbsp;The TX that =
creates the<br />payment channel with Bob will never be mined since the min=
ing pool<br />sees the double spend? <br /><br />2) Alice spams the network=
 with a double spend wide enough that the<br />double spend makes it into a=
 block before the remainder of the network<br />sees the first spend. <br /=
><br />In that case of 1), what if Bob required a opt-in rbf? &nbsp;Wouldn'=
t that<br />solve the issue? &nbsp;Bob could just create a replacement tran=
saction with<br />enough fee to get back his UTXO? <br /><br />For 2) it se=
ems to me that neither full-rbf or opt-in rbf resolves<br />this, although =
it's a probabilistic attack and requires spamming many<br />nodes. <br /><b=
r />Cheers, <br />-Yancy <br /><br />On 2022-11-07 15:32, Peter Todd wrote:=
 <br /><br />
<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:<br />AJ/Antoine et al<br />=
<br />What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to<=
br />solve that problem if they have only opt-in RBF available?<br />Assumi=
ng Alice is a well funded advisory, with enough resources to<br />spam the =
network so that enough nodes see her malicious transaction<br />first, how =
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<br />_______________________________________________<br />bitcoin-dev m=
ailing list<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a><br /><a href=3D"https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noop=
ener noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
-dev</a></blockquote>
</div>
</body></html>

--=_915585ee1b2d4de780ff9f941d73bf2f--