Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdHmG-0007sF-1P for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 10:53:00 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VdHmD-0001Jz-MS for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 10:52:59 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4AqokY025420; Mon, 4 Nov 2013 10:52:50 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 rA4Aqi0W017725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 10:52:46 GMT Date: Mon, 4 Nov 2013 05:52:43 -0500 From: Peter Todd To: John Dillon Message-ID: <20131104105243.GA28805@savin> References: <20131024143043.GA12658@savin> <20131024144358.GA17142@savin> <20131024145447.GA19949@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 3ddf57d0-453f-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUFloCAgsB AmUbWlReVV97XWQ7 bAxPbAVDY01GQQRq WVdMSlVNFUsqcBhw R0ceNRlzcAJEfTBx Y0NqXj5YCBAscEEp QlNQEG5QeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDChdeIik/ Hgl2Mz0vMDFYMCFY RB04ZWAfW0EAGTgy AgsLEzhnAV1NXSgr KxUtJ1sRGlpZcl8/ KV8oUl9dPRgITwNT EgAl X-Authentic-SMTP: 61633532353630.1023: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 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VdHmD-0001Jz-MS Cc: Bitcoin Dev Subject: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-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: Mon, 04 Nov 2013 10:53:00 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 28, 2013 at 07:17:50AM +0000, John Dillon wrote: > This discussion seems to be a lot of hot air over a simple observation th= at > estimates are imperfect and always will be. I do not understand you vehem= ent > opposition the notion that a backup is a good thing except in the context= that > replacement to change fees is halfway to profit-seeking replacement by fe= e. >=20 >=20 > Peter Todd: >=20 > You did a fair bit of leg work for replace-by-fee. Seems to me that > replace-for-fee will help prep infrastructure to eventual replace-by-fee = usage, > while avoiding some of the politics around zero-conf transactions. Here's the easy part done: https://github.com/petertodd/bitcoin/tree/replace-for-fee The rules are pretty simple: a replacement can only happen if every output in the old transaction has a corresponding output in the new with the same scriptPubKey, and of equal or greater value. All old tx outputs must also be unspent. For implementation reasons, the order of the outputs must also be the same, and the code will never replace two transactions with one. If someone wanted to mine with the above code, I'd say go right ahead. (modulo general testing concerns) Client-side though it shows a flaw with the Bitcoin wallet code that I should have realized months ago: essentially a transaction in your wallet with double-spent inputs forever blocks those inputs from being spent. This doesn't happen too often because you're wallet will currently never create double-spends, and will never respend unconfirmed coins from someone else, but any CoinJoin implementation violates that assumption and an attacker could easily cause a lot of havok. I'll have to think about the issue further, but essentially the wallet needs to recognize when a transaction's inputs no longer exist, and mark the remaining inputs as unspent. Actually deleting those transactions =66rom your wallet is secondary to that more important concern. --=20 'peter'[:-1]@petertodd.org 000000002fdfe6bbcffea72c934475cd4fcfe78d8d06910016d707c9b4a9e827 --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJSd3x7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwOWY0OTEzMzg1ZjY5OTYwZWU5YmUwMjMyNTkwZDBmMDljZmJlNjEzM2Rm NDVlNjMwNjg3ZjAxNGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv5lAgAkg/5E3Frl5Db3tNz/eWyq1lv Zc5qMId1k604DbMRerHD9TqgSdQ+Vaz2Rj+HVyBasfXh2iG23tv7HeN2OTndfpcS GVA6nfPWUewX8qIZmdCJxS+6S5NxwMGxJPdzY+HTxquq/VkaygvLJLFSQCPFyLzl oaSCSpypM/KlHoFHpflJmQB0dx/tRdbcgTIxE5YdV/Zz7ei46bJkeccQJtyth3hC gCxqiKrzHR024oNUUj3SzWYhcuzm05Hzyzb3Ah7RRd/NCxs+tmr5zO0eFqJ9V4S8 XshzUHb3rvi7OpXcRHdm8tYVkzjhh5V8DerQ5Mw/fq1KQnZfKN82k6JQxeiAew== =jqWt -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--