Bitcoin is "Growing Up" : Feature Request

[lachesis]

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.

[1713996482]

1713996482

[1713996482]

1713996482

[TheOddShot]

3) Allow different ports than 8333 and 8332.

  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.

[HostFat]

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.

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

[llama]

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.

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.

[Bitcoiner]

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.

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.

[knightmb]

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.

[Bitcoiner]

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.

[Anonymous]

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.

[lachesis]

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

[SmokeTooMuch]

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

[Babylon]

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

[d1337r]

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

[Babylon]

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? 

[Svick]

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.

The fees are already implemented, in the case of very large transactions.

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.

[Babylon]

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.

The fees are already implemented, in the case of very large transactions.

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.

[d1337r]

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 )

[dete]

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?!

[knightmb]

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.

[mizerydearia]

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.

Has this been resolved yet?

[jgarzik]

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