mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-01-24 18:23:26 -03:00
1f7fc73825
The duplicate checks are repeated early in the contextual checks of ProcessNewBlock. If duplicate blocks are detected much of their validation is skipped. Depending on the constitution of the block, validating the merkle root of the block is part of the more intensive workload when validating a block. This could be an argument for moving the pre-checks into block processing. In net_processing this would have a smaller effect however, since the block mutation check, which also validates the merkle root, is done before. A side effect of this change is that a duplicate block is persisted again on disk even when pruning is activated. This is similar to the behaviour with getblockfrompeer. Add a release note for this change in behaviour. Testing spamming a node with valid, but duplicate unrequested blocks seems to exhaust a CPU thread, but does not seem to significantly impact keeping up with the tip. The benefits of adding these checks to net_processing are questionable, especially since there are other ways to trigger the more CPU-intensive checks without submitting a duplicate block. Since these DOS concerns apply even less to the RPC interface, which does not have banning mechanics built in, remove them too. --- With the introduction of a mining ipc interface and the potential future introduction of a kernel library API it becomes increasingly important to offer common behaviour between them. An example of this is ProcessNewBlock, which is used by ipc, rpc, net_processing and (potentially) the kernel library. Having divergent behaviour on suggested pre-checks and checks for these functions is confusing to both developers and users and is a maintenance burden. The rpc interface for ProcessNewBlock (submitblock) currently pre-checks if the block has a coinbase transaction and whether it has been processed before. While the current example binary for how to use the kernel library, bitcoin-chainstate, imitates these checks, the other interfaces do not. |
||
|---|---|---|
| .. | ||
| design | ||
| man | ||
| policy | ||
| release-notes | ||
| assets-attribution.md | ||
| assumeutxo.md | ||
| benchmarking.md | ||
| bips.md | ||
| bitcoin-conf.md | ||
| bitcoin_logo_doxygen.png | ||
| build-freebsd.md | ||
| build-netbsd.md | ||
| build-openbsd.md | ||
| build-osx.md | ||
| build-unix.md | ||
| build-windows-msvc.md | ||
| build-windows.md | ||
| cjdns.md | ||
| CMakeLists.txt | ||
| dependencies.md | ||
| descriptors.md | ||
| developer-notes.md | ||
| dnsseed-policy.md | ||
| Doxyfile.in | ||
| external-signer.md | ||
| files.md | ||
| fuzzing.md | ||
| guix.md | ||
| i2p.md | ||
| init.md | ||
| JSON-RPC-interface.md | ||
| managing-wallets.md | ||
| multiprocess.md | ||
| multisig-tutorial.md | ||
| offline-signing-tutorial.md | ||
| p2p-bad-ports.md | ||
| productivity.md | ||
| psbt.md | ||
| README.md | ||
| README_doxygen.md | ||
| README_windows.txt | ||
| reduce-memory.md | ||
| reduce-traffic.md | ||
| release-notes-28358.md | ||
| release-notes-31130.md | ||
| release-notes-31175.md | ||
| release-notes-empty-template.md | ||
| release-process.md | ||
| REST-interface.md | ||
| tor.md | ||
| tracing.md | ||
| translation_process.md | ||
| translation_strings_policy.md | ||
| zmq.md | ||
Bitcoin Core
Setup
Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires several hundred gigabytes or more of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to several days or more.
To download Bitcoin Core, visit bitcoincore.org.
Running
The following are some helpful notes on how to run Bitcoin Core on your native platform.
Unix
Unpack the files into a directory and run:
bin/bitcoin-qt(GUI) orbin/bitcoind(headless)
Windows
Unpack the files into a directory, and then run bitcoin-qt.exe.
macOS
Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
Need Help?
- See the documentation at the Bitcoin Wiki for help and more information.
- Ask for help on Bitcoin StackExchange.
- Ask for help on #bitcoin on Libera Chat. If you don't have an IRC client, you can use web.libera.chat.
- Ask for help on the BitcoinTalk forums, in the Technical Support board.
Building
The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
- Dependencies
- macOS Build Notes
- Unix Build Notes
- Windows Build Notes
- FreeBSD Build Notes
- OpenBSD Build Notes
- NetBSD Build Notes
Development
The Bitcoin repo's root README contains relevant information on the development process and automated testing.
- Developer Notes
- Productivity Notes
- Release Process
- Source Code Documentation (External Link)
- Translation Process
- Translation Strings Policy
- JSON-RPC Interface
- Unauthenticated REST Interface
- BIPS
- Dnsseed Policy
- Benchmarking
- Internal Design Docs
Resources
- Discuss on the BitcoinTalk forums, in the Development & Technical Discussion board.
- Discuss project-specific development on #bitcoin-core-dev on Libera Chat. If you don't have an IRC client, you can use web.libera.chat.
Miscellaneous
- Assets Attribution
- bitcoin.conf Configuration File
- CJDNS Support
- Files
- Fuzz-testing
- I2P Support
- Init Scripts (systemd/upstart/openrc)
- Managing Wallets
- Multisig Tutorial
- Offline Signing Tutorial
- P2P bad ports definition and list
- PSBT support
- Reduce Memory
- Reduce Traffic
- Tor Support
- Transaction Relay Policy
- ZMQ
License
Distributed under the MIT software license.