2023-08-16 19:27:31 +02:00
|
|
|
// Copyright (c) 2015-2020 The Bitcoin Core developers
|
2016-01-27 12:05:25 +01:00
|
|
|
// Distributed under the MIT software license, see the accompanying
|
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
2020-03-19 23:46:56 +01:00
|
|
|
#include <consensus/merkle.h>
|
|
|
|
#include <hash.h>
|
2015-11-17 17:35:40 +01:00
|
|
|
|
|
|
|
/* WARNING! If you're reading this because you're learning about crypto
|
|
|
|
and/or designing a new system that will use merkle trees, keep in mind
|
|
|
|
that the following merkle tree algorithm has a serious flaw related to
|
|
|
|
duplicate txids, resulting in a vulnerability (CVE-2012-2459).
|
|
|
|
|
2020-03-18 19:02:20 +01:00
|
|
|
The reason is that if the number of hashes in the list at a given level
|
2015-11-17 17:35:40 +01:00
|
|
|
is odd, the last one is duplicated before computing the next level (which
|
|
|
|
is unusual in Merkle trees). This results in certain sequences of
|
|
|
|
transactions leading to the same merkle root. For example, these two
|
|
|
|
trees:
|
|
|
|
|
|
|
|
A A
|
|
|
|
/ \ / \
|
|
|
|
B C B C
|
|
|
|
/ \ | / \ / \
|
|
|
|
D E F D E F F
|
|
|
|
/ \ / \ / \ / \ / \ / \ / \
|
|
|
|
1 2 3 4 5 6 1 2 3 4 5 6 5 6
|
|
|
|
|
|
|
|
for transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and
|
|
|
|
6 are repeated) result in the same root hash A (because the hash of both
|
|
|
|
of (F) and (F,F) is C).
|
|
|
|
|
|
|
|
The vulnerability results from being able to send a block with such a
|
|
|
|
transaction list, with the same merkle root, and the same block hash as
|
|
|
|
the original without duplication, resulting in failed validation. If the
|
|
|
|
receiving node proceeds to mark that block as permanently invalid
|
|
|
|
however, it will fail to accept further unmodified (and thus potentially
|
|
|
|
valid) versions of the same block. We defend against this by detecting
|
|
|
|
the case where we would hash two identical hashes at the end of the list
|
|
|
|
together, and treating that identically to the block having an invalid
|
|
|
|
merkle root. Assuming no double-SHA256 collisions, this will detect all
|
|
|
|
known ways of changing the transactions without affecting the merkle
|
|
|
|
root.
|
|
|
|
*/
|
|
|
|
|
2018-06-04 09:11:18 +02:00
|
|
|
|
|
|
|
uint256 ComputeMerkleRoot(std::vector<uint256> hashes, bool* mutated) {
|
|
|
|
bool mutation = false;
|
|
|
|
while (hashes.size() > 1) {
|
|
|
|
if (mutated) {
|
|
|
|
for (size_t pos = 0; pos + 1 < hashes.size(); pos += 2) {
|
|
|
|
if (hashes[pos] == hashes[pos + 1]) mutation = true;
|
2015-11-17 17:35:40 +01:00
|
|
|
}
|
|
|
|
}
|
2018-06-04 09:11:18 +02:00
|
|
|
if (hashes.size() & 1) {
|
|
|
|
hashes.push_back(hashes.back());
|
2015-11-17 17:35:40 +01:00
|
|
|
}
|
2018-06-04 09:11:18 +02:00
|
|
|
SHA256D64(hashes[0].begin(), hashes[0].begin(), hashes.size() / 2);
|
|
|
|
hashes.resize(hashes.size() / 2);
|
2015-11-17 17:35:40 +01:00
|
|
|
}
|
2018-06-04 09:11:18 +02:00
|
|
|
if (mutated) *mutated = mutation;
|
|
|
|
if (hashes.size() == 0) return uint256();
|
|
|
|
return hashes[0];
|
2015-11-17 17:35:40 +01:00
|
|
|
}
|
|
|
|
|
2015-11-17 17:35:44 +01:00
|
|
|
|
|
|
|
uint256 BlockMerkleRoot(const CBlock& block, bool* mutated)
|
|
|
|
{
|
|
|
|
std::vector<uint256> leaves;
|
|
|
|
leaves.resize(block.vtx.size());
|
|
|
|
for (size_t s = 0; s < block.vtx.size(); s++) {
|
2016-11-21 10:51:32 +01:00
|
|
|
leaves[s] = block.vtx[s]->GetHash();
|
2015-11-17 17:35:44 +01:00
|
|
|
}
|
2018-06-04 09:11:18 +02:00
|
|
|
return ComputeMerkleRoot(std::move(leaves), mutated);
|
2015-11-17 17:35:44 +01:00
|
|
|
}
|
|
|
|
|