Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.82 as permitted sender)
	client-ip=62.13.149.82; envelope-from=pete@petertodd.org;
	helo=outmail149082.authsmtp.co.uk; 
Date: Fri, 25 Oct 2013 03:07:08 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20131025070708.GA5760@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
Precedence: list


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

On Fri, Oct 25, 2013 at 06:39:34AM +1000, Gavin Andresen wrote:
> Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
> the answer is "a small percentage."
>=20
> So: there are multiple layers of reasons why OOB fee payments will not
> screw up the fee estimation code:

I've responded to nearly all those arguments elsewhere, but anyway...

> And all of the above is completely orthogonal to child-pays-for-parent
> and/or replace-with-higher-fee.

Indeed. Quoting myself here: "What we should have is both: fee
estimation with replacement so you can replace transactions in the event
that the estimate was too low."

So on IRC you were talking about very agressive mempool expiration - as
little as a block or two before tx's are expired. Now if a tx does fail
to get mined in that short window, am I correct in saying you want a way
to modify the fee it pays and rebroadcast? In which case wallet software
and other players in the ecosystem will have to adjust to the fact that
they can expect to see relatively frequent double-spends of unconfirmed
transactions?

As you know I've already written relaying/mempool code for
tx-replacement and replace-by-fee; it's the wallet code that's the hard
part that I haven't done. If you're already planning on changing the
wallet side of things to handle replacement-through-expiration that'd
save me a lot of hard work. You're probably better qualified to write
that code too; I'm not very familiar with the wallet.

Worth thinking about the whole ecosystem of wallets involved; they all
have to handle double-spends gracefully to make tx replacement of any
kind user friendly. We should try to give people a heads up that this is
coming soon if that's your thinking.


Also, regarding tx replacement user experience:

> Come back a few hours later and find out you need to type in your
> password again so your client can unlock your wallet, resign, and
> re-transmit with a higher fee?

Password-using wallets sign multiple versions of the transaction in
advance of course and release the higher fee versions only later if
required. (could be applied to coinjoin too)

--=20
'peter'[:-1]@petertodd.org
0000000000000005391e2338afe5204414d66b1f140b172da651daedf5663af2

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJSahibXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMGQ2NmZlMjAzZTZlZWRhYmNmN2U5OTZlMGJhNmI2NzMxMzdj
MDkzMDdiNDZmNDEyOTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftVRgf9EPp0jaQoPtrPXuGapZ0E5UZ1
A4BlW0oegsF6EQQJKb6cMAdyuHYFDpCfw/5+pMg8/jUkoGvc0WyG5qUscDQng+bR
4jUxps+MDoenFs+StU4W1WEyKQhtslvlultop4V3v7qWk3l8YmYJ6JzN4A6GjAGx
FXausdBx9DQmM9+ltQWLb3516k+NfLxc2xWHJcFzKhCl4erq+MaIMyAJmAQKhGwv
vjl2pyxiBWKV0EZJ6UnM/drKfssaMOtur5Ur4gZU+da+YUUthCnagsKf8upVsa+y
bgMusXdYY7D7p6ZDxSeBhnUM+BceTsR0poCMSuLvwZb+WClLB+6dR74pX2e7PA==
=bHOt
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--