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 A6CB3F54 for ; Mon, 12 Feb 2018 17:30:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A93A02F6 for ; Mon, 12 Feb 2018 17:30:10 +0000 (UTC) Date: Mon, 12 Feb 2018 12:30:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1518456606; bh=+2bhF6vxNszyKB154cOLocXMwD574KoV0K6jz0LB6DA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=yCNrpu3iDzr27RuHvOCyTi3UsHDTrXbeDc/T59TGu/qCLHcSV7A9wUy4tYyOVmm+P aW8PsxkOMjv8u6VGo9qPnVJvwyWga1fZcheeyT/pOD/rdNvPmqUk21l67WLBnZbGmy ZAA0thSW8F0i/tfocOdnV8tXgE1wl7slkngqZSso= To: Russell O'Connor From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: <7zJRAGZXWFiiXu-S3UliZqtP1crDG6s8MDEOurJrXXJc0BkZxw8o0zcGh7DthtvczMxoQHKZ6PwQsZJ0s403noMah26S2xAdGBX2NNL1OfI=@protonmail.com> In-Reply-To: References: 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, 12 Feb 2018 17:39:42 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy. 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, 12 Feb 2018 17:30:12 -0000 Thank you very much for writing this up.=C2=A0 It's worth noting that there= can be multiple roots for the transactions that are getting replaced. So for rule 3, you probably want a feeRate >=3D the max "package fee rate" = of all replaced roots. I am very happy with this proposal in general, as it's clearly a step in th= e right direction for making transaction replacement practically usable for= todays services. However, I think your new rule 4 is a bit weak. The logical extension of yo= ur proposal would be to allow a transaction (say B) be able to replace tran= sactions (say A) by purely paying a higher fee rate, /even if it's less abs= olute fee/. In this simple example of B replacing A -- B should pay at leas= t: (a.FeeRate * b.size) + relayFeeRate*(a.size + b.size) =E2=80=8B-Ryan =E2=80=8B -------- Original Message -------- On February 12, 2018 10:52 AM, Russell O'Connor via bitcoin-dev wrote: >I think it is worth revisiting BIP 125's replace-by-fee policy for when to= replace transactions. >The current policy can be problematic. As noted earlier by Rhavar, sometim= es one's transaction becomes pinned making it infeasible to fee bump with R= BF.=C2=A0 This happens when one makes a normal payment to a large commercia= l service, and, while the transaction remains unconfirmed, the commercial s= ervice creates a low-fee-rate sweep of one's payment, among a collection of= others.=C2=A0 If one wants to RBF this original payment, for example to ge= t confirmation of the change output for use in further transactions, the cu= rrent BIP 125 rules require that you make a fee bump that exceeds the combi= ned total fees of the original transaction and the low-fee-rate sweep of th= e commercial service. > >The problem is that, while the fee rate of the sweep is low, the absolute = size of the fee can still be large, making it infeasible to RBF the origina= l transaction.=C2=A0 BIP 125 was defined back in 2015, when perhaps rationa= l miners did care about absolute fee amounts. However, today we are in an e= ra where rational miners care about fee-rates more than absolute fees.= =C2=A0 The fee-rate of the large sweep transaction is low enough that we do= not expect that miners will be mining it in the same block as the original= transaction.=C2=A0 Today, a rational miner will prefer a fee-bumped versio= n of original transaction without consideration of the low-fee sweep transa= ction (or at least discounting the low-fee sweep in proportion to the miner= 's hash-rate fraction). > >Let me quote the five rules that define the current BIP 125 policy: > >> >>One or more transactions currently in the mempool (original >>transactions) will be replaced by a new transaction (replacement >>transaction) that spends one or more of the same inputs if, >> >> >>1. The original transactions signal replaceability explicitly or through = inheritance as described in the above Summary section. >> >>2. The >> replacement transaction does not contain any new unconfirmed inputs=20 >>that did not previously appear in the mempool. (Unconfirmed inputs are=20 >>inputs spending outputs from currently unconfirmed transactions.) >> >>3. The replacement transaction pays an absolute fee of at least the sum p= aid 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. For example, if= =20 >>the minimum relay fee is 1 satoshi/byte and the replacement transaction= =20 >>is 500 bytes total, then the replacement must pay a fee at least 500=20 >>satoshis higher than the sum of the originals. >> >>5. The number of=20 >>original transactions to be replaced and their descendant transactions=20 >>which will be evicted from the mempool must not exceed a total of 100=20 >>transactions. >> >>To address the new reality of rational miners' consideration, I propose c= hanging rules 3 and 4 to something like the following. >3'. The replacement transaction pays a fee rate of at least the effective = fee rate of any chain of transactions from the set of original transactions= that begins with the root of the original transaction set. > >4'. The > replacement transaction must also pay for replacing the original transact= ions at or above > the rate set by the node's minimum relay fee setting. For example, if=20 >the minimum relay fee is 1 satoshi/byte and the replacement transaction an= d the original transactions are 1000 bytes total, then the replacement must= pay a fee at least 1000=20 >satoshis higher than the fee of the root transaction of the original trans= actions. >Rule 3' is a fancy way of saying that the replacement transaction must hav= e a fee rate that is larger than the package fee rate of the root of the se= t of transactions it replaces, where the package fee rate is the fee rate i= mplied by considering CPFP. >Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks= from churning the mempool. I don't know if it is really necessary to pay f= or the size of the original transactions being evicted, but some people I c= hatted with thought it could be important. > >Other people on the mailing list have been thinking about RBF policy for f= ar longer than I have, so I wouldn't be surprised if my proposal above is n= aive.=C2=A0 However, I think it can start a conversation about addressing t= he problems with the current RBF policy. >