Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.110 as permitted sender)
	client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
	helo=outmail148110.authsmtp.com; 
Date: Mon, 8 Jun 2015 17:33:36 -0400
From: Peter Todd <pete@petertodd.org>
To: "Raystonn ." <raystonn@hotmail.com>
Message-ID: <20150608213336.GA19826@muck>
References: <5574E39C.3090904@thinlink.com>
	<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
	<AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
	<COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X"
Content-Disposition: inline
In-Reply-To: <COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	"Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle.ac.uk>
Subject: Re: [Bitcoin-development] New attack identified and potential
 solution	described: Dropped-transaction spam attack against the block	size
 limit
Precedence: list


--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > there is no memory pool cap currently
>=20
> Real hardware does not have an infinite amount of RAM.  Memory pool sizes=
=20
> cannot grow unbounded.  Some transactions with insufficient fees do get=
=20
> dropped today after many hours.

Actually they don't, which is an unfortunate problem with the existing
mempool implementation; the only way a transaction can be removed from a
Bitcoin Core mempool is through it getting mined, double-spent, or the
node restarting.

The protection that we have against that attack is that you need access
to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
consumed, and furthermore, actually getting that many transactions to
propagate over the network is non-trivial. (no, I'm not going to tell
you how)

The obvious solution is to cap the size of the mempool and evict
transactions lowest fee/KB first, but if you do that they you (further)
break zeroconf security. On the other hand, if you don't break zeroconf
security an attacker can prevent reasonable fee transactions from
propagating.

I probably should get around to fixing this...

--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVdgotXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxJaAf8DPd+WNieLQpzKNN/W2FgWCAO
dM0oUlUZ3enB8y7w64pnz/ICrcyPlJD2lcPQWrAJ7WKbZpMvg2vCD2X/IOWl4GIy
yIZ+xdRhw393032ox0g5c0aP/g5ll/kmR6Au9H3zZWKflrUrEdjMad/GE8112pEs
J9rQeiG295VebhakgdezUavJkQRP9l0lEhKx6bbk+Br4xPoDuE3q24QT72qBR+1p
hoTrerW+k4ddbEV/qhrpmR2QlRV9J6H7nqFv5GA7m/9qD+AHX3Rr/Ie/Hy5GKAx+
eewH7YFcH6J+saFpb6cWROWY4r85ElpHNFR0WG9TGpqZggaia4bF/IRmyhQWDg==
=gb4z
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--