Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.181 as permitted sender)
	client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f181.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
	<CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
Date: Sat, 16 Jun 2012 09:55:55 +0200
Message-ID: <CANEZrP2pgBQUj7TYhyAw38p5KKNjmg_mOG4+O-A0DENErYbk5Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
Precedence: list

[resend, sorry gavin]

I think these ideas all make a ton of sense, some have been floating
around for a while in various forms but it's good to draw them
together coherently.

> o Fill up the "free" space (if any) with the highest-priority
> transactions, where priority is a function of transaction size, age of
> inputs, number of bitcoins... and ratio of inputs to outputs (to
> encourage combining inputs so more pruning is possible).

Is more incentive needed? If you have tons of tiny outputs you already
have incentives to merge them because otherwise your txns will become
large and the fees needed to overcome the DoS limits and gain priority
will rise.

The code to do it is a bit irritating as you really want to de-frag
wallets in the background when the user is not likely to need the
outputs quickly, and I suspect over time transaction volumes will
become diurnal so it'd be cheaper to do that at night time, but it's
all possible.

> But that won't work for newly started clients that haven't seen a lot
> of transactions enter/exit the memory pool

Peers could provide first-seen timestamps for transactions when
announced or when downloaded with Jeffs proposed command, but the
timestamps are not necessarily trustable. Not sure if that'd open up
new attacks.

> or SPV clients that can't lookup transaction inputs

SPV clients can do it by getdata-ing on the relevant inputs, but it's
very bandwidth intensive just to guesstimate fees.

> Maybe each client developer runs a "fee policy server"

That's reasonable. I don't believe this case is worth worrying about
right now. For the common cases of

a) Customer buys from merchant (runs full node)
b) Trusted person sends money to trusting person (does not need confirms)

it wouldn't matter after the changes to the block creation code. It's
only really an issue when a user running an SPV client wishes to
accept money from somebody they do not trust, and they want it to
confirm quick-ish (within an hour), but can tolerate delays up to
that. I think this is likely to be rare.

Much more common is that you want to accept the payment immediately,
which is an oft discussed but different problem.