<p>Full nodes are not required to store blocks (they can be pruned). So the answer is <strong>0</strong>.</p>

<p>If a 200 kB block does get stored, it takes 200 kB to store it.</p>

CC BY-SA 4.0
2018-05-08T21:17:56.397Z
Can we assume this new block will be stored locally on some full node somewhere, ultimately.  Which is it 200K 0r 2MB? Thanks very much for your time.
jimhash
CC BY-SA 4.0
2018-05-08T21:20:10.793Z
It will be stored somewhere. But not nearly every full node needs to keep it for eternity.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T21:21:32.003Z
How much space will it take when it does get stored?
jimhash
CC BY-SA 4.0
2018-05-08T21:22:29.010Z
That seems like a trivial question, but I've updated my answer.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T21:39:52.390Z
It's also mostly irrelevant in that debate - which is about costs related to bandwidth (full nodes need to download all blocks, even if they don't store them), validation costs, impact on growth of the UTXO set, ...
Pieter Wuille
CC BY-SA 4.0
2018-05-08T21:43:05.880Z
So in this example, the node in question is only downloading 200k, not 2MB, is that also correct?
jimhash
CC BY-SA 4.0
2018-05-08T21:43:41.407Z
Yes, why do you keep repeating 2MB? A 200kB block is 200kB.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T21:47:31.250Z
Part of what I'm trying to get to the root of is ***whether or not*** block size where doubled on BitCoin Core say or quartered on BitCoin Cash the ***actual*** resource requirements (and cost) would differ or not.
jimhash
CC BY-SA 4.0
2018-05-08T21:50:25.543Z
The reason resource limits like block weight exist is to prevent miners from increasing resource costs needed for full nodes - as that would amount to full nodes effectively accepting becoming powerless themselves. As including transactions in a block has effectively zero cost for a miner, and Bitcoin's design relies on not trusting miners, we should care about the worst-case situation where all blocks are full - even if that situation isn't reached in the short term. A resource limit increase isn't something that can be easily undone after it already hurts centralization.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T21:56:19.380Z
But if miners do a cost-benefit analysis of sha-2 work (effort), it increases linearly as the amount of transactions packed into a single block increases (as I understand it), and further diminishes the chance of reward.  I may be operating under the mistaken assumption that this cost-benefit analysis results in the natural choice of smaller blocks (changing as a function of transaction cost).  Thank you again very much for your time.
jimhash
CC BY-SA 4.0
2018-05-08T21:58:18.910Z
No, their amount of SHA256 work is independent of the number of transactions. Also, since the introduction of efficient block relay protocols like BIP152 and Fibre the speed of block propagation is also (almost) independent of their size. There is no rational reason why miners shouldn't include each and every transaction that they can if it pays them. If they don't, a competitor may include it, in which case they'll still pay all the cost, but lose the benefit.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T22:01:05.743Z
I thought SHA-2 work was a function of message size.  Are you saying that if one message has length L and another has length 2L, that the second message doesn't take twice as long to compute a digest for?
jimhash
CC BY-SA 4.0
2018-05-08T22:06:06.087Z
Yes, it is dependent. But we first hash all the transaction together into the Merkle root, and then hash _that_ many times to find a good block. There are maybe 100000 SHA256 transforms necessary to compute the Merkle root and almost 1000000000000000000 after that to find a block. The cost of hashing the transactions is completely irrelevant compared to the total effort of producing a block.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T22:11:42.940Z
This is getting off topic and too long for comments. I suggest you spend some time reading more on this site and elsewhere about the details of Bitcoin's operation.
Pieter Wuille
CC BY-SA 4.0
2018-05-08T22:17:28.823Z
Ok, sorry thanks, so hash effort/work then is dominated by the hashing of intermediate Merkle root result(s) rather than on the transaction payload in the block, so the payload hashing is (relatively) insignificant by comparison. I think this is sinking in, thanks.  I'm going to go read about that.  Thanks again for all of your time -- have a good one!
jimhash
CC BY-SA 4.0
2018-05-08T21:12:44.930Z
2018-05-08T21:22:00.787Z
2018-05-08T21:22:00.787Z
Pieter Wuille
<p><strong><em>If</em></strong> blocks were 2MB, and a 2MB block that is only 10% full gets confirmed, then how much additional storage is required on a <strong><em>full node</em></strong>?</p>

<p>I am guessing the correct answer here is 200K?</p>

<p>Thanks in advance for any guidance in this matter.</p>

CC BY-SA 4.0
2018-05-08T21:12:09.653Z
What is a 2MB block that is only 10% full? Isn't that just a 200k block?
Pieter Wuille
<bitcoin-core><block><bitcoin-cash><full-node><scalability>
Full node storage requirements for new 2MB block which is only 10% full
jimhash
# Full node storage requirements for new 2MB block which is only 10% full

(Asked by: username_0 on 2018-05-08)

***If*** blocks were 2MB, and a 2MB block that is only 10% full gets confirmed, then how much additional storage is required on a ***full node***?

I am guessing the correct answer here is 200K?

Thanks in advance for any guidance in this matter.

**Tags:** bitcoin-core, block, bitcoin-cash, full-node, scalability

> **Comments:**
> **username_1**: What is a 2MB block that is only 10% full? Isn't that just a 200k block?  

---

## 1 answers

### Answer by username_1 on 2018-05-08. Score: 1

Full nodes are not required to store blocks (they can be pruned). So the answer is **0**.

If a 200 kB block does get stored, it takes 200 kB to store it.

> **Comments:**
> **username_0**: Can we assume this new block will be stored locally on some full node somewhere, ultimately.  Which is it 200K 0r 2MB? Thanks very much for your time.  
> **username_1**: It will be stored somewhere. But not nearly every full node needs to keep it for eternity.  
> **username_0**: How much space will it take when it does get stored?  
> **username_1**: That seems like a trivial question, but I've updated my answer.  
> **username_1**: It's also mostly irrelevant in that debate - which is about costs related to bandwidth (full nodes need to download all blocks, even if they don't store them), validation costs, impact on growth of the UTXO set, ...  
> **username_0**: So in this example, the node in question is only downloading 200k, not 2MB, is that also correct?  
> **username_1**: Yes, why do you keep repeating 2MB? A 200kB block is 200kB.  
> **username_0**: Part of what I'm trying to get to the root of is ***whether or not*** block size where doubled on BitCoin Core say or quartered on BitCoin Cash the ***actual*** resource requirements (and cost) would differ or not.  
> **username_1**: The reason resource limits like block weight exist is to prevent miners from increasing resource costs needed for full nodes - as that would amount to full nodes effectively accepting becoming powerless themselves. As including transactions in a block has effectively zero cost for a miner, and Bitcoin's design relies on not trusting miners, we should care about the worst-case situation where all blocks are full - even if that situation isn't reached in the short term. A resource limit increase isn't something that can be easily undone after it already hurts centralization.  
> **username_0**: But if miners do a cost-benefit analysis of sha-2 work (effort), it increases linearly as the amount of transactions packed into a single block increases (as I understand it), and further diminishes the chance of reward.  I may be operating under the mistaken assumption that this cost-benefit analysis results in the natural choice of smaller blocks (changing as a function of transaction cost).  Thank you again very much for your time.  
> **username_1**: No, their amount of SHA256 work is independent of the number of transactions. Also, since the introduction of efficient block relay protocols like BIP152 and Fibre the speed of block propagation is also (almost) independent of their size. There is no rational reason why miners shouldn't include each and every transaction that they can if it pays them. If they don't, a competitor may include it, in which case they'll still pay all the cost, but lose the benefit.  
> **username_0**: I thought SHA-2 work was a function of message size.  Are you saying that if one message has length L and another has length 2L, that the second message doesn't take twice as long to compute a digest for?  
> **username_1**: Yes, it is dependent. But we first hash all the transaction together into the Merkle root, and then hash _that_ many times to find a good block. There are maybe 100000 SHA256 transforms necessary to compute the Merkle root and almost 1000000000000000000 after that to find a block. The cost of hashing the transactions is completely irrelevant compared to the total effort of producing a block.  
> **username_1**: This is getting off topic and too long for comments. I suggest you spend some time reading more on this site and elsewhere about the details of Bitcoin's operation.  
> **username_0**: Ok, sorry thanks, so hash effort/work then is dominated by the hashing of intermediate Merkle root result(s) rather than on the transaction payload in the block, so the payload hashing is (relatively) insignificant by comparison. I think this is sinking in, thanks.  I'm going to go read about that.  Thanks again for all of your time -- have a good one!  

---

