Bitcoin Forum

I see this question asked a lot on the forums or IRC with the answer typically being "not very much".

I started an ubuntu server nothing on it except for bitcoin and vnstat. I let it run a few days to get some connections reliably built up. I started vnstat today.

In the last 3 hours averaging between 115 and 130 connections, the server has:

Received 28.08 MiB
Transmitted 115.55 MiB

Total: 143.63 Mib


I will run it for a few weeks/months and copy some of its charts into a later post. On this average so far if the trend continues (which it has +-10% for the last three hours) this would be Over a gig of transfer per day for a server with > 100 connections. Over 30 GB a month.

If those numbers hold up for scaling down to 8 connections, this would be around 100 MB per day, 3 GB per month.

I'll have more data for you in a while.

After over a week of tracking, I have some additional results. Connections did remain over 100 the entire time.

It could be estimated from this, that approximately 50 Megs per day would be used by a standard client with 8 connections.

To make sure I ONLY was getting bitcoin traffic, I have IPtables rules set up only to allow port 8330-8340 and the non standard port I have specified for my SSH access. Hardware firewall outside of the box only allows the 8000 ports into via NAT.

      day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      07/21/11    103.77 MiB |  528.33 MiB |  632.10 MiB |   59.93 kbit/s
      07/22/11    173.51 MiB |  711.31 MiB |  884.82 MiB |   83.89 kbit/s
      07/23/11    156.95 MiB |  659.00 MiB |  815.94 MiB |   77.36 kbit/s
      07/24/11    166.74 MiB |  803.53 MiB |  970.27 MiB |   92.00 kbit/s
      07/25/11    169.36 MiB |  543.76 MiB |  713.12 MiB |   67.61 kbit/s
      07/26/11    147.99 MiB |    1.19 GiB |    1.33 GiB |  129.35 kbit/s
      07/27/11    169.59 MiB |    0.99 GiB |    1.15 GiB |  112.06 kbit/s
      07/28/11    181.20 MiB |  932.72 MiB |    1.09 GiB |  105.62 kbit/s
      07/29/11    162.22 MiB |  639.65 MiB |  801.88 MiB |   76.03 kbit/s
      07/30/11    152.59 MiB |  592.65 MiB |  745.24 MiB |   70.66 kbit/s
      07/31/11    167.25 MiB |  666.33 MiB |  833.59 MiB |   79.04 kbit/s
      08/01/11    175.02 MiB |  696.06 MiB |  871.08 MiB |   82.59 kbit/s


Notice that there were some high days and some low days. Very interesting information.

Why do people always "reserve" forum posts? I have never understood that...

Anyways the answer to your question is "it depends" ...

The fact is that every transaction block is a different size, generally growing larger by the day.

Mining iv used 31MB this month so far with 2PC
Installed the bitcoin client and my wallet on my laptop which hadn't ever been on and it took 8hours and 957mb to get upto date with all transactions.

Even if you have "only" bitcoin on the Ubuntu box, you cannot be certain that traffic you measured is *only* bitcoin.  Just to muddy the waters -- 10GH/s on our pool consumes 56kbps on average  ;D

You won't get representative numbers right now—  you're running .24 (obviously, or you wouldn't maintain >100 connections) which means you're one of the good nodes which is feeding out the block chain to new and backlogged clients.

A significant fraction of the network is still on older versions which hang up on nodes trying to fetch the current blockchain, so the good nodes are taking an unusually large portion of the load right now.

I wonder if there would be interested in adding a 'conserve bandwidth' flag to the client. This is kind of the reverse of the 'hub' or 'supernode' modes that myself and others have been talking about. I think the best solution is to address all ends of the spectrum in one set of patches. That would allow those that needed to conserve bandwidth to choose to do so but also allow those who wanted to donate connectivity to improve the network to do so as well.

It's called nolisten (or simply not forwarding the port…). Or more aggressively, "connect" though that should really be a trusted node since it makes you more vulnerable to misbehavior by your peer.

Please don't add anything more damaging to the network than that, we've already been having problems due to the pre-.24 nodes.

How to limit your bandwidth to 1mbps up and down without bloating up the bitcoin client with unnecessary code:

sudo apt-get install wondershaper
sudo wondershaper eth0 1024 1024

if you only have 8 connections total, it means that you do not have the port forwarded, and thus will not upload blocks, at least AFAIK. this also means that the only data sent/received is blocks coming in only and transactions coming in, and yours going out.

I updated my second post to reflect the new data that I have gathered. The post immedietely above this indicates that if you do not have the port forward, you are not uploading blocks. Does anyone know if that is correct? If that is actually the case, the estimated 50 megs a day for 8 connections would be considerably less.

- - - - -

After over a week of tracking, I have some additional results. Connections did remain over 100 the entire time.

It could be estimated from this, that approximately 50 Megs per day would be used by a standard client with 8 connections.

To make sure I ONLY was getting bitcoin traffic, I have IPtables rules set up only to allow port 8330-8340 and the non standard port I have specified for my SSH access. Hardware firewall outside of the box only allows the 8000 ports into via NAT.

      day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      07/21/11    103.77 MiB |  528.33 MiB |  632.10 MiB |   59.93 kbit/s
      07/22/11    173.51 MiB |  711.31 MiB |  884.82 MiB |   83.89 kbit/s
      07/23/11    156.95 MiB |  659.00 MiB |  815.94 MiB |   77.36 kbit/s
      07/24/11    166.74 MiB |  803.53 MiB |  970.27 MiB |   92.00 kbit/s
      07/25/11    169.36 MiB |  543.76 MiB |  713.12 MiB |   67.61 kbit/s
      07/26/11    147.99 MiB |    1.19 GiB |    1.33 GiB |  129.35 kbit/s
      07/27/11    169.59 MiB |    0.99 GiB |    1.15 GiB |  112.06 kbit/s
      07/28/11    181.20 MiB |  932.72 MiB |    1.09 GiB |  105.62 kbit/s
      07/29/11    162.22 MiB |  639.65 MiB |  801.88 MiB |   76.03 kbit/s
      07/30/11    152.59 MiB |  592.65 MiB |  745.24 MiB |   70.66 kbit/s
      07/31/11    167.25 MiB |  666.33 MiB |  833.59 MiB |   79.04 kbit/s
      08/01/11    175.02 MiB |  696.06 MiB |  871.08 MiB |   82.59 kbit/s


Notice that there were some high days and some low days. Very interesting information.

Unfortunately, it cannot. You need to remember that people with only outgoing connections are very unlikely to announce blocks or transactions that the nodes that are connected to it (which are well-connected since they accept incoming connections) haven't already seen. The inverse is also true: well-connected nodes are extremely likely to have to broadcast new transactions/blocks to a large portion of the nodes connected to it.

As a result, in order to get bandwidth numbers for a node that doesn't listen, you will need to do this test again with a node that doesn't accept incoming connections.

You should use iptables to measure the traffic (view data amount of your ALLOW rules with -L -v). With vnstat you measure whatever the host receives over its LAN interface, including broadcasts and filtered port ranges.