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 5D875FF1 for ; Mon, 12 Feb 2018 22:58:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148109.authsmtp.co.uk (outmail148109.authsmtp.co.uk [62.13.148.109]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14BD3D0 for ; Mon, 12 Feb 2018 22:58:35 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w1CMwXg4039417; Mon, 12 Feb 2018 22:58:33 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w1CMwUbi099131 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Feb 2018 22:58:31 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id DA1F540110; Mon, 12 Feb 2018 22:58:29 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 132BF20630; Mon, 12 Feb 2018 17:58:28 -0500 (EST) Date: Mon, 12 Feb 2018 17:58:28 -0500 From: Peter Todd To: "Russell O'Connor" , Bitcoin Protocol Discussion Message-ID: <20180212225828.GB8551@fedora-23-dvm> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 3f228c0b-1048-11e8-9f3b-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwAUHlAWAgsB Am4bWVZeVVV7WmI7 bghPaBtcak9QXgdq T0pMXVMcUwQbfFtk VEceWxBzdAQIeXZ0 YEIsXSZZXkwpdRRg Q05QHXAHZDJodWlJ UxJFflAGdgZOLE1H b1B7GhFYa3VsNCMk FAgyOXU9MCtqYB5Y XAAWLE4TR0lDNB8E D0lYQH0VN2NNXyI3 Lhc3bDYn X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 22:58:37 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 12, 2018 at 10:52:30AM -0500, 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. >=20 > The current policy can be problematic. As noted earlier by Rhavar, > sometimes one's transaction becomes pinned making it infeasible to fee bu= mp > with RBF. This happens when one makes a normal payment to a large > commercial service, and, while the transaction remains unconfirmed, the > commercial service creates a low-fee-rate sweep of one's payment, among a > collection of others. If one wants to RBF this original payment, for > example to get confirmation of the change output for use in further > transactions, the current BIP 125 rules require that you make a fee bump > that exceeds the combined total fees of the original transaction and the > low-fee-rate sweep of the commercial service. >=20 > 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 > original transaction. BIP 125 was defined back in 2015, when perhaps > rational miners did care about absolute fee amounts. However, today we are > in an era where rational miners care about fee-rates more than absolute > fees. 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. Today, a rational miner will prefer a fee-bumped version of > original transaction without consideration of the low-fee sweep transacti= on > (or at least discounting the low-fee sweep in proportion to the miner's > hash-rate fraction). I don't actually see where the problem is here. First of all, suppose we ha= ve a transaction T_a that already pays Alice with a feerate sufficiently high th= at we expect it to get mined in the near future. If we want to pay Bob, we can= do that by simply creating a double-spend of T_a that pays both Bob and Alice, T_{ab}. BIP125 only requires that double-spend to have an absolute fee high= er than the minimum relay feerate * size of the transaction. I just checked one of my nodes, and the absolute minimum relay fee is about 1/5th that of what estimatefee returns for the longest possible estimate, 48 blocks. Depends on the exact circumstances, but it'll likely be worth it to= pay Bob with a replacement of T_a rather than create a second transaction due to that difference. Secondly, if for some reason you need to broadcast a separate transaction paying Bob before you do the replacement, again I don't see an issue: just = make a minimum fee T_b that pays Bob, and replace both with T_{ab}. Again, the b= ig difference between minimum fee and what you might actually pay in fees means that you'll still save money in most cases, so long as your wallet is intelligent enough to pick a low feerate for T_b. > Let me quote the five rules that define the current BIP 125 policy: >=20 > One or more transactions currently in the mempool (original transactions) > > will be replaced by a new transaction (replacement transaction) that sp= ends > > 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 that did not previously appear in the mempool. (Unconfirmed i= nputs > > are inputs spending outputs from currently unconfirmed transactions.) > > 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. For e= xample, > > if the minimum relay fee is 1 satoshi/byte and the replacement trans= action > > is 500 bytes total, then the replacement must pay a fee at least 500 > > satoshis higher than the sum of the originals. > > 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. > > > > To address the new reality of rational miners' consideration, I propose > changing rules 3 and 4 to something like the following. >=20 > 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 transactio= ns > that begins with the root of the original transaction set. I think what you mean here should be the effective fee rate of the maximum feerate package that can be built from the set of transactions that begins = with the candidate replacement. But actually calculating this is I believe non-trivial, which is why I didn't implement it this way when RBF was first implemented. > 4'. The replacement transaction must also pay for replacing the original > transactions at or above the rate set by the node's minimum relay fee > setting. For example, if the minimum relay fee is 1 satoshi/byte and the > replacement transaction and the original transactions are 1000 bytes tota= l, > then the replacement must pay a fee at least 1000 satoshis higher than the > fee of the root transaction of the original transactions. So the previous version of condition #4 does this implicitly because the absolute fee isn't allowed to go down; you're effectively re-adding this condition. But as I've shown above, you can get the same *behavior* by simp= ly ensuring that the transactions you broadcast that you'll want to double-spe= nd have a minimum feerate in the first place. > Rule 3' is a fancy way of saying that the replacement transaction must ha= ve > a fee rate that is larger than the package fee rate of the root of the set > of transactions it replaces, where the package fee rate is the fee rate > implied by considering CPFP. >=20 > 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 > for the size of the original transactions being evicted, but some people I > chatted with thought it could be important. I think this is very important. For example, without this condition I could= do a DoS attack by repeatedly broadcasting a transaction, then spending the outputs of that transaction with a very large number of child transactions,= all of minimum fee. With up to 100 transactions allowed for consideration, and a 100KB max transaction size, that could be up to ~10MB of transactions. Next I double spend the root, increasing it's feerate but *not* paying for = the child transactions. Those ~10MB are now evicted from the mempool, and I can repeat the cycle again. The cost is whatever the root tx replacement cost, which will be much less than the cost of broadcasting 10MB should have been. > Other people on the mailing list have been thinking about RBF policy for > far longer than I have, so I wouldn't be surprised if my proposal above is > naive. However, I think it can start a conversation about addressing the > problems with the current RBF policy. A better way to solve this class of problems may be diffed tx replacement propagation: basically broadcast a diff between the original tx and the proposed replacement, allowing you to do the minimum bandwidth accounting b= ased on the size of the diff instead. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --K8nIJk4ghYZn606h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqCHBAACgkQJIFAPaXw kfs9QAgAr3A9QSkyLTVEctTkM6ig2lpbjwULXwOjAhk1ujwebKOpNgbCgP+xGCM5 oQ+HhSixpUb8ky6L4T/6bf6P51lim0pbrEUVdnHc4nsxYjh2rCb+hEsFLJOcYrIb 7Ru+GgyyBUC5/OIA+U2OesR8I5BWNluG2vG2d8aNJPzYeoFUCiYxw07Pj4sXuwJn mzQzeKvTRSdVbvbnx8bXdCmyUUPk90NYOxLGd9GS1Zv125T1Wdx7MfYCSUcKeqGR K64fpAoOe67V6MOKH2c1YWSQ7d5Q5yuldUC8zdlQOScwW83axIOJ+TOTKJOC1a8b DebEyGFThzY2SpostB18MlUrFH1f0A== =aknT -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h--