MIME-Version: 1.0
References: <871s0c1tvg.fsf@rustcorp.com.au>
	<CAMZUoKmXTONMqJ=0Vv7+e=q0CBL5h6Tio-5ec0bmZ+U4psOmCg@mail.gmail.com>
	<87r287o1fh.fsf@rustcorp.com.au>
In-Reply-To: <87r287o1fh.fsf@rustcorp.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 9 Jun 2019 00:21:19 -0400
Message-ID: <CAMZUoKmPAEYwCtiZ90cwiHz7C=WxaTouEy8dJwWC=Tkn5k-_PA@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary="000000000000e08eb0058adc65e5"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
Precedence: list

--000000000000e08eb0058adc65e5
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000e08eb0058adc65e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 8, 2019 at 11:59 PM Rusty=
 Russell &lt;<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
&quot;Russell O&#39;Connor&quot; &lt;<a href=3D"mailto:roconnor@blockstream=
.io" target=3D"_blank">roconnor@blockstream.io</a>&gt; writes:<br>
&gt; Hi Rusty,<br>
&gt;<br>
&gt; On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; The new &quot;emergency RBF&quot; rule:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 6. If the original transaction was not in the first 4,000,00=
0 weight<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0units of the fee-ordered mempool and the replac=
ement transaction is,<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0rules 3, 4 and 5 do not apply.<br>
&gt;&gt;<br>
&gt;&gt; This means:<br>
&gt;&gt;<br>
&gt;&gt; 3. This proposal does not open any significant new ability to RBF =
spam,<br>
&gt;&gt;=C2=A0 =C2=A0 since it can (usually) only be used once.=C2=A0 IIUC =
bitcoind won&#39;t<br>
&gt;&gt;=C2=A0 =C2=A0 accept more that 100 descendents of an unconfirmed tx=
 anyway.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Is it not possible for Alice to grief Bob&#39;s node by alternating RB=
Fing two<br>
&gt; transactions, each one placing itself at the bottom of Bob&#39;s top 4=
,000,000<br>
&gt; weight mempool which pushes the other one below the top 4,000,000 weig=
ht,<br>
&gt; and then repeating with the other transaction?=C2=A0 It might be possi=
ble to<br>
&gt; amend this proposal to partially mitigate this.<br>
<br>
Good point.=C2=A0 This will cost Alice approximately one tx every block, bu=
t<br>
that may still be annoying.=C2=A0 My intuition says it&#39;s hard to play t=
hese<br>
games across swathes of non-direct peers, since mempools are in constant<br=
>
flux and propagation is a bit random.<br>
<br>
What mitigations were you thinking?<br></blockquote><div><br></div><div>For=
 example,=C2=A0 &quot;If the original transaction was not in the first 4,00=
0,000 weight units of the fee-ordered mempool and the replacement transacti=
on is in the first 2,000,000 weight units....&quot; might adequately addres=
s the issue.</div><div>There are probably other ways as well.</div></div></=
div>

--000000000000e08eb0058adc65e5--