From: email@yancy•lol
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Tue, 08 Nov 2022 15:54:46 +0100 [thread overview]
Message-ID: <8c13eebc9baf1e347ce3327d5fc34060@yancy.lol> (raw)
In-Reply-To: <0A6B5781-EBC6-4D98-8AE8-43436B5F73EA@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4493 bytes --]
next prev parent reply other threads:[~2022-11-08 14:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 21:06 email
2022-11-07 14:32 ` Peter Todd
2022-11-07 14:47 ` Erik Aronesty
2022-11-08 14:54 ` email [this message]
2022-11-09 12:05 ` email
[not found] <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-27 9:56 ` John Carvalho
2022-10-27 17:21 ` Anthony Towns
2022-10-27 17:35 ` Suhas Daftuar
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ
2022-11-10 14:38 ` email
-- strict thread matches above, loose matches on Subject: below --
2022-10-26 23:52 Anthony Towns
2022-10-27 12:36 ` Gloria Zhao
2022-10-27 15:37 ` Anthony Towns
2022-10-27 18:17 ` Luke Dashjr
2022-10-27 13:49 ` Greg Sanders
2022-10-27 15:00 ` Peter Todd
2022-10-27 20:29 ` Antoine Riard
2022-10-30 2:24 ` Anthony Towns
2022-10-29 7:45 ` David A. Harding
2022-10-30 1:02 ` Anthony Towns
2022-10-30 2:40 ` Anthony Towns
2022-10-30 11:06 ` email
2022-10-31 13:02 ` Suhas Daftuar
2022-10-31 16:25 ` Greg Sanders
2022-10-31 17:21 ` email
2022-10-31 17:51 ` Peter Todd
2022-11-04 10:28 ` email
2022-11-02 3:07 ` Anthony Towns
2022-11-02 13:32 ` Greg Sanders
2022-11-02 19:50 ` Antoine Riard
2022-11-05 2:35 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c13eebc9baf1e347ce3327d5fc34060@yancy.lol \
--to=email@yancy$(echo .)lol \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox