Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.108 as permitted sender)
	client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
	helo=outmail148108.authsmtp.net; 
Date: Wed, 29 Oct 2014 16:08:48 -0400
From: Peter Todd <pete@petertodd.org>
To: Alex Morcos <morcos@gmail.com>
Message-ID: <20141029200848.GA3458@savin.petertodd.org>
References: <CAPWm=eXxs=AfFhaT2EeGFsR+2r96WcaOeWL_Z59-6LixH+=4AQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <CAPWm=eXxs=AfFhaT2EeGFsR+2r96WcaOeWL_Z59-6LixH+=4AQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Reworking the policy estimation code (fee
 estimates)
Precedence: list


--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 27, 2014 at 03:33:45PM -0400, Alex Morcos wrote:
> I've been playing around with the code for estimating fees and found a few
> issues with the existing code.   I think this will address several
> observations that the estimates returned by the existing code appear to be
> too high.  For instance see @cozz in Issue 4866
> <https://github.com/bitcoin/bitcoin/issues/4866>.

I don't have time to look at the details of your statistical methods
unfortunately due to some deadlines, but a quick comment:

You should think about the malleability of your estimates to attackers.
For instance the current fee estimation code has a serious issue where
it'll happily estimate ludicriously high fees based on very little date.
There is a 'insane fees' failsafe, but it's IIRC set to allow
transactions with fees of less than 100mBTC/tx, roughly $50 at current
exchange rates. It's relatively easy to get a wallet into a condition
where this happens as the estimations are considered valid even based on
very little data - a simple sybil attack suffices. (e.g. the recently
published paper(1) on Tor sybil attacks comes to mind as one example of
many ways to do this) Obviously this could empty someone's wallet pretty
quickly; an exchange that makes a few dozen transactions an hour could
easily lose tens of thousands of dollars due to this exploit. Someone
correct me if I'm wrong, but last I checked in git HEAD this exploit is
still unfixed.

A user-configurable failsafe limit is a pretty obvious solution here,
albeit a crude one; it'd be interesting to see if a plausible security
argument could be made for something more sophisticated, like taking
into account coin-age of observed transactions that estimates are based
on.

1) "Bitcoin over Tor isn't a good idea",
   http://arxiv.org/abs/1410.6079

--=20
'peter'[:-1]@petertodd.org
0000000000000000098d3c9095b47ff1fd692fef5ac6731340802c7c63d38bb0

--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQGrBAEBCACVBQJUUUlNXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxZGM5NzRlNjc4YTdjYjY1ZDU1ZTIzNmFlYzQ5MzM3ZjRl
ZWIyOGU2ZWU5ODIxOGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv//wf/QxtLEzTYc7AiwB8Km0InHqv3
ZEaMmEIjVHBC8eagecvTKP8Jhs/S10Sy0xqU+bNzp1GE7rwxnawKJuSFXqhE98EV
UHn4rO8DxReyqbOlpoqmixmAPkwHc92mw8tsCnpqZaFBohypT5Df9mXZghgfIXB6
lsA4y0cRgxZz+JKCCzcoOgkpHt9xdjc26Wj9nl17L+F49aZt3hVV9CwrU0zSN0JZ
S93ZW4IR2Q+kJ3Xox7CDoLkd6ZcUJ3qt2/PZHP1UF2j3h8vLc480E/QHjZxurC5L
Izr37FY/2y9bHKhBpkLoQC8LlKnUgnEgauAFpqYacUMga+lj8M04UxkdoU4x5A==
=zeWG
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--