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 52903ECB for ; Mon, 12 Feb 2018 23:42:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com [62.13.149.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85A89165 for ; Mon, 12 Feb 2018 23:42:31 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w1CNgTfj062215; Mon, 12 Feb 2018 23:42:29 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 w1CNgRQS075573 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Feb 2018 23:42:28 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 1E59940110; Mon, 12 Feb 2018 23:42:27 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 3290F20630; Mon, 12 Feb 2018 18:42:25 -0500 (EST) Date: Mon, 12 Feb 2018 18:42:25 -0500 From: Peter Todd To: "Russell O'Connor" Message-ID: <20180212234225.GA9131@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 62f2464f-104e-11e8-8106-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwAUHlAWAgsB Am4bWVdeVF97W2s7 bghPaBtcak9QXgdq T0pMXVMcUwQbf0tj Z30eVRx3cAYIcH53 ZwhkXCZZWEJ+I1t8 QkoBCGwHMG99YGEf Vl1YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z GA41ejw8IwAXEilL QxoMMVMUTg4hPwZ0 HkpfVQ8FMwUdQCEy JA1gQiN4 X-Authentic-SMTP: 61633532353630.1038: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 Cc: Bitcoin Protocol Discussion 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 23:42:32 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: >=20 > > > > I don't actually see where the problem is here. First of all, suppose we > > have a > > transaction T_a that already pays Alice with a feerate sufficiently high > > that > > 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 Al= ice, > > T_{ab}. BIP125 only requires that double-spend to have an absolute fee > > higher > > than the minimum relay feerate * size of the transaction. > > >=20 > The problem is that rule 3 of BIP 125 requires you pay a fee that is high= er > than the the fee of T_a *plus* the fee of the sweep-transaction that the > Alice has added as a unconfirmed child transaction to T_a because > double-spending to pay Alice and Bob invalidates Alice's > sweep-transaction. Alice's sweep-transaction is very large, and hence pa= ys > a large absolute fee even though her fee-rate is very low. We do not have > any control over its value, hence Alice has "pinned" our RBF transaction. Ah ok, I misunderstood and didn't realise you were talking about the case w= here Alice re-spends her unconfirmed payment. Unfortunately I don't think that c= ase is possible to solve without putting some kind of restriction on spending unconfirmed outputs; with a restriction it's fairly simple to solve. > > I think what you mean here should be the effective fee rate of the maxi= mum > > feerate package that can be built from the set of transactions that beg= ins > > 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 f= irst > > implemented. > > >=20 > Yes, that is what I mean. My proposal was off-the-mark. >=20 > Surely CPFP is already computing the package-fee rates of mempool > transactions. That is the value we need to compute. True, maybe we can just reuse the CPFP calculation now. That said, AFAIK th= at's only done in the miner code, not the mempool, so that may not be trivial to actually do. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqCJl0ACgkQJIFAPaXw kfsZjggAjXkZVdlnC9GSKOyTixz0f4qROGpCZ7IMF3O+Nb0x+LSlj0vZAnu+k5oZ 7cTkzed3MXVdmfKPw463PMPh2uhp8D1oLatgLk+PkRtsTkoNphDARoJAFpJXHKSV gRYRKLjhLZXZt4Hu+ZLJI8Gifm9tjevaNw3yUKFGaZC1BWF8gFxYaSYtWT/IalsU rlElk+VASwwKg0bXTxVp9K4dbY+3l/skfzcTpQ4u+bniPwQmkSzr2KHlMTkWj6jk 1v5myMdcQ2/dP485551kjGwoURqiXDUo1DEH59Bf+pRU553QTYrysjInxQqYG0TT D4/ZdrjPoG9JWRXoiSBaXoVy3wtU6Q== =/I+S -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--