Not per connection no. Once you have a block from one peer you don't need to download it from another peer.
One download, one upload, on average.
Topic: 84 Gigabytes Per Month, Per Connection (Read 2654 times)
That's what 20 MB blocks require. That means, you receive the blockchain, that's 84 gigabytes per month. You send the blockchain to one peer, that's another 84 gigabytes per month.
This post is very misleading.
Just because block sizes are allowed to be 20 MB doesn't mean they will. That would take a hell of a lot of transactions to create a 20 MB block.
If the block size was 20 MB right now then it would make no difference if there's still only 500-2000 transactions per block.
By the way if we do start seeing 20 MB block sizes at some point in the distant future after they have been enabled the time to increase this limit from 20 GB to 40+ GB block sizes will have long passed.
1) Not all users need to run a full node. Most of them don't
2) It will take a long time before (and if) we have 20mb blocks. I don't expect that before 2020.
3) Connection speed and hardware advance fast. If I am not wrong average global internet speed when blockchain was started was ~3mb/s and now is well over 20mb/s. Many people have cheap 100mb/s already. I expect 250mb/s to be average by 2020. 84 gigabytes = 75% of an hour to be downloaded @ 250mb/s speed.
4) Even so, I think scalability is an issue and we need to look into further more efficient measures such as pruning
2) It will take a long time before (and if) we have 20mb blocks. I don't expect that before 2020.
3) Connection speed and hardware advance fast. If I am not wrong average global internet speed when blockchain was started was ~3mb/s and now is well over 20mb/s. Many people have cheap 100mb/s already. I expect 250mb/s to be average by 2020. 84 gigabytes = 75% of an hour to be downloaded @ 250mb/s speed.
4) Even so, I think scalability is an issue and we need to look into further more efficient measures such as pruning
the OP was referring to transfer of the entire block chain so I didn't realize it had abstracted from that to discussion on new blocks with the initial block chain being separate.
He may have been unclear, but it is 84GB "per month". It wasn't about initial download.
144 blocks per day * 30 days per month * 20 MB per block = 84.375 GB per month.
Quote
I had meant unless 5000(or more specifically, equivalent to however many nodes there are) new nodes were added, there wouldn't be a 1:1 ratio of transfer of the entire block chain.
Just to stay synced (assuming maximum size blocks), you need to download 84GB. Unless you plan to leech (in the Bit-torrent meaning of the word), you need an upload to download ratio of at least 1.0, which means an upload of at least 84GB too.
If no new nodes join the network, then you are correct, initial download doesn't add anything. Even if the number of nodes stays constant, it is likely that some full nodes will drop out to be replaced by other full nodes. In addition, some (potential) full nodes won't stay online all the time, so they push up the ratio for everyone else.
To contribute to the network a full node needs to stay online and be accessible by SPV clients. Running a full node which doesn't accept incoming connections uses up slots on full nodes which do.
Using the reference client as a wallet means downloading the chain in short bursts and probably having an upload ratio of less than 1.0.
SPV clients are leechers in the pure network sense of the term, but they contribute to the network by increasing use of the currency. They probably won't consume much extra bandwidth by an increased block size.
84GB per month is a lot. This would lead to growth in full nodes or centralization of the system. Do you think all blocks will be 20M? There may be smaller and bigger blocks in the blockchain?
the OP was referring to transfer of the entire block chain so I didn't realize it had abstracted from that to discussion on new blocks with the initial block chain being separate.
He may have been unclear, but it is 84GB "per month". It wasn't about initial download.
144 blocks per day * 30 days per month * 20 MB per block = 84.375 GB per month.
Quote
I had meant unless 5000(or more specifically, equivalent to however many nodes there are) new nodes were added, there wouldn't be a 1:1 ratio of transfer of the entire block chain.
Just to stay synced (assuming maximum size blocks), you need to download 84GB. Unless you plan to leech (in the Bit-torrent meaning of the word), you need an upload to download ratio of at least 1.0, which means an upload of at least 84GB too.
If no new nodes join the network, then you are correct, initial download doesn't add anything. Even if the number of nodes stays constant, it is likely that some full nodes will drop out to be replaced by other full nodes. In addition, some (potential) full nodes won't stay online all the time, so they push up the ratio for everyone else.
To contribute to the network a full node needs to stay online and be accessible by SPV clients. Running a full node which doesn't accept incoming connections uses up slots on full nodes which do.
Using the reference client as a wallet means downloading the chain in short bursts and probably having an upload ratio of less than 1.0.
SPV clients are leechers in the pure network sense of the term, but they contribute to the network by increasing use of the currency. They probably won't consume much extra bandwidth by an increased block size.
The overall ratio of transfer will be much less than 1:1.
No matter how many full nodes you have on the network, each of them has to download every new block. This means that the number of blocks downloaded divided by the number of nodes has to be at least 1.
It could be higher if some nodes download the same block from more than 1 node.
This is separate from the initial download. Some storage nodes are needed for bootstrapping.
Sorry I misinterpreted the discussion.... -- the OP was referring to transfer of the entire block chain so I didn't realize it had abstracted from that to discussion on new blocks with the initial block chain being separate. I had meant unless 5000(or more specifically, equivalent to however many nodes there are) new nodes were added, there wouldn't be a 1:1 ratio of transfer of the entire block chain.
The overall ratio of transfer will be much less than 1:1.
No matter how many full nodes you have on the network, each of them has to download every new block. This means that the number of blocks downloaded divided by the number of nodes has to be at least 1.
It could be higher if some nodes download the same block from more than 1 node.
This is separate from the initial download. Some storage nodes are needed for bootstrapping.
current block size has little to do with real usage.
There are people pushing megabytes of plain text in transactions just for fun.
(example of someone spamming the blockchain with the text of Gavin's rationale for increasing the limit)
These, dust-spammers and tx chains by people who mistakenly think chains
help "mixing" are almost filling the 1 MB limit now, and they can easily fill 20 MB blocks as well.
Until there is a reasonably-behaved market for transactions, it seems
opportunistic increasing the block size limit, even if the bandwidth/storage are not a problem for most.
There are people pushing megabytes of plain text in transactions just for fun.
(example of someone spamming the blockchain with the text of Gavin's rationale for increasing the limit)
These, dust-spammers and tx chains by people who mistakenly think chains
help "mixing" are almost filling the 1 MB limit now, and they can easily fill 20 MB blocks as well.
Until there is a reasonably-behaved market for transactions, it seems
opportunistic increasing the block size limit, even if the bandwidth/storage are not a problem for most.
In the end it's a 1:1 ration , with some peers uploading 50x times more than they download and peers not uploading anything.
You could say the requirements for running a full node will be going down, as well. A great deal of nodes are going to operate in pruned mode. Sure. some nodes will receive the full chain from several sources, but what about the great deal of nodes that will only hold 1-2GB? The overall ratio of transfer will be much less than 1:1. Your also ignoring a very important factor: Nodes are already up. If you add a new node to the network, and it had to get 84GB, it has 5000 nodes to do it from, not like it some crazy stress to the network. If your unable to download '84GB' or whatever the real number would be, than you can operate a full pruned node with just a few GB, or SPV client.
I don't think 84GB is that much... most connections nowadays can perfectly handle that. Connections that currently host nodes can certainly handle that. And all this considering all blocks will be full...
Come on, let's just switch this
Come on, let's just switch this
That's what 20 MB blocks require. That means, you receive the blockchain, that's 84 gigabytes per month. You send the blockchain to one peer, that's another 84 gigabytes per month.
You don't have to send all blocks to all peers. You send the block hash to all the peers, and only those who haven't already got it will ask you to send the full block.
On average, each node forwards it to one other node.
If your node is very well connected, then it may receive blocks earlier than others. In that case, more of your peers will ask you for the block.
If each node limited the number of forwards, then bandwidth could be kept low. If each node forwarded new blocks to 2 peers, then the blocks would still be flooded over the network.
It could have a long and short term setting.
This means that it can forward a new block up to 10 peers, but not if it has forwarded more than 2X blocks on average over the last 24 hours.
When a new block is received, it would add 2 to the block forwarding counter, up to a maximum of 288. When a block is forwarded, it would decrement the total by 1. Once the number hits zero, it would send a reject message when asked for a block.
Connecting to a node multiple times and asking for blocks could be used to consume all the slots. To prevent a DOS attack, outgoing nodes would have to be given priority.
[Edit]
Thinking more, at minimum, the node would have to download 84GB per month just to stay synced, so 168GB per month on average per node (assuming average forwarding to one other node).
i would prefer bitcoin to be laissez faire, unfortunately the powers that be, need this extra space to monetize the blockchain.
IF.. AND WHEN.. AND IF EVER! we got to a point of adoption where transactions didn't confirm without higher and higher fees then bitcoin would be a success and spam and penny posts can move to side chains and alts.
expanding the blockchain to allow more space that is not required to take advantage of it like a whore that you don't have to pay can only hurt bitcoin in the end.
IF.. AND WHEN.. AND IF EVER! we got to a point of adoption where transactions didn't confirm without higher and higher fees then bitcoin would be a success and spam and penny posts can move to side chains and alts.
expanding the blockchain to allow more space that is not required to take advantage of it like a whore that you don't have to pay can only hurt bitcoin in the end.
Easiest research ever
Block / transaction
355149 52
355145 174
355144 188
355143 98
355137 77
Even easier, and more accurate:https://blockchain.info/charts/n-transactions-per-blockBlock / transaction
355149 52
355145 174
355144 188
355143 98
355137 77
Which part of your own statment you're having trouble understand?
Miners are definitely not adding less than 100 transactions in a block.
I'll just say that I really didn't intend to argue one way or another with this post. I do have my preferences. But I just wanted to present a few facts regarding blocksize increase, in a way that perhaps some of you hadn't considered before. Don't get caught up in the hoopla of choosing sides. We're all ultimately on the same side.
Easiest research ever
Block / transaction
355149 52
355145 174
355144 188
355143 98
355137 77
Even easier, and more accurate:https://blockchain.info/charts/n-transactions-per-block Block / transaction
355149 52
355145 174
355144 188
355143 98
355137 77
@^
Can you explain the details of why miners might not want to include transactions? Does it make it harder to solve a block? Or something else?
Either way, when the block rewards lower significantly, at that time, miners will be forced to accept more transactions, no?
Can you explain the details of why miners might not want to include transactions? Does it make it harder to solve a block? Or something else?
Either way, when the block rewards lower significantly, at that time, miners will be forced to accept more transactions, no?
Beyond a certain point larger blocks incur an increasing risk of getting orphaned if they take too long to propagate across the network.
And double that.
Because the customer pays to random generated address , then seller has to collect all coins in one place.
While it might look small , it will be enough for a lot of miners to exclude a lot of transactions just to have their solved block accepted first and a lot of miners would not even think of including 4MB of transactions in one block.
Actually, it would not have to be double that, they could all send the bitcoin to the same address. Or, once a day, one large transaction is created which consolidates all of the bitcoin in one address. There would only be a massive transaction fee for including so many inputs. Double the transactions is not necessary.Because the customer pays to random generated address , then seller has to collect all coins in one place.
While it might look small , it will be enough for a lot of miners to exclude a lot of transactions just to have their solved block accepted first and a lot of miners would not even think of including 4MB of transactions in one block.
We are seeing this already with the transaction pool running in thousands and miners adding only <100 in their solved block.
Where are we seeing this? I don't see anywhere where miners are dropping transactions because there are too many. I see them dropping transactions for low or no fees. Miners are definitely not adding less than 100 transactions in a block. In fact, there are between 500 and 900 transactions per block on average. I don't know where you are getting that number, but I suggest you do some research before posting.Easiest research ever
Block / transaction
355149 52
355145 174
355144 188
355143 98
355137 77
And double that.
Because the customer pays to random generated address , then seller has to collect all coins in one place.
While it might look small , it will be enough for a lot of miners to exclude a lot of transactions just to have their solved block accepted first and a lot of miners would not even think of including 4MB of transactions in one block.
Actually, it would not have to be double that, they could all send the bitcoin to the same address. Or, once a day, one large transaction is created which consolidates all of the bitcoin in one address. There would only be a massive transaction fee for including so many inputs. Double the transactions is not necessary.Because the customer pays to random generated address , then seller has to collect all coins in one place.
While it might look small , it will be enough for a lot of miners to exclude a lot of transactions just to have their solved block accepted first and a lot of miners would not even think of including 4MB of transactions in one block.
We are seeing this already with the transaction pool running in thousands and miners adding only <100 in their solved block.
Where are we seeing this? I don't see anywhere where miners are dropping transactions because there are too many. I see them dropping transactions for low or no fees. Miners are definitely not adding less than 100 transactions in a block. In fact, there are between 500 and 900 transactions per block on average. I don't know where you are getting that number, but I suggest you do some research before posting.
@^
Can you explain the details of why miners might not want to include transactions? Does it make it harder to solve a block? Or something else?
Either way, when the block rewards lower significantly, at that time, miners will be forced to accept more transactions, no?
Can you explain the details of why miners might not want to include transactions? Does it make it harder to solve a block? Or something else?
Either way, when the block rewards lower significantly, at that time, miners will be forced to accept more transactions, no?
Looking at another chart :
https://blockchain.info/en/charts/n-transactions-excluding-chains-longer-than-10?showDataPoints=false×pan=&show_header=true&daysAverageString=7&scale=0&address=
Seems like there are only 30k real transactions per day in bitcoinland.
Let's assume 1 pf every 100 McDonalds customers would pay in bitcoin....
Care to tell me what would be the size of the blocks?
McDonalds serves about 69 million customers per day, according to their company profilehttps://blockchain.info/en/charts/n-transactions-excluding-chains-longer-than-10?showDataPoints=false×pan=&show_header=true&daysAverageString=7&scale=0&address=
Seems like there are only 30k real transactions per day in bitcoinland.
Let's assume 1 pf every 100 McDonalds customers would pay in bitcoin....
Care to tell me what would be the size of the blocks?
If one out of every 100 customers paid with bitcoin: 69000000 / 100 = 690000 transactions per day
Assuming that the transactions are spread equally throughout the day: 690000 / 144 = 4791.667 ~ 4792 transactions per block
Assuming that the transactions are standard and the average transaction size is 250 bytes (0.25 KB): 4792*.25 = 1198 KB in transactions
Adding this extra size to average block size: 1.198 + 0.5 = 1.698 MB.
The block size would then be about 1.698 MB, not that much larger than the current maximum, and most certainly not up to 20 MB. Even with that many transactions, it still would not take up a lot of bandwidth, but eventually, over time, like the current blockchain, these transactions will cause the blockchain to grow in size, but it is already doing that.
*Note: these numbers are both rounded up and chosen from the highest numbers on blockchain.info's charts for the past year.
And double that.
Because the customer pays to random generated address , then seller has to collect all coins in one place.
While it might look small , it will be enough for a lot of miners to exclude a lot of transactions just to have their solved block accepted first and a lot of miners would not even think of including 4MB of transactions in one block.
We are seeing this already with the transaction pool running in thousands and miners adding only <100 in their solved block.
Jump to: