From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFLoA-0008Cc-RM for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 09:47:46 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.78 as permitted sender) client-ip=62.13.149.78; envelope-from=pete@petertodd.org; helo=outmail149078.authsmtp.net; Received: from outmail149078.authsmtp.net ([62.13.149.78]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFLo8-0004e0-Fo for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 09:47:46 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r2C9lbjD093802 for ; Tue, 12 Mar 2013 09:47:37 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r2C9lUd8047432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 12 Mar 2013 09:47:32 GMT Date: Tue, 12 Mar 2013 05:47:00 -0400 From: Peter Todd To: Bitcoin Dev Message-ID: <20130312094700.GA8130@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: dd020541-8af9-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1 LRkLXVBSFQZ4ARUL AhkUURo8cANYeX5u ZEFqQHFbVVt/fUFi QwAWFx4POQI0YGAb V0RbdU1ScQVCMEsR alJ/UXcMfG1WMHN9 RlY+ZXU7ZG1VbXwN GFxcdQlJHhsGRCgX RxkEEjQpEgUZRyh7 IRErYlkaVE8VKEg7 PUppQl8eL1cOEARY BEhGHC5eIUJp X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1UFLo8-0004e0-Fo Subject: [Bitcoin-development] Changing the fee on already sent transactions 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: Tue, 12 Mar 2013 09:47:47 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We can allow for transaction replacement for the purpose of adding fees to existing transactions safely, and while not increasing the risk of double-spends by taking advantage of the stubbed out replacement code. Specifically the replacement code allows for the replacement of a transaction if a transaction spending the tx that is being replaced is not in the mempool. Specifically: 664 // Check for conflicts with in-memory transactions 665 CTransaction* ptxOld =3D NULL; 666 for (unsigned int i =3D 0; i < tx.vin.size(); i++) 667 { 668 COutPoint outpoint =3D tx.vin[i].prevout; 669 if (mapNextTx.count(outpoint)){ Followed by the actual replacement logic. We could change this logic to instead evaluate if the candidate replacement does not remove or decrease the value of any existing outputs. Adding outputs is ok. Changing the set of inputs is also ok, provided that there are no conflicts with other spent transactions. DoS attacks would be prevented by only forwarding/accepting into the mempool replacements that increase the fees paid by at least MIN_RELAY_TX_FEE * size - essentially the same decision to allow the broadcast of the transaction in the first place. Because a transaction can not be replaced if another transaction already depends on it the change would not increse double-spend risks for unconfirmed transactions. Along with this change code can be added to clients to examine the mempool and recent blocks to determine what fee would be required to get a transaction confirmed in what time. Of course, considering our recent "fun" last night, I'll be the first to admit that this change needs a lot of testing and careful thought. However the ability to increase fees on already broadcast transactions would be very valuable to users as competition for blockchain space increases. --=20 'peter'[:-1]@petertodd.org --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRPvmTAAoJEH+rEUJn5PoEJpYH/3ekZmzdKeOPhbbJrZK4MVSJ SYlt7XW2Q7uK/K5F/gNE3Wog/SUhSK3Q2soLZc3CvY96rGNfHr1mwPDhwMz0z1Wj yRPseU0u4ZnfZqHj3Dr8rjvEicDN3CtmvH+ptKmmpXdWpWDmZICsM/Uh/vWSo2nq 9AlZLvNryIC/ji4+rWBLGjyvCiZCowmU/LsVKcbGNhsrWA3aJLWSqubXAfRn2fCd GqBAkD1EhN/CN3Rp9XPlfXWG1wLBlSlFIk29gSXoWL0g39i7hdIm/2jOhIUY6sB1 mYg5PEpuopNVFoH3XLiHD6TO4hojz3eEMyQy7/YLL2Jpy2rcF6NMhXPMk1ZM3zQ= =CjfM -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--