From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxVna-0002DQ-9e for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 07:30:46 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.154 as permitted sender) client-ip=62.13.148.154; envelope-from=pete@petertodd.org; helo=outmail148154.authsmtp.co.uk; Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YxVnX-0006HG-KX for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 07:30:46 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7Ub2P085033 for ; Wed, 27 May 2015 08:30:37 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7UWDc073975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 27 May 2015 08:30:35 +0100 (BST) Date: Wed, 27 May 2015 03:30:32 -0400 From: Peter Todd To: Bitcoin Dev Message-ID: <20150527073032.GA22286@savin.petertodd.org> References: <20150526051305.GA23502@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20150526051305.GA23502@savin.petertodd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 43fd65f4-0442-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQJ1 LRkAXVBSFQB4ARQL BR4UURw8cABYeX95 e0RnX25aWkVlcE56 XU8aUWlkYgIHHDMf V0NRcAYaeQdJdlFB aQYrUnZbZXgHYn5i WlZqMm10N24OdmEN GltQfAobGBsHF2Eq fR1QVQYFHFEOQCQ1 ahArNFMYG14UP0Mu BBMPWEgDL1opBwBY WnpEDiIRHVQZQyMg AEZQTAswHTA1 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YxVnX-0006HG-KX Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 07:30:46 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote: > Case 1: Increasing the fee on a single tx > ----------------------------------------- >=20 > We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size > with the minimal relay fee, 2.26uBTC. Increasing the fee while > respecting FSS-RBF rules requires the addition of one more txin, with > the change output value increased appropriately, resulting in > transaction t2, size 374 bytes. If the change txout is sufficient for > the fee increase, increasing the fee via CPFP requires a second > 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another > input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total > of 566 bytes. >=20 > Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in > cases where the original transaction didn't have a change > output. To clarify a point raised(1) on the pull-req itself: The replacement transaction is allowed to not only add new txin's, but also replace txins. Suppose t1 is a 2-in-2-out P2PKH using transaction, 374 bytes in size. With CPFP accomplished by a 1-in-1-out tx, 192 bytes, you have 566 bytes total. With FSS RBF if you have an unspent output greater in value than one of the outputs spent by t1, you can replace that output in t1's vin txin set and rebroadcast the transaction, still 374 bytes in size. This gives you a 34% cost savings vs. CPFP. > Case 2: Paying multiple recipients in succession > ------------------------------------------------ >=20 > We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice. > We now need to pay Bob. With plain RBF we'd just add a new outptu and > reduce the value of the change address, a 90% savings. However with FSS > RBF, decreasing the value is not allowed, so we have to add an input. >=20 > If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can > be created, 2*226=3D452 bytes in total. With FSS RBF we can replace t1 > with a 2-in-3-out tx paying both, increasing the value of the change > output appropriately, resulting in 408 bytes transaction saving 10% >=20 > Similar to the above example in the case where the change address of t1 > is insufficient to pay Bob the end result is one less transaction output > in the wallet, defragmenting it. Spending these outputs later on would > require two 148 byte inputs compared to one with RBF, resulting in an > overall savings of 25% Similarly in the multiple recipients case, if sufficiently large outputs are available the additional funds can be obtained by swapping one input for another. For instance if Alice has three outputs, 1.0, 0.5, and 0.2 BTC, and needs to pay Bob 1.1 BTC, she can create t1: 1.0 -> Bob 1.1 0.2 -> Alice 0.1 If she then needs to pay Charlie 0.2 BTC she can doublespend that with: 1.0 -> Bob 1.1 0.5 -> Charlie 0.2 -> Alice 0.2 Note that care does need to be taken to ensure that multiple rounds of this always leave at least one input unchanged. 1) https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-105630255 --=20 'peter'[:-1]@petertodd.org 00000000000000000ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVZXKTXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZWMwYzNhOTBiYWE1MjI4OTE3MTA0NjQ2OWZlNGEyMWRj NWEwZGFjNGNiNzU4YTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft4iwf9EMAb+JGciUEiaTMJYvl1SVVr DeZhhF9xbNOgAjXAYjtDRpzuL5imnWl8wwHcDPJlYkFehEidOz6H40xD3FGsBTL9 9afhSJN4xsyISg3fdIxEKW+LvzkaCD2Goih2ZeLUhXi0Kk+PvMBGh/1u+DSEniBP 1YncM6QzmCJwruwuOfkBGDr7FAju330QMNarmNu2ZrK+qc8WrGhcj1ebYxM/gIYQ +hIaXvnFtQS7MQ9OBtlQy1VpHSPikplmAvyHM6l3heyWgcXRIHMji3PQB8/BXy/k EsJYbb5biVxbAEFqCY6Y87vPJnSodnmfiOMksOaN902x3wY+M0jrrefrkuZOgw== =bOqh -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr--