Bitcoin Forum
April 19, 2014, 10:07:28 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2  All
  Print  
Author Topic: Bitcoin client upload saturating my DSL connection. (No bandwidth throttling ?)  (Read 6851 times)
Transisto
Donator
Hero Member
*
Offline Offline

Activity: 1134



View Profile WWW

Ignore
August 15, 2012, 04:50:18 AM
 #1

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.

Visit and contribute to reddit.com/r/Bitcoin
1397945248
Hero Member
*
Offline Offline

Posts: 1397945248

View Profile Personal Message (Offline)

Ignore
1397945248
Reply with quote  #2

1397945248
Report to moderator
1397945248
Hero Member
*
Offline Offline

Posts: 1397945248

View Profile Personal Message (Offline)

Ignore
1397945248
Reply with quote  #2

1397945248
Report to moderator
1397945248
Hero Member
*
Offline Offline

Posts: 1397945248

View Profile Personal Message (Offline)

Ignore
1397945248
Reply with quote  #2

1397945248
Report to moderator
Buy a Blade, Get a 5-Chip Free!
Start Mining with GAWMiners.com
24/7 Live Phone & Tech Support
Free Hosting & Electricity for 1 Year!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397945248
Hero Member
*
Offline Offline

Posts: 1397945248

View Profile Personal Message (Offline)

Ignore
1397945248
Reply with quote  #2

1397945248
Report to moderator
zvs
Hero Member
*****
Offline Offline

Activity: 854



View Profile WWW

Ignore
August 16, 2012, 10:43:01 AM
 #2

yes, it is normal.

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

This is no job for the police. It's something I'll have to do. Only a ninja can stop a ninja.

DOGE P2Pool 0% nogleg.net:9555
Transisto
Donator
Hero Member
*
Offline Offline

Activity: 1134



View Profile WWW

Ignore
August 16, 2012, 08:16:55 PM
 #3

...
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)

Visit and contribute to reddit.com/r/Bitcoin
TheBitcoinChemist
Member
**
Offline Offline

Activity: 70


View Profile

Ignore
August 16, 2012, 08:21:53 PM
 #4

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
Donator
Hero Member
*
Offline Offline

Activity: 1134



View Profile WWW

Ignore
August 16, 2012, 08:24:59 PM
 #5

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.

Visit and contribute to reddit.com/r/Bitcoin
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Activity: 966



View Profile WWW

Ignore
August 16, 2012, 08:35:18 PM
 #6

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

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
zvs
Hero Member
*****
Offline Offline

Activity: 854



View Profile WWW

Ignore
August 16, 2012, 10:20:06 PM
 #7

Quote
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)

This is no job for the police. It's something I'll have to do. Only a ninja can stop a ninja.

DOGE P2Pool 0% nogleg.net:9555
2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
August 16, 2012, 11:23:25 PM
 #8

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Transisto
Donator
Hero Member
*
Offline Offline

Activity: 1134



View Profile WWW

Ignore
August 17, 2012, 10:09:01 AM
 #9

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.

Visit and contribute to reddit.com/r/Bitcoin
grue
Moderator
Hero Member
*
Offline Offline

Activity: 1036


It is pitch black. You are likely to be eaten by a grue.


View Profile

Ignore
August 17, 2012, 02:03:06 PM
 #10

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...

1ELvnrA6PhUyDBS6iR25K1Xx4xXL6VMfJX
2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
August 17, 2012, 02:21:14 PM
 #11

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
scintill
Sr. Member
****
Offline Offline

Activity: 446


View Profile WWW

Ignore
August 17, 2012, 05:00:08 PM
 #12

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.

1SCiN5kqkAbxxwesKMsH9GvyWnWP5YK2W | donations
HeavyMetal
Jr. Member
*
Offline Offline

Activity: 42



View Profile

Ignore
August 25, 2012, 12:27:49 AM
 #13

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

1AuAgBTU8FJ2oHM4iwRRa5SJVTbuKV8htr - Bitcoins to this address go to the purchase of Silver.
Transisto
Donator
Hero Member
*
Offline Offline

Activity: 1134



View Profile WWW

Ignore
August 25, 2012, 12:31:58 AM
 #14

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

Visit and contribute to reddit.com/r/Bitcoin
racerguy
Sr. Member
****
Offline Offline

Activity: 271


View Profile

Ignore
August 25, 2012, 05:36:59 PM
 #15

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

Activity: 1134



View Profile WWW

Ignore
August 25, 2012, 08:50:01 PM
 #16

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.

Visit and contribute to reddit.com/r/Bitcoin
Raoul Duke
aka psy
Global Moderator
Hero Member
*
Offline Offline

Activity: 1078


XBT.pt - BTC/DOGE


View Profile WWW

Ignore
August 25, 2012, 08:58:56 PM
 #17

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? Tongue

racerguy
Sr. Member
****
Offline Offline

Activity: 271


View Profile

Ignore
August 26, 2012, 07:53:18 PM
 #18

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
Member
**
Offline Offline

Activity: 70


View Profile

Ignore
August 27, 2012, 05:34:50 PM
 #19

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
Hero Member
*****
Offline Offline

Activity: 1022



View Profile WWW

Ignore
August 28, 2012, 11:53:46 PM
 #20

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.

http://we.lovebitco.in/how-bitcoin-works/
1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5
"A Part of Us Remains Wherever We Have Been" - fortune cookie
Pages: [1] 2  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!