aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarcoFalke <falke.marco@gmail.com>2020-03-18 14:02:20 -0400
committerMarcoFalke <falke.marco@gmail.com>2020-03-18 14:02:22 -0400
commitdbb067da389d457e73c6ecbf6389baa3ab082b46 (patch)
tree90cc0c5135c14c13372143fd058f6a2fe109977d
parent3a8d25064e700ff2e69600cc1ede597751283a85 (diff)
parent5b59a19731827398aa32754d1f327178247d3199 (diff)
downloadbitcoin-dbb067da389d457e73c6ecbf6389baa3ab082b46.tar.xz
Merge #18379: doc: Comment fix merkle.cpp
5b59a19731827398aa32754d1f327178247d3199 Update merkle.cpp (4d55397500) Pull request description: Change comment from `The reason is that if the number of hashes in the list at a given time is odd`, to ` The reason is that if the number of hashes in the list at a given level is odd` (to be a bit more precise: replacing `time` with `level`) <!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. --> <!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. --> <!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> ACKs for top commit: MarcoFalke: ACK 5b59a19731827398aa32754d1f327178247d3199 instagibbs: ACK https://github.com/bitcoin/bitcoin/pull/18379/commits/5b59a19731827398aa32754d1f327178247d3199 Tree-SHA512: 30d29b9855b30de8b54033ca4884cfb5bf8ab9e52cf61da237abba0e15ebff947c65f8ba82175694bc60ee0d54f940a098cadcb0404d3c3bcf577006ab0561a5
-rw-r--r--src/consensus/merkle.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/consensus/merkle.cpp b/src/consensus/merkle.cpp
index 843985e54c..241cc316a6 100644
--- a/src/consensus/merkle.cpp
+++ b/src/consensus/merkle.cpp
@@ -10,7 +10,7 @@
that the following merkle tree algorithm has a serious flaw related to
duplicate txids, resulting in a vulnerability (CVE-2012-2459).
- The reason is that if the number of hashes in the list at a given time
+ The reason is that if the number of hashes in the list at a given level
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