The blockchain that provides the digital content namespace for the LBRY protocol

bitcoin blockchain c-plus-plus cryptocurrency decentralized lbry

Find a file

Wladimir J. van der Laan d7d7d31506 Merge #15141 : Rewrite DoS interface between validation and net_processing `0ff1c2a838` Separate reason for premature spends (coinbase/locktime) (Suhas Daftuar) `54470e767b` Assert validation reasons are contextually correct (Suhas Daftuar) `2120c31521` [refactor] Update some comments in validation.cpp as we arent doing DoS there (Matt Corallo) `12dbdd7a41` [refactor] Drop unused state.DoS(), state.GetDoS(), state.CorruptionPossible() (Matt Corallo) `aa502b88d1` scripted-diff: Remove DoS calls to CValidationState (Matt Corallo) `7721ad64f4` [refactor] Prep for scripted-diff by removing some \ns which annoy sed. (Matt Corallo) `5e78c5734b` Allow use of state.Invalid() for all reasons (Matt Corallo) `6b34bc6b6f` Fix handling of invalid headers (Suhas Daftuar) `ef54b486d5` [refactor] Use Reasons directly instead of DoS codes (Matt Corallo) `9ab2a0412e` CorruptionPossible -> BLOCK_MUTATED (Matt Corallo) `6e55b292b0` CorruptionPossible -> TX_WITNESS_MUTATED (Matt Corallo) `7df16e70e6` LookupBlockIndex -> CACHED_INVALID (Matt Corallo) `c8b0d22698` [refactor] Drop redundant nDoS, corruptionPossible, SetCorruptionPossible (Matt Corallo) `34477ccd39` [refactor] Add useful-for-dos "reason" field to CValidationState (Matt Corallo) `6a7f8777a0` Ban all peers for all block script failures (Suhas Daftuar) `7b999103e2` Clean up banning levels (Matt Corallo) `b8b4c80146` [refactor] drop IsInvalid(nDoSOut) (Matt Corallo) `8818729013` [refactor] Refactor misbehavior ban decisions to MaybePunishNode() (Matt Corallo) `00e11e61c0` [refactor] rename stateDummy -> orphan_state (Matt Corallo) `f34fa719cf` Drop obsolete sigops comment (Matt Corallo) Pull request description: This is a rebase of #11639 with some fixes for the last few comments which were not yet addressed. The original PR text, with some strikethroughs of text that is no longer correct: > This cleans up an old main-carryover - it made sense that main could decide what DoS scores to assign things because the DoS scores were handled in a different part of main, but now validation is telling net_processing what DoS scores to assign to different things, which is utter nonsense. Instead, we replace CValidationState's nDoS and CorruptionPossible with a general ValidationInvalidReason, which net_processing can handle as it sees fit. I keep the behavior changes here to a minimum, but in the future we can utilize these changes for other smarter behavior, such as disconnecting/preferring to rotate outbound peers based on them providing things which are invalid due to SOFT_FORK because we shouldn't ban for such cases. > > This is somewhat complementary with, though obviously conflicts heavily with #11523, which added enums in place of DoS scores, as well as a few other cleanups (which are still relevant). > > Compared with previous bans, the following changes are made: > > Txn with empty vin/vout or null prevouts move from 10 DoS > points to 100. > Loose transactions with a dependency loop now result in a ban > instead of 10 DoS points. > ~~BIP68-violation no longer results in a ban as it is SOFT_FORK.~~ > ~~Non-SegWit SigOp violation no longer results in a ban as it > considers P2SH sigops and is thus SOFT_FORK.~~ > ~~Any script violation in a block no longer results in a ban as > it may be the result of a SOFT_FORK. This should likely be > fixed in the future by differentiating between them.~~ > Proof of work failure moves from 50 DoS points to a ban. > Blocks with timestamps under MTP now result in a ban, blocks > too far in the future continue to not result in a ban. > Inclusion of non-final transactions in a block now results in a > ban instead of 10 DoS points. Note: The change to ban all peers for consensus violations is actually NOT the change I'd like to make -- I'd prefer to only ban outbound peers in those situations. The current behavior is a bit of a mess, however, and so in the interests of advancing this PR I tried to keep the changes to a minimum. I plan to revisit the behavior in a followup PR. EDIT: One reviewer suggested I add some additional context for this PR: > The goal of this work was to make net_processing aware of the actual reasons for validation failures, rather than just deal with opaque numbers instructing it to do something. > > In the future, I'd like to make it so that we use more context to decide how to punish a peer. One example is to differentiate inbound and outbound peer misbehaviors. Another potential example is if we'd treat RECENT_CONSENSUS_CHANGE failures differently (ie after the next consensus change is implemented), and perhaps again we'd want to treat some peers differently than others. ACKs for commit 0ff1c2: jnewbery: utACK `0ff1c2a838` ryanofsky: utACK `0ff1c2a838`. Only change is dropping the first commit (f3883a321bf4ab289edcd9754b12cae3a648b175), and dropping the temporary `assert(level == GetDoS())` that was in 35ee77f2832eaffce30042e00785c310c5540cdc (now `c8b0d22698`) Tree-SHA512: e915a411100876398af5463d0a885920e44d473467bb6af991ef2e8f2681db6c1209bb60f848bd154be72d460f039b5653df20a6840352c5f7ea5486d9f777a3		2019-05-04 11:58:57 +02:00
.github	Get more info about GUI-related issue on Linux	2018-12-27 06:53:07 +02:00
.travis	travis: Switch to ubuntu keyserver to avoid timeouts	2019-03-29 11:38:25 -04:00
.tx	qt: Pre-0.18 split-off translations update	2019-02-04 15:24:37 +01:00
build-aux/m4	Bump minimum Qt version to 5.5.1	2019-02-14 11:12:30 +01:00
build_msvc	Align MSVC build options with Linux build ones	2019-04-27 10:11:52 +03:00
contrib	contrib: gh-merge: Use pagination to fetch all review comments	2019-04-17 20:21:45 +01:00
depends	Merge #15446 : Improve depends debuggability	2019-04-08 10:19:14 -04:00
doc	doc: Add historical release notes for 0.18.0	2019-05-02 16:10:19 +02:00
share	Merge #15548 : build: use full version string in setup.exe	2019-03-12 10:43:08 +01:00
src	Merge #15141 : Rewrite DoS interface between validation and net_processing	2019-05-04 11:58:57 +02:00
test	Merge #15141 : Rewrite DoS interface between validation and net_processing	2019-05-04 11:58:57 +02:00
.appveyor.yml	appveyor: Write @PACKAGE_NAME@ to config	2019-04-26 13:07:11 -04:00
.cirrus.yml	cirrus ci: Inital config	2019-02-03 10:24:39 -05:00
.gitattributes	Separate protocol versioning from clientversion	2014-10-29 00:24:40 -04:00
.gitignore	gitignore: add *.plist (clang-check)	2019-04-12 15:25:00 -04:00
.python-version	.python-version: Specify full version 3.5.6	2019-03-02 12:06:26 -05:00
.style.yapf	test: .style.yapf: Set column_limit=160	2019-03-04 18:28:13 -05:00
.travis.yml	travis: Bump second timeout to 33 minutes, Add rationale	2019-04-11 14:56:56 -04:00
autogen.sh	Add "export LC_ALL=C" to all shell scripts	2018-06-14 15:27:52 +02:00
configure.ac	Merge #15849 : Thread names in logs and deadlock debug tools	2019-04-30 15:26:01 -04:00
CONTRIBUTING.md	Doc: update ACK description in CONTRIBUTING.md	2019-03-20 12:10:35 +01:00
COPYING	[Trivial] Update license year range to 2019	2018-12-31 04:27:59 +01:00
INSTALL.md	Update INSTALL landing redirection notice for build instructions.	2016-10-06 12:27:23 +13:00
libbitcoinconsensus.pc.in	Unify package name to as few places as possible without major changes	2015-12-14 02:11:10 +00:00
Makefile.am	Merge #12051 : add missing debian contrib file to tarball	2019-04-29 08:48:39 -04:00
README.md	docs: Update Transifex links	2019-03-02 17:42:33 +08:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information, as well as an immediately useable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/, or read the original whitepaper.

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 and tested, but is not guaranteed to be completely stable. Tags are created regularly to indicate new official, stable release versions of Bitcoin Core.

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, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The Travis CI system makes 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.

Translators should also subscribe to the mailing list.