On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <ru...@rustcorp.com.au> wrote:
> "Russell O'Connor" <rocon...@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.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
