user101033: I noticed that the hash message for the tagged hash in BIP340 is prefixed with SHA256(tag) || SHA256(tag), which also describes the reason

Because this is a 64-byte long context-specific constant and the SHA256 block size is also 64 bytes, optimized implementations are possible (identical to SHA256 itself, but with a modified initial state). Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.

But I have some confusions

"optimized implementations are possible": What specifically is the optimization being talked about here, is it caused by the prefix being the same size as the block size of SHA-256? If so, can this conclusion be generalised to all block hashing algorithms? i.e. the same size of the prefix and the block of the algorithm can lead to optimization.
"Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.": Does this mean that if the implementation does not intend to adopt optimization, then it can not repeat the tag? i.e. the tagged hash would be SHA256( SHA256(tag) || msg).


user208: 

"optimized implementations are possible": What specifically is the optimization being talked about here, is it caused by the prefix being the same size as the block size of SHA-256? If so, can this conclusion be generalised to all block hashing algorithms? i.e. the same size of the prefix and the block of the algorithm can lead to optimization.


Yes, it means that the SHA256 hashing state at SHA256(SHA256(tag)||SHA256(tag)|| can be precomputed. If the tag was just 32 bytes this wouldn't work, as you'd need to know 32 bytes of data before being able to process the first block.


"Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.": Does this mean that if the implementation does not intend to adopt optimization, then it can not repeat the tag? i.e. the tagged hash would be SHA256( SHA256(tag) || msg).


No, that would give a different result. All this is saying is that it's a simple construction to concatenate the hashed tag twice. Obviously not doubling it would be even simpler, but that would forego the optimization from the previous point.

101033: <p>I noticed that the hash message for the tagged hash in <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="nofollow noreferrer">BIP340</a> is prefixed with SHA256(tag) || SHA256(tag), which also describes the reason</p>
<blockquote>
<p>Because this is a 64-byte long context-specific constant and the SHA256 block size is also 64 bytes, optimized implementations are possible (identical to SHA256 itself, but with a modified initial state). Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.</p>
</blockquote>
<p>But I have some confusions</p>
<ol>
<li><strong>&quot;optimized implementations are possible&quot;:</strong> What specifically is the optimization being talked about here, is it caused by the prefix being the same size as the block size of SHA-256? If so, can this conclusion be generalised to all block hashing algorithms? i.e. the same size of the prefix and the block of the algorithm can lead to optimization.</li>
<li><strong>&quot;Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.&quot;</strong>: Does this mean that if the implementation does not intend to adopt optimization, then it can not repeat the tag? i.e. the tagged hash would be SHA256( SHA256(tag) || msg).</li>
</ol>
 208: <blockquote>
<ol>
<li>&quot;optimized implementations are possible&quot;: What specifically is the optimization being talked about here, is it caused by the prefix being the same size as the block size of SHA-256? If so, can this conclusion be generalised to all block hashing algorithms? i.e. the same size of the prefix and the block of the algorithm can lead to optimization.</li>
</ol>
</blockquote>
<p>Yes, it means that the SHA256 hashing state at <code>SHA256(SHA256(tag)||SHA256(tag)||</code> can be precomputed. If the tag was just 32 bytes this wouldn't work, as you'd need to know 32 bytes of data before being able to process the first block.</p>
<blockquote>
<ol start="2">
<li>&quot;Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization.&quot;: Does this mean that if the implementation does not intend to adopt optimization, then it can not repeat the tag? i.e. the tagged hash would be SHA256( SHA256(tag) || msg).</li>
</ol>
</blockquote>
<p>No, that would give a different result. All this is saying is that it's a simple construction to concatenate the hashed tag twice. Obviously not doubling it would be even simpler, but that would forego the optimization from the previous point.</p>
