Bitcoin client upload saturating my DSL connection. (No bandwidth throttling ?)

[Transisto]

During four days the bitcoin-qt.exe has uploaded 2.5gb of data and received 128mb.

It totally saturate my upload thus bottlenecking download too.  Pings of 260ms

I had 58 connected peers.

A: Is this normal ?
B: How trivial is it to add a bandwidth limiting feature ?
C: Why not a connection limiting feature too, ? I would think 40 connection is enough for me.

[1713856048]

1713856048

[1713856048]

1713856048

[1713856048]

1713856048

[1713856048]

1713856048

[zvs]

yes, it is normal.

i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)

[Transisto]

...
i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)

Thanks for the tip, I'd use my router QOS feature if I was concerned. Just wont be running it.

You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)

Also, It's not written anywhere what port it is using, although it has a "Map using UPnP" feature which nobody security conscious should be using.

Oh and the "Help" menu provide no help whatsoever. Not that I needed any, apart for knowing what port I should forward.  (8333, I know)

[TheBitcoinChemist]

You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)

You can actually set the number of connections, but I don't know enough about it to tell you how to do it.  You could 'nice' the process, and that would slow it down somewhat.

[Transisto]

You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)

You can actually set the number of connections, but I don't know enough about it to tell you how to do it.  You could 'nice' the process, and that would slow it down somewhat.

It might be possible under CLI but there is no such feature in the QT Version.  
"Nice" is for Linux, and affect the CPU aspect only.  


This is almost a security concern as rogue clients could endlessly request upload of the block-chain and saturate thousands of people's slow connections.

[DeathAndTaxes]

It might be possible under CLI but there is no such feature in the QT Version. 

https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File

[zvs]

This is almost a security concern as rogue clients could endlessly request upload of the block-chain and saturate thousands of people's slow connections.

yeah, I've had this happen.  I'm not sure if it's intentional or not, though.

but there have been several occasions where i've had one IP receiving data at 300k/s + for hours (this on my dedicated server, not home connection)

[2112]

It might be possible under CLI but there is no such feature in the QT Version.  

It works both with bitcoind and bitcoin-qt. You can set it in bitcoin.conf. The flag is:

maxconnections=125

with 125 being the default value. Set it to 9 or 10 if you have bandwidth caps.

By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. If you are really pushed into limiting your bandwidth usage then put "listen=0" in the .conf file and set the maxconnections to less than the default 8 outgoing connections.

Be aware that Satoshi bitcoin client does not check the spelling of the configuration flags and does not inform you about the ignored flags. This is entirely by design.

[Transisto]

It might be possible under CLI but there is no such feature in the QT Version.  

...
By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...

Botnets of rogue clients don't care about limits.

I don't think it's normal to put at risk users Internet's connections reliability for a feature so basic and easy to add.
There is more menus and sections in the GUI than there are settings to configure.

[grue]

It might be possible under CLI but there is no such feature in the QT Version. 

...
By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...

Botnets of rogue clients don't care about limits.

I don't think it's normal to put at risk users Internet's connections reliability for a feature so basic and easy to add.
There is more menus and sections in the GUI than there are settings to configure.

so you're worried about botnet owners ddosing a p2p network? right...

[2112]

Botnets of rogue clients don't care about limits.

I doubt about any botnets pretending to be the Bitcoin clients. About the only botnet-like thing that I could correlate with with running a Bitcoin (and Litecoin) client were probes for misconfigured and easily exploitable home routers with remote configuration port open.

On the other hand Bitcoin has a mechanism for statistically spreading p2p connections globally over /16 subnets. You may be running your bitcoin client on an ISP that has none or very few other bitcoin clients within the same /16 netmask.

I observed this on one of my office ISPs which gave us several disjont /28 subnets. Depending on which IP range I exposed my client I would've gotten vastly different numbers of incoming connections. But they are were legitimately behaving.

[scintill]

It might be possible under CLI but there is no such feature in the QT Version.  

...
By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...

Botnets of rogue clients don't care about limits.

2112 meant that the block-sending peer limits the block rates, not the block-requester, so rogue clients have good/smart clients to stop them.

However, if I'm reading the code correctly, it looks like 500 block hashes per request-message can be sent (via an inv response to getblocks).  Actual block data seems to only be limited to 50,000 blocks per request (or transactions, since this message can be used to fetch them too.)

This is my first time looking at the code, so I could be wrong.  There could also be lower-level rate-limiting not visible in the referenced sections of code.

[HeavyMetal]

In linux you can use a tool called "trickle" to limit your bandwidth like this:

Code:

trickle -u50 bitcoind

That will limit its upload to 50kb/s

[Transisto]

In linux you can use a tool called "trickle" to limit your bandwidth like this:

Code:

trickle -u50 bitcoind

That will limit its upload to 50kb/s

Sorry but what about adding a way to set connection limiting setting of bitcoin.conf to the UI ?

This is ridiculously weird.

And NO I am not editing my conf file nor am I going to install Linux for this.

Thanks HeavyMetal for trying to help

[racerguy]

Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.

[Transisto]

Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.

Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up.  I prefer to broadcast my transaction to 60+ connection than 8.

Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.

[Raoul Duke]

In linux you can use a tool called "trickle" to limit your bandwidth like this:

Code:

trickle -u50 bitcoind

That will limit its upload to 50kb/s

Sorry but what about adding a way to set connection limiting setting of bitcoin.conf to the UI ?

This is ridiculously weird.

And NO I am not editing my conf file nor am I going to install Linux for this.

Thanks HeavyMetal for trying to help

Why? Don't you have a text editor?

[racerguy]

Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.

Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up.  I prefer to broadcast my transaction to 60+ connection than 8.

Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.

You can tell bitcoin-qt to not use upnp from within the gui, also I don't see how 60 connections is better to broadcast a transaction v 8 connections, using only 8 also increases anonymity.  You can also tell bitcoin-qt to use a tor proxy from within the gui. 

[TheBitcoinChemist]

Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.

Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up.  I prefer to broadcast my transaction to 60+ connection than 8.

Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.

I leave my client closed and it doesn't have to catch up if I'm sending funds.  Otherwise I start it and leave it overnight about once every couple weeks.

[deepceleron]

Start with the command line option -maxconnections=X, where X is the largest number of other peers you want to maintain connections with. This won't prevent one of the clients wanting to get the whole blockchain from you, but it will lower the chance.