phantom/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-01-11 20:32:35 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions
Bitcoin Core mirror and no, I don't give a fuck about Monero.
34825 commits 6 branches 321 tags 2.2 GiB
C++ 56.4%
C 22.8%
Python 17.6%
CMake 1%
Shell 0.8%
Other 1.1%
Find a file
MacroFake 5057adf22f
Merge bitcoin/bitcoin#25349: CBlockIndex/CDiskBlockIndex improvements for safety, consistent behavior 
3a61fc56a0 refactor: move CBlockIndex#ToString() from header to implementation (Jon Atack)
57865eb512 CDiskBlockIndex: rename GetBlockHash() to ConstructBlockHash() (Jon Atack)
99e8ec8721 CDiskBlockIndex: remove unused ToString() class member (Jon Atack)
14aeece462 CBlockIndex: ensure phashBlock is not nullptr before dereferencing (Jon Atack)

Pull request description:

  Fix a few design issues, potential footguns and inconsistent behavior in the CBlockIndex and CDiskBlockIndex classes.

  - Ensure phashBlock in `CBlockIndex#GetBlockHash()` is not nullptr before dereferencing and remove a now-redundant assert preceding a GetBlockHash() caller.  This protects against UB here, and in case of failure (which would indicate a consensus bug), the debug log will print `bitcoind: chain.h:265: uint256 CBlockIndex::GetBlockHash() const: Assertion 'phashBlock != nullptr' failed. Aborted` instead of `Segmentation fault`.
  - Remove the unused `CDiskBlockIndex#ToString()` class member, and mark the inherited `CBlockIndex#ToString()` public interface member as deleted to disallow calling it in the derived CDiskBlockIndex class.
  - Rename the `CDiskBlockIndex GetBlockHash()` class member to `ConstructBlockHash()`, which also makes sense as they perform different operations to return a blockhash, and mark the inherited `CBlockIndex#GetBlockHash()` public interface member as deleted to disallow calling it in the derived CDiskBlockIndex class.
  - Move `CBlockIndex#ToString()` from header to implementation, which also allows dropping `tinyformat.h` from the header file.

  Rationale and discussion regarding the CDiskBlockIndex changes:

  Here is a failing test on master that demonstrates the inconsistent behavior of the current design: calling the same inherited public interface functions on the same CDiskBlockIndex object should yield identical behavior, but does not.

  ```diff
  diff --git a/src/test/validation_chainstatemanager_tests.cpp b/src/test/validation_chainstatemanager_tests.cpp
  index 6dc522b421..dac3840f32 100644
  --- a/src/test/validation_chainstatemanager_tests.cpp
  +++ b/src/test/validation_chainstatemanager_tests.cpp
  @@ -240,6 +240,15 @@ BOOST_FIXTURE_TEST_CASE(chainstatemanager_activate_snapshot, TestChain100Setup)

       const CBlockIndex* tip = chainman.ActiveTip();

       BOOST_CHECK_EQUAL(tip->nChainTx, au_data.nChainTx);

  +    // CDiskBlockIndex "is a" CBlockIndex, as it publicly inherits from it.
  +    // Test that calling the same inherited interface functions on the same
  +    // object yields identical behavior.
  +    CDiskBlockIndex index{tip};
  +    CBlockIndex *pB = &index;
  +    CDiskBlockIndex *pD = &index;
  +    BOOST_CHECK_EQUAL(pB->GetBlockHash(), pD->GetBlockHash());
  +    BOOST_CHECK_EQUAL(pB->ToString(), pD->ToString());
  ```

  (build and run: `$ ./src/test/test_bitcoin -t validation_chainstatemanager_tests`)

  The GetBlockHash() test assertion only passes on master because the different methods invoked by the current design happen to return the same result.  If one of the two is changed, it fails like the ToString() assertion does.

  Redefining inherited non-virtual functions is well-documented as incorrect design to avoid inconsistent behavior (see Scott Meyers, Effective C++, Item 36). Class usage is confusing when the behavior depends on the pointer definition instead of the object definition (static binding happening where dynamic binding was expected). This can lead to unsuspected or hard-to-track bugs.

  Outside of critical hot spots, correctness usually comes before optimisation, but the current design dates back to main.cpp and it may possibly have been chosen to avoid the overhead of dynamic dispatch.  This solution does the same: the class sizes are unchanged and no vptr or vtbl is added.

  There are better designs for doing this that use composition instead of inheritance, or that separate the public interface from the private implementations.  One example of the latter would be a non-virtual public interface that calls private virtual implementation methods, i.e. the Template pattern via the Non-Virtual Interface (NVI) idiom.

ACKs for top commit:
  vasild:
    ACK 3a61fc56a0

Tree-SHA512: 9ff358ab0a6d010b8f053ad8303c6d4d061e62d9c3755a56b9c9f5eab855d02f02bee42acc77dfa0cbf4bb5cb775daa72d675e1560610a29bd285c46faa85ab7
2022-07-25 16:20:13 +02:00
.github doc: Remove label from good first issue template 2020-08-24 09:31:24 +02:00
.tx qt: Update transifex resource blob to 23.0 2022-02-03 13:18:28 +01:00
build-aux/m4 build: Check for std::atomic::exchange rather than std::atomic_exchange 2022-07-18 10:47:19 -04:00
build_msvc build: Increase MS Visual Studio minimum version 2022-07-07 19:59:48 +01:00
ci ci: better pin to dwarf4 in valgrind job 2022-07-21 10:16:46 +01:00
contrib contrib: remove unneeded valgrind suppressions 2022-07-21 10:16:47 +01:00
depends depends: modify FastFixedDtoa optimisation flags 2022-07-19 12:12:26 +01:00
doc Release notes for Miniscript support in P2WSH descriptors 2022-07-15 14:20:26 +02:00
share doc: replace bitcoin.conf with placeholder file 2022-05-02 15:38:07 +02:00
src Merge bitcoin/bitcoin#25349: CBlockIndex/CDiskBlockIndex improvements for safety, consistent behavior 2022-07-25 16:20:13 +02:00
test test: remove unused if statements 2022-07-25 09:59:05 +02:00
.cirrus.yml Revert "ci: Increase CPU number for "Win64 native" task" 2022-06-27 14:01:08 +02:00
.editorconfig ci: Drop AppVeyor CI integration 2021-09-07 06:12:53 +03:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore refactor: cleanups post unsubtree'ing univalue 2022-06-15 12:56:44 +01:00
.python-version Bump minimum python version to 3.6 2020-11-09 17:53:47 +10:00
.style.yapf test: .style.yapf: Set column_limit=160 2019-03-04 18:28:13 -05:00
autogen.sh scripted-diff: Bump copyright of files changed in 2019 2019-12-30 10:42:20 +13:00
configure.ac Merge bitcoin/bitcoin#25630: Add symlinks for hardcoded Makefiles in out of tree builds 2022-07-19 16:38:36 +01:00
CONTRIBUTING.md doc: Explain squashing with merge commits 2022-05-24 08:17:41 +02:00
COPYING doc: Update license year range to 2022 2022-01-03 04:48:41 +08:00
INSTALL.md doc: Added hyperlink for doc/build 2021-09-09 19:53:12 +05:30
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00
Makefile.am refactor: cleanups post unsubtree'ing univalue 2022-06-15 12:56:44 +01:00
README.md doc: Explain Bitcoin Core in README.md 2022-05-10 07:49:09 +02:00
REVIEWERS test: port 'lint-shell.sh' to python 2022-05-05 08:44:08 -05:00
SECURITY.md doc: Suggest keys.openpgp.org as keyserver in SECURITY.md 2021-11-08 12:22:04 +01:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

What is Bitcoin Core?

Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and graphical user interface, which can be optionally built.

Further information about Bitcoin Core is available in the doc folder.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core.

The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.