There's a lot that must be done, and my biggest target in the coming
months will be to free up enough time and isolate myself to be able to
finish these.

- - Electrum backend adapter either using the Python query layer or
libbitcoin Python directly.

This would be the first Bitcoin wallet that is completely independent
combined with a fully complete reimplementation that isn't depending
on bitcoind.

- - Rewrite the protocol service subsystem in libbitcoin. Make the
max_outbound connections adjustable. Parameters are passed in the
start() method, dependencies for a service inside the constructor.

- - Way to intercept version messages inside protocol service when a new
connection is made and the handshake is performed.

- - Way to attach custom state/data to channel. Custom properties? This
would be used for bloom filters or other state that is now required by
the Bitcoin system since the recent changes (3 big protocol changes in
under a year :/).

The only tricky part is getting/setting these properties must be
asynchronous without locks. So there should be a way to combine
several queries into one combined operation which calls a handler with
all the requested data once it's done.

- - Proper unit testing suite. This is mainly to appease people. Real
stability comes from putting your code into heavy production cycles.
Not silly unit tests testing things you expect to go wrong.

- - Rewrite the blockchain reorganisation code to use an algorithm like
the git trees/rebase. More of a data-structure driven approach rather
than an algorithmic one.

- - HD wallet support.

- - Finish getx_responder for the get* Bitcoin messages.

- - firstbits support.

- - bloom_filter support.

- - BlueMatt has a blockchain testing suite which tests lots of edge
cases. Would be good to get that working.

- - Use append only memory mapped file for storing blocks. Flat file
block storage with indexes stored in the database rather than the data.

- - New blockchain API. You create a query like:

blocks[110].transactions[10].hash

And then the underlying storage engine (leveldb, bdb, SQL, memory,
...) generates the needed queries and then calls a handler you provided.

This convenience layer simplifies the long chain of fetch_* calls that
the library user must perform. However trying to visualise how to
create this layer is difficult as it needs several underlying generic
components that I haven't worked out yet.

1. Take the query.
2. Translate it to some kind of query tree.
3. Storage backend translates it to its internal model format, and
generates the fetch mechanism it performs.
4. Storage backend executes the series of fetch calls, filling in a
data structure.
5. Calls the user provided handler with the data structure.

I'm unsure what the returned structure would look like or whether it's
just a generic properties list.