diff options
author | MarcoFalke <falke.marco@gmail.com> | 2019-11-11 13:20:20 -0500 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2019-11-11 13:20:27 -0500 |
commit | 80fdb6fad132166b10fbeb8615e3c5c591209e0b (patch) | |
tree | dec44e32433abb769e534d9f9dc13580cead7871 | |
parent | a6f6333ba253cda83221ee529810cacf930e413f (diff) | |
parent | eb880f092b4154cf66fe96fc42ffdeff309e3975 (diff) |
Merge #17442: fix Typo: "merkelRoot" -> "merkleRoot"
eb880f092b4154cf66fe96fc42ffdeff309e3975 fix Typo: "merkelRoot" -> "merkleRoot" (ianliu)
Pull request description:
<!--
*** 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:
practicalswift:
ACK eb880f092b4154cf66fe96fc42ffdeff309e3975 but please change from `merkleRootofHashes` to `merkleRootOfHashes`
Tree-SHA512: ada9edceee19da5678bf35e1258163e7102fe176dc5cf40acaa1468fa8b2801494f8bf65d5359dcd0054fbc22f07fdc98d6208cfdb54dd9171fd45c89d71e098
-rw-r--r-- | src/test/merkle_tests.cpp | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/src/test/merkle_tests.cpp b/src/test/merkle_tests.cpp index 8813921df5..03dce552fc 100644 --- a/src/test/merkle_tests.cpp +++ b/src/test/merkle_tests.cpp @@ -345,8 +345,8 @@ BOOST_AUTO_TEST_CASE(merkle_test_BlockWitness) hashes[0].SetNull(); hashes[1] = block.vtx[1]->GetHash(); - uint256 merkelRootofHashes = ComputeMerkleRoot(hashes); + uint256 merkleRootofHashes = ComputeMerkleRoot(hashes); - BOOST_CHECK_EQUAL(merkelRootofHashes, blockWitness); + BOOST_CHECK_EQUAL(merkleRootofHashes, blockWitness); } BOOST_AUTO_TEST_SUITE_END() |