9

If your goal is just to get a stable Bitcoin node running, and not to contribute to the network, you can add listen=0 to your bitcoin.conf file. This generally (though not always) keeps your upload bandwidth in check. If you want to contribute to the Bitcoin network without using up too much of your own bandwidth, however, there are ways of limiting your ...


7

While nodes are set to be listening by default, the vast majority does not permit inbound connections either because listening has been disabled or their network setup doesn't make the necessary port accessible. There seem to be in the range of 8-10k listening nodes, while estimates for non-listening nodes range in 60-400k depending on the source. Next to ...


6

If you mine with a pool, your actual internet activity will be fairly small. I just took a look at my network statistics and BFGMiner used 9MBytes down and 11 MBytes up over the previous 24-hour period. The Bitcoin-Qt application on the other hand maxes out my upload bandwidth since I always seem to get 2-3 peers who want to download the entire 12 GB ...


5

This is a possible issue. Currently we have a block limit in size of 1Mb although many pools send out 250Kb to make their block propagate faster to avoid orphaned blocks. This gives us a cap of 7 transactions per second, data usage of 6Mb per hour or 144Mb a day, almost negligible amount of bandwidth. Visa on average handles 2000 per second. So looking ...


5

I don't think any such study exists, because it is very difficult to gain any concrete information about full nodes on the network. Because nodes can (and often are) run over proxies or TOR, their true IP addresses are often obscured. Furthermore, IP addresses aren't necessarily a good indicator of geographic location, and certainly not connection speed. ...


5

The RPC interface has a command getpeerinfo which will give a breakdown of upload and download metrics per connected peer. { .. "bytessent": 67619177, "bytesrecv": 47229533, "conntime": 1446238156, .. } Totals for the session for all peers are available with getnettotals. { "totalbytesrecv": 3664310320, "...


4

According to Greg Maxwell: 4.14kB/sec in, 10.7kb/s out; averaged over the last 30 days. 38GB in transfer total. Significantly less than the full node that goes with it... p2pool used to be fairly large relative to the node; but greater amounts of load on the Bitcoin network have shifted the balance.


4

Bitcoin Core is full node software. This means that it will download, validate, and keep up with every transaction made in Bitcoin's history and future. Its goal is independence: if you run a node, you know that everything you see adds up (no theft, no money created out of nothing, ...), without relying on anyway else's judgement. However, it comes at the ...


3

Bandwidth - You need to receive an 80-byte header about every 10 minutes. In addition, if you want to spend, you will get SPV proofs that range about 500-1000 bytes per utxo. In other words, the bandwidth requirements are really tiny. Storage - Each block header is 80 bytes, as of this writing, there are less than 430,000 blocks, so 80 * 430,000 = 35.4 MB. ...


3

Bitcoin mining doesn't require much bandwidth at all! It's worth noting that the higher the hash-rate of your rig, the more bandwidth it will require (as you will get through work units faster - downloading new ones and feeding back more frequently). Seeing as though you are planning to use guiminer, you most likely won't use much bandwidth (most high-...


3

Absolutely not. The bandwidth required to mine Bitcoin is very low as shown here: What are the bandwidth requirements of a mining rig? So that's 700 bits per second out and about 2,000 bits per second back. Essentially, zero. This means that your son can mine 24/7 and your daughter won't notice any slowdowns whatsoever.


3

Is there a way to find out which blk*.dat file contains a particular block? We can't tell you which of your *.dat files contains block 478558 because there is no requirement that different nodes store their data in the same way. Two installations of the same software (e.g. Bitcoin core) could have different blocks in a blk*.dat file of the same name. In ...


2

Alternatives to downloading the data yourself in reference client: Take your computer to somewhere with Internet that you can be for several hours, perhaps a friend or relative's house, or a library or coffee shop. You can employ bootstrap.dat by having someone else download it and give it to you somehow. Then you'd only have to get caught up and download ~ ...


2

With solo mining, all you need to get from the Internet is the latest block. Since these come once every 2.5 minutes (average) and are at most 250 KB (typically ~10 KB), you should be just fine. You'd also want to get all the latest Litecoin network traffic in order to validate all the transactions you can, but that'd be pretty small, like the blocks. You ...


2

1 Meg Internet can connect 150 S9. 1S9 could use upto 300M per month of data


2

That would indeed create a lot of data. However, there are solutions for this. First of all, as a normal consumer you don't store the blockchain anyways. Only some nodes like Bitcoin services and generally those who choose to store the blockchain. Secondly, even as a miner, keeping the UTXO pool available fast is important. They don't need the entire ...


2

Apart from a few cryptocurrencies, including Bitcoin, most of them have very low exchange rates. So although you will find many such virtual currencies, it won't be profitable either way. And mining does not require bandwidth as such, it's only the blockchain synchronization which would be slower with a lower bandwidth. Mining is achieved by your machine and ...


2

A search for definitive information turned up literally nothing, so, what happens when transaction bandwidth is exceeded for an extended period? The same thing as always happens: miners decide, at their own discretion, which transactions to include in their blocks. Most likely they will choose those that have the highest fees. Transactions that don't go ...


1

CPU is basically the only thing that matters. The memory requirements for mining are trivial (enough to run bitcoind; SHA256 uses only a few bytes of memory). Having more that enough will add no benefit. Disk performance is nearly irrelevant also. A fast network connection may help you get new blocks a little bit faster. This is helpful because the ...


1

The reason I added that section to my article is because Gavin Andresen, one of the Bitcoin Core developers, suggested in response to it that limiting bandwidth too much could be detrimental to the network because it slows block announcements: gavinandresen @maxlaumeister limiting number of connections is better for the network, limiting bwidth slows block ...


1

It does not hurt the network; it just helps it less than the maximum potential amount you theoretically could be helping it.


1

It would seem to me as though every contributing full node would only help the network (regardless of ISP speed). Does limiting the bandwidth of Bitcoin Core actually hurt the network, and if so, how precisely? Not necessarily, but if everyone did it then yes. If everyone actually trottled upload bandwidth so much that there is not sufficient bandwidth to ...


1

SPV clients are thin clients that do not need to hold the full blockchain. They use other nodes on the network to validate transactions. SPV clients are available for Android and require a lot less disk space. Of course it is more secure for you and for the network to run a full node.


1

Hash rate measures how fast your miner can attempt to find a nonce that satisfies the proof of work. The speed at which it performs this task is not related to network bandwidth. It does not perform a network operation per hash. Bitcoin mining still requires network usage, however. Your miner will request a unit of work from the mining pool, which is ...


1

Bitnodes attempts to estimate the size of the network and aggregates data including, country, IP geolocation, version of bitcoin software etc. You may be able to use IP information to determine what types of connections are being used. Obviously this is only public facing nodes. They can be used to query peer information and learn about other nodes that ...


1

If you're running two bitcoind instances on one machine, depending on the use case, you may instead be better off by connecting one to the other only, and not make it talk to the network. This will reduce the total bandwidth used significantly, as every block and transaction will only be fetched once. Run the first one normally, and use -connect=127.0.0.1:...


1

The new option is called maxuploadtarget. It joins maxconnections and listen in the list of things that can be used to control the bandwidth and resource usage of your Bitcoin client. maxuploadtarget controls the bandwidth used in a much more precise way than was previously possible without external tools. maxuploadtarget is off by default. You don't need ...


1

I havent seen a proper answer on the internet so I did the test myself using bitcoin-0.18.1 with the -testnet flag and after downloading the chain ~2 GB I monitored the traffic of the bitcoind process with nethogs for 24 hours. I got 40MB download and 20MB uploads so 60*30 = 1800MB You can expect 1.8GB of traffic from the bitcoin testnet compared to the ...


1

I think your 3G speeds should work pretty well. They usually do not require fast internet connections.


1

The initial sync only needs to happen once, launches after a full synchronization will just catch up on the data that you've missed.


Only top voted, non community-wiki answers of a minimum length are eligible