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; 
Date: Tue, 12 Mar 2013 05:47:00 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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)
Subject: [Bitcoin-development] Changing the fee on already sent transactions
Precedence: list


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