Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

["Russell O'Connor" <roconnor@blockstream.io>]

[-- 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 --]