Topic: Selfish Node: min. bandwdith needed for Bitcoin Core + tons of other data - page 2. (Read 3936 times)

What client?  Are you running both bitcoin and bitcoind on the same machine?  If so why?

Interesting!

I am running bitcoind but only have 9 peers connected and they are consuming in total 1KBs down & 500Bs up. My total would be about 2.6GBs per month down, if I have my math right


I have one other connection to bitcoind and that is to the client itself which consumes 23KBs down and 22KBs but to the same computer. Hopefully every took that connection into account when totalling their figures.

I'm using http://www.netlimiter.com/ for my monitoring/throttling, and the pictures posted by Kludge look very much alike, I wouldn't be surprised he was using it too.
You can give it a try if your node is on a windows box, but it installs network drivers, so there's always a risk, be sure to backup before.

He was just using Skype as a common reference point to show how much more QT uses than many people may think.

mine has around 90 connections and sends around 10-15gbs out per day.

Where did you get the stats from?

I am running a relatively large node (200+ connections, 50 kbps upload, uncapped download) and would be interested in graphing something like that.  I probably will be moving my main node to datacenter and connecting to it via secure RPC calls.  The client locally will just be "dumb wallet".

I don't get your Skype comparison, either to mislead or you simply didn't read it properly, the Skype graph shows consumption in MB, not GB, so its still way smaller than the Bitcoin QT.

After 24 hours, upload consumed by QT client has reached 22GB.
So we're talking about 650GB per month.
Guess it's time to throttle it. 

20 minutes, almost 300MB upload.
Great clue to explain family complaining about sluggish internet...
I'll still run QT "unleashed" for some time, for truth, but I'll throttle it hard too, after. If not stickied, this should at least come up as a warning when you install QT.

I don't have QT runnning 7/24, but I'll be able to do at least batches of weekly stats, will update.

I'd guess it'd be dependent on the total amount of bandwidth available unless you have a lot of slow peers (like me) connected, where they can't "eat" as much as they could be sent. Most wired connections are asymmetrical, so the user probably wouldn't notice if QT consumed the vast majority of their upload bandwidth unless they were uploading large files.

I'd guesstimate if you had a 756kbps up connection, many peers, and left QT on 24/7, you'd probably be looking at ~100-150gb/mo.

Thanks for the data, Kludge.
I'm curious about the throttle, though, what do you think it would look without it?
Anyway, I'll monitor bandwidth of QT client too, from now on...

bump for curiosity

In most cases, upload bandwidth would be dramatically higher. In my case (made a little note in OP), I always have QT throttled to 1kb/s because I can't handle more and still be able to browse online. I also throttle download speed to 9.5kb/s, but that's more than enough to stay sync'd to the blockchain. Download speed throttle is only to even out strain of receiving new blocks so I don't notice it as much.

That is surprising. I have my Bitcoin-Qt node running 24/7 at home. It states around 60 active connections, 8 of which are outgoing connections and the rest are incoming. For that reason, I would have thought that the up bandwidth would have been noticeably higher than the down bandwidth...

Not that I care that much. I have a flat rate monthly contract 

Thx.  Trying to decide whether to start my client back up on my satellite connection ($80 for 15GB/mo.)  Your info is valuable.

It is probably worth note that half a decade ago, Comcast (at least) was traffic shaping for economic reasons.  Fucking with P2P traffic.  They stopped because of economic, political, and legal pressures and not because of any particular technical challenges.

This is a key point to consider because the political and legal challenges could not only vanish but be completely reversed.  And it could happen at the flip of a switch, and probably across all providers who do not have actual ownership of part of the internet backbone.  That means practically everyone and every business could be impacted.  Those organizations who do have actual fiber and core routers can be brought under other pressures.

This is why the issue of transaction rate (block size) is so critical to me.  Smaller streams could potentially find nooks and crannies to wiggle through and keep the Bitcoin network functional in a more or less free form.  Larger streams feeding more sophisticated deployments (e.g., 'supernodes') could have a great deal of difficulty operating in a hostile environment.  Or at least operating free of coercion to honor various type of taint and privacy frameworks.  This is what I would call the 'WHG attack' after Waters, Hearn, and Guo.

Thank you very much for this analysis.

I stopped running nodes in mid-2012 due to excessive costs of bandwidth in rural Australia.

Estimated minimum TCP throttle: 3kb/s (likely lower, will continue testing)
Estimated minimum UDP throttle: 1kb/s (likely closer to .1kb/s)
Caveats: Because throttling will prevent you from truly acting as a full node and processing the transaction queue, you will likely not see transactions sent to addresses you control until it's included in a block. If you receive a low-priority transaction, it's possible your client won't notice it for a looong time (a 10kb/s throttle appears to keep up fairly well with the transaction queue). There may also be a delay when you send a transaction out, though temporarily unthrottling the connection would obviously fix this. This minimum WILL change due both to changes to Bitcoin's rules and the increasing blockchain size.


I figured someone may be interested in how much bandwidth running QT actually consumes per month in a scenario. It's right around 3GB down, 1GB up, assuming network is caught up AND you have severely throttled upload bandwidth allowed to QT (in these stats, QT has always been throttled to 1kb/s UL). December 10, '13 update: That statement is false. QT downloads transactions for queue as well as blocks. By throttling (for these stats, I set DL limit to 9.5kB/s) above the "true minimum" required, bandwidth is still going toward downloading transactions, which is non-essential. This makes these stats useless except to know QT will currently function (without accumulating a block backlog) with less than 9.5kB/s or ~3GB/mo allotted to it.

QT consumption stats:

Grabbed on December 10, 2013

The stats file gets enormous, so I semi-regularly delete it and don't have older data - sorry.

For the sake of comparison (I'm not trying to make any kind of point with this), here is "real" consumption from a well-used Skype client without use of video/audio streaming:


ETA: Stats on Chrome are incomplete for some reason... so here're the stats for the download manager I use (every large file I download off the web):


Other data:
Sync times and theoretical "cost to sync": https://bitcointalksearch.org/topic/m.6306363
Blockchain compression (not pruning!) methods compared: https://bitcointalksearch.org/topic/m.6352393