public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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 [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125) 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.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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