Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2A6AD723 for ; Sun, 9 Jun 2019 04:21:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 237A7174 for ; Sun, 9 Jun 2019 04:21:30 +0000 (UTC) Received: by mail-it1-f171.google.com with SMTP id i21so8550382ita.5 for ; Sat, 08 Jun 2019 21:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OnCRByJYXa3+QAsPibJiTmHRr0Nwdy/eyPgbNVUgQJ0=; b=qCoOZb+vETsPgKV7PeZIB7mBY3+jhJbudry3k/I+h+PRdfa+pIuKmhxY01HqjGsabK uB/96AZTTeqxz/OTNttsJR4PgJjaYgTQMKCeVseXrKmculIPPjwNlPq0PLAseQlW7R4I Vm4/deKBE30M7BAu6TXK4/ordvRXZIzCGf7eo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OnCRByJYXa3+QAsPibJiTmHRr0Nwdy/eyPgbNVUgQJ0=; b=h2uG71cYnoPqtof/o0wd0diIYh0fHxiOn8CdlTamksfzPl7/EYSCYDzyfyw9P5J303 zjNCOyBqYMF/UdvSmSEuXoavHraGX3R1Ihs4FHBHDRqjQ97rsN26Md2GXaOUPXS/wREu iChoC70xA19YutFiOG+LTqk/RT461AZSQ/u+/rdk3g1IU5+Jema1TlNlGOFn4Ww0Ftu3 ed+/6tRrU2aDmyDVFHEdfH1IkHZ/mkERYH0G4sGi1xcDX3cMUnDlHeYaVUNegGqMNRwm foKXdkfbXZ3Gn27arHocmoFpw1wZzgZbzAgmGBkJR2IFAyPb3jr8K7N+Mcxw6GRujGAx I8aA== X-Gm-Message-State: APjAAAUQaKvmWj/Qld+9rYd/7ZHwqnCdbm32Dd4lfKBahhBaLmdsF06p E4Ab3Bw8KRzOZBOG1Rlplx8k0LmWxxiioKDUkEbrLtxwEfk= X-Google-Smtp-Source: APXvYqyW/cc+h4eRa30tdv2qkuJIfVw5bHS5KjQxQdBBamTshgH0XKOpZUho43NV29szmp1wcx2av5vcoQLBFYtizcM= X-Received: by 2002:a24:4344:: with SMTP id s65mr9496669itb.137.1560054090198; Sat, 08 Jun 2019 21:21:30 -0700 (PDT) MIME-Version: 1.0 References: <871s0c1tvg.fsf@rustcorp.com.au> <87r287o1fh.fsf@rustcorp.com.au> In-Reply-To: <87r287o1fh.fsf@rustcorp.com.au> From: "Russell O'Connor" Date: Sun, 9 Jun 2019 00:21:19 -0400 Message-ID: To: Rusty Russell Content-Type: multipart/alternative; boundary="000000000000e08eb0058adc65e5" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 09 Jun 2019 08:18:41 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 04:21:32 -0000 --000000000000e08eb0058adc65e5 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell wrote: > "Russell O'Connor" 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


=
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:
>>
>>=C2=A0 6. If the original transaction was not in the first 4,000,00= 0 weight
>>=C2=A0 =C2=A0 =C2=A0units of the fee-ordered mempool and the replac= ement transaction is,
>>=C2=A0 =C2=A0 =C2=A0rules 3, 4 and 5 do not apply.
>>
>> This means:
>>
>> 3. This proposal does not open any significant new ability to RBF = spam,
>>=C2=A0 =C2=A0 since it can (usually) only be used once.=C2=A0 IIUC = bitcoind won't
>>=C2=A0 =C2=A0 accept more that 100 descendents of an unconfirmed tx= anyway.
>>
>
> Is it not possible for Alice to grief Bob's node by alternating RB= Fing 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 weig= ht,
> and then repeating with the other transaction?=C2=A0 It might be possi= ble to
> amend this proposal to partially mitigate this.

Good point.=C2=A0 This will cost Alice approximately one tx every block, bu= t
that may still be annoying.=C2=A0 My intuition says it's hard to play t= hese
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,=C2=A0 "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...." might adequately addres= s the issue.
There are probably other ways as well.
--000000000000e08eb0058adc65e5--