Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-09 📝 Original message:On Sat, Jun 8, 2019 at ...

📅 Original date posted:2019-06-09
📝 Original message:On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <rusty at rustcorp.com.au> wrote:

> "Russell O'Connor" <roconnor at blockstream.io> writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190609/e1605c53/attachment.html>;