In the Wikipedia article about Merkle trees, I was just reading this, unable to understand where the problem lies:
Second preimage attack
The Merkle hash root does not indicate the tree depth, enabling a second-preimage attack in which an attacker creates a document other than the original that has the same Merkle hash root. For the example above, an attacker can create a new document containing two data blocks, where the first is hash 0-0 + hash 0-1, and the second is hash 1-0 + hash 1-1.
One simple fix is defined in Certificate Transparency: when computing leaf node hashes, a 0x00 byte is prepended to the hash data, while 0x01 is prepended when computing internal node hashes. Limiting the hash tree size is a prerequisite of some formal security proofs, and helps in making some proofs tighter. Some implementations limit the tree depth using hash tree depth prefixes before hashes, so any extracted hash chain is defined to be valid only if the prefix decreases at each step and is still positive when the leaf is reached.
My first questions are: Is this really a problem in Bitcoin? If yes, how is it being solved in Bitcoin core?
My second questions are: Could this problem be solved by storing the tree depth of each block directly in the block chain? Or speaking of Bitcoin, would that negatively affect the block validation procedure itself somehow?