From: "Russell O'Connor" <roconnor@blockstream•io>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
Date: Sun, 9 Jun 2019 00:21:19 -0400 [thread overview]
Message-ID: <CAMZUoKmPAEYwCtiZ90cwiHz7C=WxaTouEy8dJwWC=Tkn5k-_PA@mail.gmail.com> (raw)
In-Reply-To: <87r287o1fh.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <rusty@rustcorp•com.au> wrote:
> "Russell O'Connor" <roconnor@blockstream•io> writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >> 6. If the original transaction was not in the first 4,000,000 weight
> >> units of the fee-ordered mempool and the replacement transaction is,
> >> rules 3, 4 and 5 do not apply.
> >>
> >> This means:
> >>
> >> 3. This proposal does not open any significant new ability to RBF spam,
> >> since it can (usually) only be used once. IIUC bitcoind won't
> >> accept more that 100 descendents of an unconfirmed tx anyway.
> >>
> >
> > Is it not possible for Alice to grief Bob's node by alternating RBFing
> two
> > transactions, each one placing itself at the bottom of Bob's top
> 4,000,000
> > weight mempool which pushes the other one below the top 4,000,000 weight,
> > and then repeating with the other transaction? It might be possible to
> > amend this proposal to partially mitigate this.
>
> Good point. This will cost Alice approximately one tx every block, but
> that may still be annoying. My intuition says it's hard to play these
> games across swathes of non-direct peers, since mempools are in constant
> flux and propagation is a bit random.
>
> What mitigations were you thinking?
>
For example, "If the original transaction was not in the first 4,000,000
weight units of the fee-ordered mempool and the replacement transaction is
in the first 2,000,000 weight units...." might adequately address the issue.
There are probably other ways as well.
[-- Attachment #2: Type: text/html, Size: 2447 bytes --]
prev parent reply other threads:[~2019-06-09 4:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-02 4:41 Rusty Russell
2019-06-03 1:49 ` rhavar
2019-06-03 9:48 ` Matt Corallo
2019-06-06 5:16 ` Rusty Russell
2019-06-09 14:07 ` David A. Harding
2019-06-10 16:34 ` rhavar
2019-06-14 5:50 ` Rusty Russell
2019-06-03 12:56 ` Russell O'Connor
2019-06-06 3:08 ` Rusty Russell
2019-06-09 4:21 ` Russell O'Connor [this message]
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='CAMZUoKmPAEYwCtiZ90cwiHz7C=WxaTouEy8dJwWC=Tkn5k-_PA@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/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