Bitcoin Forum

I recently downloaded the newest version (0.8.5) of bitcoin-qt to my MacBook. I'd been using 0.8.0.
Today, I just happened to notice that my internet performance was sluggish so I took a look at the Activity Monitor and saw something was uploading to the internet at max speed. It was rolling along at 600+Kbytes/sec, which maxes out my Comcast cable upload capacity.

By process of elimination, I determined it was bitcoin-qt. Now I can understand it having to download the blockchain, but what on earth is it uploading?

Thanks

peer to peer.

When you are "downloading" the blockchain where do you think it is being "uploaded" from?  The central Bitcoin, Inc server farm?  :)

That being said the QT client is pretty horrible about bandwidth management.  Since devs seem to have no interest in putting in speed caps you may want to look into a third party tool which will cap the speed.

Where do you think you are downloading it from?...

So that other people can download. It's all p2p based. You download the blockchain from other people running the client, and upload to other people needing a download.

Thanks for the replies. Well, I always thought that the miners served out the blockchain not the clients. And my client is behind a firewall, with no port forwarding, so how are other clients attaching to it?

You had to give permission when you installed it, right? Everytime I download a different wallet, Windows asks me...

You are the bank and your computer is doing bank stuff.  :)

Just as a side comment, I use torrent seeding etiquette when DL-ing the blockchain. That is to say, I keep the client running twice as long as it took to receive the chain. That way I'm not leaching off the network. (which is allowed)

No permissions were requested, plus the firewall is on my wi-fi router, and I know damned well it has no ports forwarded.

My guess is that they're using some sort of server polling handshake or maybe UDP punch-through?

https://bitcointalk.org/index.php?topic=334778.msg3626032#msg3626032

QT uploads A LOT, if you let it, though, which should be advertised a little more, in my opinion.
If you don't limit QT, it will eat up a huge chunk of your upload BW.

Also except from the blockchain per se it relays unconfirmed transactions until they get included to a block.

Could you limit it thru the maxconnections parameter?

Yes,

I have limited mine to a max. of 5 connections. This limits the amount of transactions your Node relays. Although, it doesn't limit the bandwidth used when one of your connections happens to need the Blockchain from you. But there are not as many that get the Blocks from you every time there is a new block.

Please also note that you are helping Bitcoin with running a full Node. Without enough of them Bitcoin wont work.

(Also that's one thing that bugs me about BTC a little, that miners have a financial incentive to secure the Network, but there is none to store the transaction history and to relay blocks and transactions.)

Bitcoin-Qt establishes 8 outgoing connections to peer nodes when it starts up.  It then listens for incoming connections and will accept connections until the maxconnections limit is reached.  By default, Bitcoin-Qt will use uPnP to open the 8333 port on your router if it is supported.  You can specify listen=0 if you do not want to accept incoming connections.

I use NetLimiter to limit the upload bandwidth used by Bitcoin-Qt and I specify maxconnections to limit the total number of connections to something that is manageable.

Thanks for all the replies. This has been very informative. I checked the Preferences on bitcoin-qt and found that it uses uPnp, which has the ability to open ports on routers that have it enabled. So I am trying, just as an experiment, shutting off uPNP on my router and see if anything else breaks.

The other interesting thing I discovered was that my supposition was correct about UDP. UPnP uses a UDP variant of http called httpu. You can do some pretty cool things with UDP because it doesn't require establishing a heavyweight connection like TCP.