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 82D85265 for ; Mon, 3 Jun 2019 01:49:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 91F7F19B for ; Mon, 3 Jun 2019 01:49:21 +0000 (UTC) Date: Mon, 03 Jun 2019 01:49:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1559526559; bh=UkN/hNoBQByCCL+FcX17pum9++xW4iF1yh5zQ2Ojroc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=iEVl6HRIU7t068oqjOgV+C8z6ZaBYVi7I14zTZhZYKSwnf5i7OiDtQgd1Qf+xQeez wJjd+6vPmtnm4RxMpbNBRJ/wGT+ltb+wzEXd5IgVZ6mFBAasLTPZ4GG3G0yp75Kc18 aATDle1OcaHiTiXKyNJ/NQgxoNHLG3UNLRI6hKQw= To: Rusty Russell , Bitcoin Protocol Discussion From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: In-Reply-To: <871s0c1tvg.fsf@rustcorp.com.au> References: <871s0c1tvg.fsf@rustcorp.com.au> Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW 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:33 +0000 Cc: Matt Corallo 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 01:49:22 -0000 +1 >From an incentive-compatible point of view, miners should be accepting tran= sactions that increase the amount of fees that can achieved with 4M weight = of transactions, so it seems like a pretty sane plan. One common problem I've run into with RBF is since you're using RBF you pro= bably want to low ball fees. With good coin selection (*cough* coinsayer.co= m *cough*), it'll use that opportunity to consolidate inputs. But now let's= say fees suddenly spike (pretty common), you might want to fee bump your n= ow stuck transaction. But now that fees are high, it doesn't make sense to = be consolidating so ideally you'd just replace it with a much smaller trans= action (that pays higher fee rate). So if anything, I think your proposal doesn't go far enough. I think even i= n "non-emergency" cases, we could get away with removing the requirement to= increase the absolute fee (as long as the fee rate is increased); which al= so makes it incentive compatible if you assume a reasonable fee-market. I realize it does open potential DoS vectors, but they seem reasonably smal= l. -Ryan =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, June 1, 2019 9:41 PM, Rusty Russell via bitcoin-dev wrote: > Hi all, > > I want to propose a modification to rules 3, 4 and 5 of BIP 125: > > To remind you of BIP 125: > 3. The replacement transaction pays an absolute fee of at least the sum > paid by the original transactions. > > 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. > > 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. > > 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: > > 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"). > > 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. > > 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. > > 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. > > Unfortunately I haven't found time to code this up in bitcoin, but if > there's positive response I can try. > > Thanks for reading! > Rusty. > > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev