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; 
Date: Mon, 4 Nov 2013 05:52:43 -0500
From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20131104105243.GA28805@savin>
References: <20131024143043.GA12658@savin>
	<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
	<20131024144358.GA17142@savin>
	<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
	<20131024145447.GA19949@savin>
	<CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
	<op.w5h2rwhcyldrnw@laptop-air>
	<CABsx9T0nc-TO1_=n47UnYHiWKSNvci9Xyhni9PQa=DRo1B7FDg@mail.gmail.com>
	<CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline
In-Reply-To: <CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
Precedence: list


--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--