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 – 2018-05-08T21:17:56.397

It will be stored somewhere. But not nearly every full node needs to keep it for eternity. – Pieter Wuille – 2018-05-08T21:20:10.793

How much space will it take when it does get stored? – jimhash – 2018-05-08T21:21:32.003

That seems like a trivial question, but I've updated my answer. – Pieter Wuille – 2018-05-08T21:22:29.010

Agreed, though I haven't seen it spoken about anywhere in any of the block size debates I've seen, sorry. To me this question cuts to the heart of the debate, exposing some arguments as irrational. I thought I knew the answer, but I appreciate that you (with all of your credibility and greatness of learning) answered it. Thanks again! – jimhash – 2018-05-08T21:38:41.373

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 – 2018-05-08T21:39:52.390

So in this example, the node in question is only downloading 200k, not 2MB, is that also correct? – jimhash – 2018-05-08T21:43:05.880

Yes, why do you keep repeating 2MB? A 200kB block is 200kB. – Pieter Wuille – 2018-05-08T21:43:41.407

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 – 2018-05-08T21:47:31.250

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 – 2018-05-08T21:50:25.543

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 – 2018-05-08T21:56:19.380

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 – 2018-05-08T21:58:18.910

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 – 2018-05-08T22:01:05.743

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 – 2018-05-08T22:06:06.087

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 – 2018-05-08T22:11:42.940

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 – 2018-05-08T22:17:28.823