Yes, absolutely! Compact blocks is about the most sane scheme we've seen, and we'll likely implement something exactly like that.
For those that don't know how it works, the basic idea is that your node has likely already received most of the transactions in a newly mined block. So instead of receiving them all over again, a node will send the block header ...
Bandwidth utilization greatly depends upon whether or not inbound ports are opened up or not.
On a fast 10gbit+ VPS with inbound ports opened up, I see 280 GB inbound and 250 GB outbound used.
On a residential connection with 8 outbound connections and zero inbound, I see less than 10GB inbound / outbound used in 30 days.
Monero transaction confirmations are very quick on modern computers. With LMDB estimates from developers Smooth and NoodleDoodle are that Monero can handle 1700 TPS (up from 1600 TPS pre LMDB).
Confirmation time is definitely not the limiting factor. Many nodes do not have the bandwidth to support 1700 TPS based on current transaction sizes.
Monero can ...
You can set this when you start the daemon I believe:
Typing monerod --help and scrolling down shows you there are these options:
So to limit your bandwidth you could type: monerod --limit-rate 100 to limit up and downstream activity to 100kB/s each way. Or you can set them individually as shown.
Solo mining requires running a full node, pool mining does not. Also, when solo mining, it will usually take much longer to find a block when compared to a pool. Pools do charge a fee, normally 1-2% of the block reward.
When pool mining on a Windows PC, I use less than 20 Mb/day download and less than 5 Mb/day upload. Solo mining will be more bandwidth ...
This post should help you a lot. It discusses how to set bandwidth limits.
You can change them, either when starting monerod:
--limit-rate-up arg (=-1) set limit-rate-up [kB/s]
--limit-rate-down arg (=-1) set limit-rate-down [kB/s]
--limit-rate arg (=-1) set limit-rate [kB/s]
or at runtime (while monerod is already ...
Adding to the previous answer, those TPS estimates assume an Intel i7 2600k quad core processor. So roughly 400 TPS per core. That processor is from 2011, so I assume that this figure will improve with newer processors, as well scale with more cores. Note that these are just tx verification times, bandwidth is a whole different issue.
I would say that ...
Bandwidth is currently the limiting factor.
Assuming an average transaction size of around 15 KiB, nodes can handle ~8 tx/s with every Mbit/s connection speed.
There is no real answer to how many transactions per second the network can "theoretically" handle though. A higher transaction rate means higher requirements, whether it's bandwidth, CPU or disk ...
All of these are measured in kB (1024 bytes). See src/p2p/net_node.inl, in set_rate_up_limit.
The defaults are 2048 kB/s upload, and 8192 kB/s download. If those are near or above your connection's capabilities, you may want to lower them to a bit lower, to keep some QoS. Similarly if you have a fast connection, you might want to increase them.
Yes, RingCT transactions are much bigger than non-RingCT transactions. The monthly blockchain growth has already more than doubled in comparison to December 2016, when RingCT hasn't been enabled yet.
Why are you hosting more than one full node at home? You just need one full node and all your local machines can connect to it via local network.
Your understanding is correct: outgoing connections are initiated by you, incoming connections are initiated by the peer. You can certainly have a peer syncing from you via an outgoing connection though.
The 800 connections is just a bug in the accounting. They're not all actual connections. You can see that using netstat or similar tool.
When a node is ...
monerod takes a lot of bandwidth during the initial sync. If you're unable to browse or use any applications that require internet connection, you can limit monerod's bandwidth as follows:
Go to the Settings page of the GUI.
Look for the daemon startup flags box.
Add this line -> --limit-rate 500
Exit the GUI and make sure to stop the daemon as well.
The --hide-my-port option is used to prevent incoming connections of peers to your node, which would reduce traffic if your node could receive incoming connections.
But if your node is behind a router without port forwarding, it already can't receive incoming connections, therefore the --hide-my-port option won't have any extra effect on traffic reduction.
If you update to the coming release, and if the remote node you're using is using a recent daemon (the one that'll come with that release), the bandwidth will be much less when refreshing the wallet.
For current blocks (ie, after the ringct change), the bandwidth should be less than 5% what it was.