user50349: The Background
Bitcoin tracks chain work by counting the (expected) minimum number of hashes it would take to create a chain of the same number of blocks and same difficulty steps[1]. Naturally, accumulated work measured in this fashion (e.g. expected number of hashes) increases with each new block that is added to the chain. 
For a given target t, the minimum expected number of hash attempts necessary to find a block which meets the proof of work criteria (hash less than or equal to t) is geometrically distributed[2] with parameter p = t / 2^256.
We can calculate the entropy, w, of such a geometrically distributed random variable[3] by the equation w(p) = (-(1-p)log2(1-p) - plog2(p)) / p, and using p = t / 2^256 we can trivially rewrite this into a function of the target instead, w(t).
Using this method we can calculate the minimum work (e.g. entropy) w(t), denominated in bits, necessary to describe the proof of work signal. Other components of the blockchain (such as what data is in the blocks besides the proof of work signal) are not included in this analysis so that is why it is an estimate of the minimum encoding.
Plugging in some numbers: 

for block zero (and any block with the lowest possible difficulty, hence p = 1 / 2^32), we get approximately 33.44 bits of work per block.
for a more recent block, say block #602784 we getapproximately 76.97 bits of work per block.

The Question
Can we complete the above analysis for every difficulty period and sum the entropies to obtain a lower bound on the minimum complexity, in bits, of the (proof of work aspects of the) Bitcoin blockchain? Or is there some assumption (such as being able to sum the entropies in this context?) that is unsafe/wrong?
An Attempted Answer & Some Motivation
Performing such an analysis[4] seems to give a result, as of block 602784, of approximately 36.9 million bits or 4.6 megabytes and growing. 
However, one reason why the method seems interesting is that, if it is reasonable, then it seems that all the math which the bitcoin protocol currently does with "time" (in the unix timestamp sense, such as difficulty adjustments, and block timestamp must advance median of last n block's timestamps) could instead be done in "bits." As such, this could be helpful for when/if the protocol is extended into operate across vast distances of spacetime?
Then again, there is probably something terribly wrong with this analysis which is why the question is being asked here.
References
[1] Strongest vs Longest chain and orphaned blocks
[2] How is it that concurrent miners do not subvert each other's work?
[3] https://math.stackexchange.com/questions/490559/entropy-of-geometric-random-variable
[4] https://github.com/philbertw4/mathematicalbitcoin/blob/master/scala/SatsPerBit.sc

user139391: It is possible to complete the above analysis for every difficulty period and sum the entropies to obtain a lower bound on the minimum complexity, in bits, of the proof of work aspects of the Bitcoin blockchain. However, one assumption that is being made in this analysis is that the entropy of the proof of work signal can be accumulated by summing the entropies of each block. This assumption may not be entirely accurate, as there may be other factors that contribute to the overall complexity of the blockchain that are not being taken into account in this analysis.
The method of using entropy as a measure of the complexity of the blockchain is an interesting approach, as it can provide a way to quantify the amount of work that has gone into maintaining the integrity of the blockchain. Additionally, the idea of using
However, it is important to note that this is a simplification of the complexity of the blockchain and it may not fully capture the complexity of the proof of work mechanism. It would be important to consider other factors that could affect the overall complexity of the blockchain, such as the number of nodes participating in the network and the distribution of computational power among them.

50349: <p><strong>The Background</strong></p>

<p>Bitcoin tracks chain work by counting the (expected) minimum number of hashes it would take to create a chain of the same number of blocks and same difficulty steps[1]. Naturally, accumulated work measured in this fashion (e.g. expected number of hashes) increases with each new block that is added to the chain. </p>

<p>For a given target <code>t</code>, the <em>minimum</em> expected number of hash attempts necessary to find a block which meets the proof of work criteria (hash less than or equal to t) is geometrically distributed[2] with parameter <code>p = t / 2^256</code>.</p>

<p>We can calculate the entropy, <code>w</code>, of such a geometrically distributed random variable[3] by the equation w(p) = (-(1-p)<em>log2(1-p) - p</em>log2(p)) / p, and using <code>p = t / 2^256</code> we can trivially rewrite this into a function of the target instead, <code>w(t)</code>.</p>

<p>Using this method we can calculate the minimum work (e.g. entropy) <code>w(t)</code>, denominated in bits, necessary to describe the proof of work signal. Other components of the blockchain (such as what data is in the blocks besides the proof of work signal) are not included in this analysis so that is why it is an estimate of the <em>minimum</em> encoding.</p>

<p>Plugging in some numbers: </p>

<ul>
<li>for block zero (and any block with the lowest possible difficulty, hence <code>p = 1 / 2^32</code>), we get <code>approximately 33.44 bits</code> of work per block.</li>
<li>for a more recent block, say block <a href="https://blockstream.info/block/000000000000000000119839f8a9f5a021a5cd442fafd6e712089bb5cf238a8d" rel="nofollow noreferrer"><code>#602784</code></a> we get<code>approximately 76.97 bits</code> of work per block.</li>
</ul>

<p><strong>The Question</strong></p>

<p>Can we complete the above analysis for every difficulty period and sum the entropies to obtain a lower bound on the minimum complexity, in bits, of the (proof of work aspects of the) Bitcoin blockchain? Or is there some assumption (such as being able to sum the entropies in this context?) that is unsafe/wrong?</p>

<p><strong>An Attempted Answer &amp; Some Motivation</strong></p>

<p>Performing such an analysis[4] seems to give a result, as of block 602784, of approximately 36.9 million bits or 4.6 megabytes and growing. </p>

<p>However, one reason why the method seems interesting is that, if it is reasonable, then it seems that all the math which the bitcoin protocol currently does with "time" (in the unix timestamp sense, such as difficulty adjustments, and block timestamp must advance median of last n block's timestamps) could instead be done in "bits." As such, this could be helpful for when/if the protocol is extended into operate across vast distances of spacetime?</p>

<p>Then again, there is probably something terribly wrong with this analysis which is why the question is being asked here.</p>

<p><strong>References</strong></p>

<p>[1] <a href="https://bitcoin.stackexchange.com/questions/29742/strongest-vs-longest-chain-and-orphaned-blocks">Strongest vs Longest chain and orphaned blocks</a></p>

<p>[2] <a href="https://bitcoin.stackexchange.com/questions/35662/how-is-it-that-concurrent-miners-do-not-subvert-each-others-work">How is it that concurrent miners do not subvert each other&#39;s work?</a></p>

<p>[3] <a href="https://math.stackexchange.com/questions/490559/entropy-of-geometric-random-variable">https://math.stackexchange.com/questions/490559/entropy-of-geometric-random-variable</a></p>

<p>[4] <a href="https://github.com/philbertw4/mathematicalbitcoin/blob/master/scala/SatsPerBit.sc" rel="nofollow noreferrer">https://github.com/philbertw4/mathematicalbitcoin/blob/master/scala/SatsPerBit.sc</a></p>
 139391: <p>It is possible to complete the above analysis for every difficulty period and sum the entropies to obtain a lower bound on the minimum complexity, in bits, of the proof of work aspects of the Bitcoin blockchain. However, one assumption that is being made in this analysis is that the entropy of the proof of work signal can be accumulated by summing the entropies of each block. This assumption may not be entirely accurate, as there may be other factors that contribute to the overall complexity of the blockchain that are not being taken into account in this analysis.</p>
<p>The method of using entropy as a measure of the complexity of the blockchain is an interesting approach, as it can provide a way to quantify the amount of work that has gone into maintaining the integrity of the blockchain. Additionally, the idea of using</p>
<p>However, it is important to note that this is a simplification of the complexity of the blockchain and it may not fully capture the complexity of the proof of work mechanism. It would be important to consider other factors that could affect the overall complexity of the blockchain, such as the number of nodes participating in the network and the distribution of computational power among them.</p>
