Bitcoin Forum

Bitcoin has obviously outgrown the initial experiment stage. It's getting robust and has gained at least 400 clients today (according to the counts in #bitcoin on LFnet). As a result, it needs to grow some new features.

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.
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.
3) Allow different ports than 8333 and 8332.
   Right now, it is trivially easy to block Bitcoin at a network level, and nothing has used fixed ports since BIND. We can do better.
4) Allow exporting the wallet for backups.
   People might actually backup then!

I'm sure there are others, but those are my top four. This is based upon participating in the chat in #bitcoin-dev. The other request was to drop wxWidgets from the daemon, but having read the code, that seems like too much trouble to do now.

I'm sorry if this post sounded harsh, but these are some nice (and fairly simple) things to do to make Bitcoin more new user friendly.

  is essential.  There are a lot of places where several people are behind the same NAT router. as it is, only one of them can have incoming connections.

The client needs also to show something to the user, example: unable to connect ...

This is important.  A lot of people got very frustrated waiting hours for them to download.

If a user wants perfectly ensured security / doesn't trust the builder, they can always delete the bundled blocks and let them reload individually.

Agreed; it could be a checkbox option in the installer.

Add priority management to the list, so that we can start the program always in the lowest priority for example. That way, it can run on idle CPU time instead of sharing CPU time with the current system applications.

I can confirm the block problem. I just installed Bitcoin on my tower, and it is really annoying to hear the hard drive crunch like crazy as it downloads the blocks.

Could the initial block and client download be managed through bittorrent?

This way you could seed whilst running bitcoin . :)

The seeds on bittorrent would have the latest blocks and this would mean removing the single point of failure of one website location for the initial download.

For the block download problem, this patch might solve it. I haven't had time to test it yet, but it looks good.

http://bitcointalk.org/index.php?topic=354.0

you can use this torrent http://knightmb.dyndns.org/files/bitcoin/BitcoinBlocks.torrent (http://knightmb.dyndns.org/files/bitcoin/BitcoinBlocks.torrent) for the block download.

I've seen transaction fees mentioned a few times but I don't see any way in the client to implement them.

Looks like they will be implemented only after emission of 21 million BTCs will be close to an end.

So not for about 20 years? 

The fees are already implemented, in the case of very large transactions (http://bitcointalk.org/index.php?topic=141.msg1168#msg1168).

It is done so that when you create a transaction, you put more bitcoins in than what goes out. The difference goes to whoever manages to create an accepted block with your transaction. If I wanted, I could modify my client so that your transaction is included in the block I'm generating only if it gives me enough bitcoins as a fee. If enough (generating) clients did this, it would be advantageous for you to add the fee to your transactions, so that they are processed faster.

Right.  I was asking if this is going to be an option that will be a part of the GUI for the bitcoin client.  Making it simple for someone to charge transaction fees if they so desire.

Yep, I had an idea too, for someone generous to disable taking transaction fees (so if they somehow participate in the transaction, they don't take the fee, but let it pass to the recipient (or return to the sender :D )

I'm not sure a static download of the first n blocks is really the right solution.  The problem isn't that it's so much data for the network to handle, the problem is that the processing and storage of those blocks is really expensive.

Static download is a crutch, fix the real problem: Why should downloading 32M of blocks bring my computer to a halt for a couple hours under any circumstances?!

I don't think the block download brings your computer to a halt, it's more like the program isn't going to burn up 100 megabits to get the blocks. It runs very light on bandwidth and so do the other peers you are connected to get the blocks.

That's why I created those package block downloads, to save time. It's quicker to download a small 32 MB file from my fiber connection than to wait a while for the p2p network to send it to you.

Has this been resolved yet?

Does the 'address' network message include TCP port number?

add more configuration / command line options:

PS: Port, to which the listening socket is bound to is not always the same port, that is externally visible to the Internet, especially if you use firewall, so do not always derive one from another, please let the users decide too.

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.

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.

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).

Oh yes, how about using autoconf & automake to provide beautiful configure script to generate makefiles,
instead of hand-editing them for every build environment?

Just for the software to be taken seriously by the GNU people.

Autotools are evil. I heard someone was already working on CMake build system for bitcoin. Boost.Build would be fine too, as Bitcoin requires non-header only Boost libraries anyway, and building those libraries (at least Boost.Filesystem) requires Boost.Build to be configured.

You may dislike autotools, but they are supported by every packaging system out there.  Fedora, Debian, Slackware, etc. all have macros and other tools to help with packaging autotool packages.

Well, Windows (namely, MSVC) doesn't. And autotools are not installed by default, just like CMake, SCons etc. And installing autotools are not any harder than other build systems. So autotools are not better in terms of availability on *nix than any other build tools. Of course having autotools is better than manual make we have now, but I don't see how CMake or Boost.Build are worse.

Don't confuse me!

CMake is not installed by default on my Debian. And MSVC is not installed too :).

autotools are only required to generate configure scripts, they are not needed to build the source distribution
on the build environments.
Only gcc (g++), binutils and GNU make will be required to build from the generated makefile, not other tools.