From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 556AAD73 for ; Mon, 3 Jun 2019 09:48:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60F5AA3 for ; Mon, 3 Jun 2019 09:48:38 +0000 (UTC) Received: from [69.59.18.158] (unknown [69.59.18.155]) by mail.bluematt.me (Postfix) with ESMTPSA id B32E3185542; Mon, 3 Jun 2019 09:48:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Matt Corallo X-Mailer: iPhone Mail (16F203) In-Reply-To: <871s0c1tvg.fsf@rustcorp.com.au> Date: Mon, 3 Jun 2019 11:48:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871s0c1tvg.fsf@rustcorp.com.au> To: Rusty Russell X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE 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: Mon, 03 Jun 2019 15:10:25 +0000 Cc: Bitcoin Dev 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: Mon, 03 Jun 2019 09:48:39 -0000 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 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.