Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <871s0c1tvg.fsf@rustcorp.com.au>
Date: Mon, 3 Jun 2019 11:48:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F252D824-5BE6-4B03-B59D-D40EAFBAEE84@mattcorallo.com>
References: <871s0c1tvg.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
Precedence: list

I think this needs significantly improved motivation/description. A few area=
s I'd like to see calculated out:

1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-mi=
ner, I'd think no evicted transactions would be allowed to be in the next bl=
ock range. This would probably require some significant additional tracking i=
n today's mempool logic.

2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I thi=
nk we're already not in a great place, but maybe it's worth it or maybe ther=
e is some other way to reduce this cost (intuitively it looks like this prop=
osal could make things very, very, very bad).

3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS a=
ttack, but it may also be the case that is (a) not worse than other fundamen=
tal issues or (b) sufficiently expensive.

4) As I've indicated before, I'm generaly not a fan of such vague protection=
s for time-critical transactions such as payment channel punishment transact=
ions. At a high-level, in this context your counterparty's transactions (not=
 to mention every other transaction in everyone's mempool) are still involve=
d in the decision about whether to accept an RBF, in contrast to previous pr=
oposals, which makes it much harder to reason about. As a specific example, i=
f an attacker exploits mempool policy differences they may cause your concep=
t of "top 4M weight" to be bogus for a subeset of nodes, causing propogation=
 to be limited.

Obviously there is also a ton more client-side knowledge required and comple=
xity to RBF decisions here than other previous, more narrowly-targeted propo=
sals.

(I don't think this one use-case being not optimal should prevent such a pro=
posal, i agree it's quite nice for some other cases).

Matt

> On Jun 2, 2019, at 06:41, Rusty Russell <rusty@rustcorp.com.au> wrote:
>=20
> Hi all,
>=20
>       I want to propose a modification to rules 3, 4 and 5 of BIP 125:
>=20
> To remind you of BIP 125:
> 3. The replacement transaction pays an absolute fee of at least the sum
>   paid by the original transactions.
>=20
> 4. The replacement transaction must also pay for its own bandwidth at
>   or above the rate set by the node's minimum relay fee setting.
>=20
> 5. The number of original transactions to be replaced and their
>   descendant transactions which will be evicted from the mempool must not
>   exceed a total of 100 transactions.
>=20
> The new "emergency RBF" rule:
>=20
> 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.
>=20
> This means:
>=20
> 1. RBF can be used in adversarial conditions, such as lightning
>  unilateral closes where the adversary has another valid transaction
>  and can use it to block yours.  This is a problem when we allow
>  differential fees between the two current lightning transactions
>  (aka "Bring Your Own Fees").
>=20
> 2. RBF can be used without knowing about miner's mempools, or that the
>  above problem is occurring.  One simply gets close to the required
>  maximum height for lightning timeout, and bids to get into the next
>  block.
>=20
> 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.
>=20
> 4. This proposal makes RBF miner-incentive compatible.  Currently the
>  protocol tells miners they shouldn't accept the highest bidding tx
>  for the good of the network.  This conflict is particularly sharp
>  in the case where the replacement tx would be immediately minable,
>  which this proposal addresses.
>=20
> Unfortunately I haven't found time to code this up in bitcoin, but if
> there's positive response I can try.
>=20
> Thanks for reading!
> Rusty.