<p>Tl:dr<br />
How did Satoshi/the community decide an appropriate block-size-limit?<br />
Why does the protocol increase mining difficulty by adding zeros?</p>
<hr />
<p>I've some limited experience with some of the cryptographic concepts underlying bitcoins protocols.<br />
I have two questions.</p>
<p>Given the fact that there is an upper limit on block size, perhaps the easiest way to breach this is to arrive at an some exceedingly large nonce which will become necessary due to other block contents.<br />
<strong>The question is</strong>, how do you set an appropriate limit for arbitrary blocks?<br />
Would you need to know about inverting the hashing-algorithm in order to prove the efficacy of a given limit for an arbitrary ledger/header/nonce set?</p>
<hr />
<p>Second question is about the relevance of increasing the leading zeros over time.</p>
<p>Would it not be equivalent (wrt work done) to set a total number of zeros?<br />
That is, would you need to know about inverting the hash algorithm in order to prove that difficulty is increasing by adding leading zeros as opposed to any other &quot;pattern&quot; of any other hex character of the same cardinality?</p>
<p>Please forgive and correct my understanding of the issues in question.</p>

CC BY-SA 4.0
2021-04-16T16:04:50.957Z
Does this answer your question? [How does solving a block work in relation to the first letter/number after the 0's?](https://bitcoin.stackexchange.com/questions/102414/how-does-solving-a-block-work-in-relation-to-the-first-letter-number-after-the-0). See also [Growth Dependent Block Size Limit](https://bitcoin.stackexchange.com/q/30681/13866)
RedGrittyBrick
CC BY-SA 4.0
2021-04-16T16:13:15.463Z
Block size is not related to difficulty. What's hashed contains a hash of all transactions included in the block and all the transactions are not hashed every time the block is hashed.
MCCCS
CC BY-SA 4.0
2021-04-16T16:14:03.787Z
@RedGrittyBrick I'm not yet wise enough to be sure but I don't think so because I'm not asking about how to check the ordinal-size of digests, I'm wondering about the extent to which ordinality corresponds to difficulty, whether or not cardinality of non-contiguous digest substring patterns are an equally good way to control difficulty, and how we can compare approaches without inverting sha256.
kendfss
CC BY-SA 4.0
2021-04-16T16:22:33.273Z
@MCCCS  I didn't mean to imply it was. I only wanted to know about how to be sure we have a good size-limit and how to know we are actually controlling difficulty without first knowing how to invert sha256.
kendfss
CC BY-SA 4.0
2021-04-16T16:48:12.497Z
Hi kendfss, welcome to Bitcoin Stackexchange. If you haven't seen our [tour], please check it out. Our site works best, if each topic only asks one question, but your post has two fairly distinct areas of inquiry. Could you please edit your post to reduce it to one topic and ask the other in a separate post?
Murch
<protocol>
(How/Why) - Work vs Block Size Limit and Leading Zeros
kendfss
# (How/Why) - Work vs Block Size Limit and Leading Zeros

(Asked by: username_0 on 2021-04-16)

Tl:dr  
How did Satoshi/the community decide an appropriate block-size-limit?  
Why does the protocol increase mining difficulty by adding zeros?

---

I've some limited experience with some of the cryptographic concepts underlying bitcoins protocols.  
I have two questions.

Given the fact that there is an upper limit on block size, perhaps the easiest way to breach this is to arrive at an some exceedingly large nonce which will become necessary due to other block contents.  
**The question is**, how do you set an appropriate limit for arbitrary blocks?  
Would you need to know about inverting the hashing-algorithm in order to prove the efficacy of a given limit for an arbitrary ledger/header/nonce set?

---

Second question is about the relevance of increasing the leading zeros over time.

Would it not be equivalent (wrt work done) to set a total number of zeros?  
That is, would you need to know about inverting the hash algorithm in order to prove that difficulty is increasing by adding leading zeros as opposed to any other "pattern" of any other hex character of the same cardinality?

Please forgive and correct my understanding of the issues in question.

**Tags:** protocol

> **Comments:**
> **username_1**: Does this answer your question? [How does solving a block work in relation to the first letter/number after the 0's?](https://bitcoin.stackexchange.com/questions/102414/how-does-solving-a-block-work-in-relation-to-the-first-letter-number-after-the-0). See also [Growth Dependent Block Size Limit](https://bitcoin.stackexchange.com/q/30681/13866)  
> **username_2**: Block size is not related to difficulty. What's hashed contains a hash of all transactions included in the block and all the transactions are not hashed every time the block is hashed.  
> **username_0**: @username_1 I'm not yet wise enough to be sure but I don't think so because I'm not asking about how to check the ordinal-size of digests, I'm wondering about the extent to which ordinality corresponds to difficulty, whether or not cardinality of non-contiguous digest substring patterns are an equally good way to control difficulty, and how we can compare approaches without inverting sha256.  
> **username_0**: @username_2  I didn't mean to imply it was. I only wanted to know about how to be sure we have a good size-limit and how to know we are actually controlling difficulty without first knowing how to invert sha256.  
> **username_3**: Hi username_0, welcome to Bitcoin Stackexchange. If you haven't seen our [tour], please check it out. Our site works best, if each topic only asks one question, but your post has two fairly distinct areas of inquiry. Could you please edit your post to reduce it to one topic and ask the other in a separate post?  

---

## 0 answers

