bitcoin client that doesnt use so much bandwidth?

[kalinka]

I can't be using 15 GB bandwidth running this client every 3 days. I'm on family's internet plan and I don't want them warning us for high bandwidth use...

Are there any clients that don't use so much bandwidth?

[gweedo]

You can also just set the max connections to 8 in the bitcoin.conf file, that should help with the high bandwidth.

Code:

maxconnections=8

[Nesetalis]

there are thin clients.. that don't download the block chain.. instead connect to some one else's block chain and use that.
of course, you have to trust the person you are connecting to.

[Monster Tent]

there are thin clients.. that don't download the block chain.. instead connect to some one else's block chain and use that.
of course, you have to trust the person you are connecting to.

It really defeats the purpose of bitcoin to do that.

[Nesetalis]

there are thin clients.. that don't download the block chain.. instead connect to some one else's block chain and use that.
of course, you have to trust the person you are connecting to.

It really defeats the purpose of bitcoin to do that.

no, it doesn't.
I have 3 computers, plus maybe a mobile device.. my desktop doesn't need to be on 24/7 but my tiny server does.. I can run my block chain on the tiny server.. and then use a thin client to connect to the server from my mobile device, desktop, or what not... but becuase i'm running this node, and my room mates trust me, they too could use this node.
It does not make the network any more or less secure... it doesn't "Defeat the purpose" in the least.. My mobile device does NOT have 2gb of free space to download the current block chain, let alone the bandwidth required to keep up to date. My desktop isn't on 24/7 to download the block chain constantly, so any time I start up bitcoin, it may take an hour or two to catch up.. rather annoying for quick transactions.

[jim618]

Now that MultiBit has bloom filtering it really reduces the amount of bandwidth used.

It will only download the transactions relevant to your wallet - my network usage when I am syncing is only about 100 KB/s at 100 blocks a second.

[Sukrim]

Also were these the first 3 days where oyu did download the whole chain etc. or does your node really use 15 GB of traffic every 3 days?

[Raoul Duke]

Now that MultiBit has bloom filtering it really reduces the amount of bandwidth used.

It will only download the transactions relevant to your wallet - my network usage when I am syncing is only about 100 KB/s at 100 blocks a second.

Well, I've used nethogs to check bandwidth spendings of bitcoin-qt and multibit yesterday, and your client spends more bandwidth than bitcoin-qt in normal usage. Like 5x more. And yes, I have way way more than 8 connections on bitcoin-qt.
Also it's buggy and 30% of times it doesn't see incoming transactions without reseting the blockchain.

It may be good not to scare newbies with the blockchain download time, but I won't recommend it to any newbie because of the incoming transactions bug.

[Zeilap]

Now that MultiBit has bloom filtering it really reduces the amount of bandwidth used.

It will only download the transactions relevant to your wallet - my network usage when I am syncing is only about 100 KB/s at 100 blocks a second.

Well, I've used nethogs to check bandwidth spendings of bitcoin-qt and multibit yesterday, and your client spends more bandwidth than bitcoin-qt in normal usage. Like 5x more. And yes, I have way way more than 8 connections on bitcoin-qt.

Just tried this myself, here's the results after both have synchronized
Multibit: send 2.6 - 3.2 KB/s, receive 3.6 - 5.0 KB/s
Bitcoin-qt: send 0.6 - 1.2 KB/s, receive 0.6 - 1.2 KB/s

Both have empty wallets. Surely Multibit should really only be receiving rare unsolicited 'inv' and 'addr' commands and sending nothing.

[Raoul Duke]

Now that MultiBit has bloom filtering it really reduces the amount of bandwidth used.

It will only download the transactions relevant to your wallet - my network usage when I am syncing is only about 100 KB/s at 100 blocks a second.

Well, I've used nethogs to check bandwidth spendings of bitcoin-qt and multibit yesterday, and your client spends more bandwidth than bitcoin-qt in normal usage. Like 5x more. And yes, I have way way more than 8 connections on bitcoin-qt.

Just tried this myself, here's the results after both have synchronized
Multibit: send 2.6 - 3.2 KB/s, receive 3.6 - 5.0 KB/s
Bitcoin-qt: send 0.6 - 1.2 KB/s, receive 0.6 - 1.2 KB/s

Both have empty wallets. Surely Multibit should really only be receiving rare unsolicited 'inv' and 'addr' commands and sending nothing.

Kinda strange that the Multibit developer doesn't know the behaviour of his own client and comes here passing lies as truths. But I digress...

[Zeilap]

Both have empty wallets. Surely Multibit should really only be receiving rare unsolicited 'inv' and 'addr' commands and sending nothing.

Ahh, just realized what the extra bandwidth is - MtGox ticker data.

Anyway, does anyone really care about a few KB/s?

Kinda strange that the Multibit developer doesn't know the behaviour of his own client and comes here passing lies as truths. But I digress...

What's the lie?

[Raoul Duke]

What's the lie?

That it spends less bandwidth.
If I remember correctly from when I installed Multibit the ticker was active by default. At least I don't remember activating it, I just remember changing the currency from USD to EUR. But that was more than 1 month ago, so I may be mistaken.

BTW, Jim, if you read this, you should put a warning that after deactivating the ticker the client should be restarted or else it continues getting the data.

[Zeilap]

What's the lie?

That it spends less bandwidth.
If I remember correctly from when I installed Multibit the ticker was active by default. At least I don't remember activating it, I just remember changing the currency from USD to EUR. But that was more than 1 month ago, so I may be mistaken.

BTW, Jim, if you read this, you should put a warning that after deactivating the ticker the client should be restarted or else it continues getting the data.

Lol, I didn't realize you could turn it off - assumed it simply stopped displaying it as the network activity didn't change.

Turns out that only accounts for 1KB/s each up and down, so there's still some funny business going on. 5KB/s total up and down over 24 hours is pushing half a gigabyte, compare that to what is possible from a thin client
- Sync from last checkpoint in mid-February, 3200 blocks is about 260KB down (2000 headers at 81 bytes per block plus 24 bytes message header, then same but for the remaining 1200),
- 144 blocks over 24 hours which is another 15.1KB (81+24 bytes per block header)

So total down could be as little as 275KB for your first day, then 15.1KB per day after that. Compare that to half a gigabyte per day and it's quite significant if you're running it over 3g or something.

[jim618]

Now that MultiBit has bloom filtering it really reduces the amount of bandwidth used.

It will only download the transactions relevant to your wallet - my network usage when I am syncing is only about 100 KB/s at 100 blocks a second.

Well, I've used nethogs to check bandwidth spendings of bitcoin-qt and multibit yesterday, and your client spends more bandwidth than bitcoin-qt in normal usage. Like 5x more. And yes, I have way way more than 8 connections on bitcoin-qt.

Just tried this myself, here's the results after both have synchronized
Multibit: send 2.6 - 3.2 KB/s, receive 3.6 - 5.0 KB/s
Bitcoin-qt: send 0.6 - 1.2 KB/s, receive 0.6 - 1.2 KB/s

Both have empty wallets. Surely Multibit should really only be receiving rare unsolicited 'inv' and 'addr' commands and sending nothing.

It has to send to the server some "command and control" bytes and also the bloom filter which is non trivial in size. It resends the bloom filter every few ten thousand blocks. These all go to a single download peer, not all connections. It also listens to the zero confirmation transactions from all peers to check transaction propagation.

From your figures it looks like MultiBit uses more bandwidth than Bitcoin-QT once it is synchronized. Fair enough. A max figure of 5.0 KB/s is acceptable to most users I think. The big win is in the initial sync.

edit: the exchange rate is only polled if you either have currency conversions switched on or the ticker shown. You don't have to restart MB if you change it - I restart the background task that does the polling if you change it's settings.

[jim618]

Here is a Mac 'Activity Monitor' screenshot of MultiBit's network usage:



I waited for a block to arrive to make it more interesting. This is the spike in the middle. The horizontal axis is about a minute for the whole graph. Most of the time the up and down traffic is around the 2 or 3 KB/s level which matches Zeilap's figures.

This is the latest version (v0.4.22) with the currency ticker on and two currencies being shown coming from two different exchanges (Mt Gox/GBP and OpenExchangeRates.org/USD).

[Mike Hearn]

There's a bug in the current version of MultiBit that makes it send pings too fast/too frequently. That is the reason for the high bandwidth usage.

Also, just in general we ping other servers quite aggressively. In future we'll scale it back a bit.

Anyway, comparing continuous bandwidth usage seems rather pointless. There's no need to run a client like MultiBit all the time. It catches up fast, so just open it when you need it.