1) Bundle the first 80% of the blocks with the client download!
It really hammered the network to slowly distribute the blocks, and a lot of people talked about how annoying a problem this was for new users.
In early versions BitCoin wrote each single block synchronously - according to Satoshi, it flushed disk cache after each block and probably performed other operations required to make writes transactional. That performance problem has been fixed since that.
Also, is it possible for clients to start generating without the whole chain? Could clients download only "last block" (or something like that) and start solving it immediately? The previous blocks would be only necessary to validate that the last block is genuine, and that validation can be performed later.
2) Disconnect from the IRC when the outside port (8333) isn't connectible.
We gain NOTHING by having Bitcoin idle on the IRC channel when nobody can connect to it, and we hit the server harder and annoy privacy-minded people.
IRC is often forbidden by hosting TOS, so ability to operate without IRC and to use IRC only when necessary is important. I think we should bundle a host list with bitcoin and client should only try to use IRC if it cannot connect using that list.
The other request was to drop wxWidgets from the daemon, but having read the code, that seems like too much trouble to do now.
This in fact has already been implemented by Satoshi - building bitcoind does not require wxWidgets any more.[/quote]
My wishlist is:
1) RPM or at least binaries for CentOS (it has incompatible Boost and OpenSSL, so it's hard to build)
2) a pacman package for Arch
3) Pluggable hash cruncher.
4) Pluggable network layer.
5) An alternate implementation in Haskell, Erlang or Node.js (Python is fine too)
6) A graphical front-end to Bitcoind (it would be nice to run bitcoind in background and only run GUI sometimes to check balance/transactions. Now bitcoin cannot operate as a front-end to (a possibly remote) Bitcoind.)
A pluggable hash cruncher will allow one to implement plugins to use BitCoin on MPI clusters, Condor grids, BOINC workers, CUDA, cryptoaccelerators, specific processor features such as found in Via C7, Cray XT4 FPGA nodes, whatever. Also it will allow for slave workers with tiny memory requirements and minimal dependencies. Official bitcoin would send work to the cruncher, and the cruncher would distribute it to slaves and collect results. Slaves would only implement SHA256, so Boost and OpenSSL would not be necessary any more.
BOINC slaves are good because BOINC has much finer detection of idle resources than BitCoin.
A pluggable network layer will allow BitCoin to operate over other networks - for example, over Skype, XMPP/Jabber, Tor (clients could advertise their .Onion addresses instead of ips). It will also allow to switch to a network with higher degree of anonymity in the future if such network emerges and provides transport and node discovery services).
