aboutsummaryrefslogtreecommitdiff
path: root/src/validation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Replace consensus values with Dogecoin equivalentsRoss Nicoll2021-06-021-2/+2
| | | | | | | * Replace chain parameters with Dogecoin values * Update maximum coins to match Dogecoin * Disable version 2 block requirement * Update coinbase maturity to match Dogecoin
* Litecoin: Add scrypt N=1024 PoWshaolinfry2021-05-301-2/+2
|
* Add Dogecoin block subsidiesRoss Nicoll2021-05-301-1/+2
|
* Make assume valid minimum interval per-chain configurableRoss Nicoll2021-05-201-1/+1
| | | | Make assume valid minimum interval per-chain configurable as syncing 21,000 blocks in a regression test isn't an achievable goal.
* Dogecoin: Update coinbase maturityRoss Nicoll2021-05-201-3/+3
| | | | | | | * Change coinbase maturity to 240 blocks in most cases, with main/test early chains allowing 30 blocks. I've kept the 240 consistent in regtest to avoid having to redesign a lot of the test cases. * Disabled mining unit test which require COINBASE_MATURITY worth of pre-calculated blocks, as we'd otherwise be constantly refactoring them. * Moved functional test which uses the Bitcoin testnet block data as its reference, as it completely breaks as we introduce Dogecoin data. * Updated standard blockchains for tests from 100/200 to 240/480 as appropriate.
* Avoid signed integer overflow when loading a mempool.dat file with a ↵practicalswift2020-11-111-1/+1
| | | | malformed time field
* Only relay Taproot spends if next block has it activePieter Wuille2020-10-301-1/+3
|
* Merge #19953: Implement BIP 340-342 validation (Schnorr/taproot/tapscript)Wladimir J. van der Laan2020-10-151-7/+19
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0e2a5e448f426219a6464b9aaadcc715534114e6 tests: dumping and minimizing of script assets data (Pieter Wuille) 4567ba034c5ae6e6cc161360f7425c9e844738f0 tests: add generic qa-asset-based script verification unit test (Pieter Wuille) f06e6d03452cf5e0b1a0863afb08c9e6d3ef452e tests: functional tests for Schnorr/Taproot/Tapscript (Pieter Wuille) 3c226639eb134314a0640d34e4ccb6148dbde22f tests: add BIP340 Schnorr signature support to test framework (Pieter Wuille) 206fb180ec6ee5f916afc6f574000d716daf79b7 --- [TAPROOT] Tests --- (Pieter Wuille) d7ff237f2996a4c11fdf9399187c2d2b26bf9809 Activate Taproot/Tapscript on regtest (BIP 341, BIP 342) (Pieter Wuille) e9a021d7e6a454d610a45cb9b3995f0d96a5fbb6 Make Taproot spends standard + policy limits (Pieter Wuille) 865d2c37e2e44678498b7f425b65e01b1e231cde --- [TAPROOT] Regtest activation and policy --- (Pieter Wuille) 72422ce396b8eba7b1a72c171c2f07dae691d1b5 Implement Tapscript script validation rules (BIP 342) (Johnson Lau) 330de894a9a48515d9a473448b6c67adc3d188be Use ScriptExecutionData to pass through annex hash (Pieter Wuille) 8bbed4b7acf4c76eaea8c0e10f3cbf6ba4e53809 Implement Taproot validation (BIP 341) (Pieter Wuille) 0664f5fe1f77f08d235aa3750b59428257b0b91d Support for Schnorr signatures and integration in SignatureCheckers (BIP 340) (Pieter Wuille) 5de246ca8159dcffaa4c136a60c8bfed2028e2ee Implement Taproot signature hashing (BIP 341) (Johnson Lau) 9eb590894f15ff40806039bfd32972fbc260e30d Add TaggedHash function (BIP 340) (Pieter Wuille) 450d2b23710ad296eede81339195376021ab5500 --- [TAPROOT] BIP340/341/342 consensus rules --- (Pieter Wuille) 5d62e3a68b6ea9bb03556ee1fbf5678f20be01a2 refactor: keep spent outputs in PrecomputedTransactionData (Pieter Wuille) 8bd2b4e78452ff69c08c37acf164a6b80e503f13 refactor: rename scriptPubKey in VerifyWitnessProgram to exec_script (Pieter Wuille) 107b57df9fa8b2d625d2b342dc77722282a6ae4c scripted-diff: put ECDSA in name of signature functions (Pieter Wuille) f8c099e2207c90d758e7a659d6a55fa7ccb7ceaa --- [TAPROOT] Refactors --- (Pieter Wuille) Pull request description: This is an implementation of the Schnorr/taproot consensus rules proposed by BIPs [340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), [341](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), and [342](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki). See the list of commits [below](https://github.com/bitcoin/bitcoin/pull/19953#issuecomment-691815830). No signing or wallet support of any kind is included, as testing is done entirely through the Python test framework. This is a successor to https://github.com/bitcoin/bitcoin/pull/17977 (see discussion following [this comment](https://github.com/bitcoin/bitcoin/pull/17977#issuecomment-682285983)), and will have further changes squashed/rebased. The history of this PR can be found in #19997. ACKs for top commit: instagibbs: reACK https://github.com/bitcoin/bitcoin/pull/19953/commits/0e2a5e448f426219a6464b9aaadcc715534114e6 benthecarman: reACK 0e2a5e4 kallewoof: reACK 0e2a5e448f426219a6464b9aaadcc715534114e6 jonasnick: ACK 0e2a5e448f426219a6464b9aaadcc715534114e6 almost only looked at bip340/libsecp related code jonatack: ACK 0e2a5e448f426219a6464b9aaadcc715534114e6 modulo the last four commits (tests) that I plan to finish reviewing tomorrow fjahr: reACK 0e2a5e448f426219a6464b9aaadcc715534114e6 achow101: ACK 0e2a5e448f426219a6464b9aaadcc715534114e6 Tree-SHA512: 1b00314450a2938a22bccbb4e177230cf08bd365d72055f9d526891f334b364c997e260c10bc19ca78440b6767712c9feea7faad9a1045dd51a5b96f7ca8146e
| * Activate Taproot/Tapscript on regtest (BIP 341, BIP 342)Pieter Wuille2020-10-121-0/+5
| | | | | | | | | | Define a versionbits-based activation for the new consensus rules on regtest. No activation or activation mechanism is defined for testnet or mainnet.
| * Implement Taproot signature hashing (BIP 341)Johnson Lau2020-10-121-1/+1
| | | | | | | | | | | | | | This implements the new sighashing scheme from BIP341, with all relevant whole-transaction values precomputed once and cached. Includes changes to PrecomputedTransactionData by Pieter Wuille.
| * refactor: keep spent outputs in PrecomputedTransactionDataPieter Wuille2020-10-121-6/+13
| | | | | | | | | | | | A BIP-341 signature message may commit to the scriptPubKeys and amounts of all spent outputs (including other ones than the input being signed for spends), so keep them available to signature hashing code.
* | [validation] Remove absurdfee from accepttomempoolJohn Newbery2020-10-051-11/+6
| | | | | | | | | | | | | | Mempool behavior should not be user-specific. Checking that txfee is acceptable should be the responsibility of the wallet or client, not the mempool.
* | [rpc/node] check for high fee before ATMP in clientsgzhao4082020-10-051-2/+1
|/ | | | | | | Check absurd fee in BroadcastTransaction and RPC, return TransactionError::MAX_FEE_EXCEEDED instead of TxValidationResult::TX_NOT_STANDARD because this is client preference, not a node-wide policy.
* Merge #19898: log: print unexpected version warning in validation log categoryfanquake2020-09-291-4/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 62dba9628d2532dca0c44934600f5aac3b21e275 log: print unexpected version warning in validation log category (nthumann) Pull request description: Fixes #19603: As suggested by practicalswift, instead of always printing `<n> of the last 100 blocks have unexpected version` as a warning appended to UpdateTip, it is now printed in the validation log category and therefore only visible with `-debug=validation` enabled. Before: `2020-09-06T15:56:00Z UpdateTip: new best=00000000000000000001b2872e107a98b57913120e5c6c87ce2715a34c40adf8 height=646969 version=0x20400000 log2_work=92.261571 tx=565651941 date='2020-09-06T10:35:36Z' progress=0.999888 cache=32.2MiB(237417txo) warning='72 of last 100 blocks have unexpected version'` After: `2020-09-06T16:31:26Z UpdateTip: new best=0000000000000000000b3bd786dc42745dd7be4a8c695500a04518cb9e2f4dc1 height=646971 version=0x20000000 log2_work=92.261607 tx=565655901 date='2020-09-06T10:57:19Z' progress=0.999883 cache=3.8MiB(27550txo)` `2020-09-06T16:31:26Z 71 of last 100 blocks have unexpected version` Ran unit & functional tests, confirmed that the warning is now only printed when validation category is enabled. ACKs for top commit: theStack: ACK 62dba9628d2532dca0c44934600f5aac3b21e275 MarcoFalke: re-ACK 62dba96 practicalswift: ACK 62dba9628d2532dca0c44934600f5aac3b21e275 -- only change since last ACK is `s/nUpgraded/num_unexpected_version/` hebasto: re-ACK 62dba9628d2532dca0c44934600f5aac3b21e275, https://github.com/bitcoin/bitcoin/pull/19898#pullrequestreview-483158708 is resolved now. Tree-SHA512: 2100ca7d6d3fd67c92e81d75162d2506d6f1ecf1761d5180d76663fac06771b35e5c4235ebe1a00731b5f7db82db3cd19328627929c8f22912df592686ba51d3
| * log: print unexpected version warning in validation log categorynthumann2020-09-091-4/+6
| | | | | | | | | | | | Instead of printing "<n> of the last 100 blocks have unexpected version" as a warning appended to UpdateTip, it is now printed in the validation log category.
* | Merge #19927: validation: Reduce direct g_chainman usageMarcoFalke2020-09-231-57/+29
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 72a1d5c6f3834e206719ee5121df7727aed5b786 validation: Remove review-only comments + assertions (Carl Dong) 3756853b15902d63f4b5a3129e8b5d82e84e125b docs: Move FindFilesToPrune{,Manual} doxygen comment (Carl Dong) 485899a93c6f5fff62090907efb0ac938992e1fb style: Make FindFilesToPrune{,Manual} match style guide (Carl Dong) 3f5b5f3f6db0e5716911b3fba1460ce327e8a845 validation: Move FindFilesToPrune{,Manual} to BlockManager (Carl Dong) f8d4975ab3fcd3553843cf0862251289c88c106b validation: Move PruneOneBlockFile to BlockManager (Carl Dong) 74f73c783d46b012f375d819e2cd09c792820cd5 validation: Pass in chainman to UnloadBlockIndex (Carl Dong) 4668ded6d6ea4299d998abbb57543f37519812e2 validation: Move ~CMainCleanup logic to ~BlockManager (Carl Dong) Pull request description: This PR paves the way for de-globalizing `g_chainman` entirely by removing the usage of `g_chainman` in the following functions/methods: - `~CMainCleanup` - `CChainState::FlushStateToDisk` - `UnloadBlockIndex` The remaining direct uses of `g_chainman` are as follows: 1. In initialization codepaths: - `AppTests` - `AppInitMain` - `TestingSetup::TestingSetup` 2. `::ChainstateActive` 3. `LookupBlockIndex` - Note: `LookupBlockIndex` is used extensively throughout the codebase and require a much larger set of changes, therefore I've left it out of this initial PR ACKs for top commit: MarcoFalke: re-ACK 72a1d5c6f3 👚 jnewbery: utACK 72a1d5c6f3834e206719ee5121df7727aed5b786 Tree-SHA512: 944a4fa8405eecf39706ff944375d6824373aaeea849d11473f08181eff26b12f70043a8348a5b08e6e9021b243b481842fbdfbc7c3140ca795fce3688b7f5c3
| * | validation: Remove review-only comments + assertionsCarl Dong2020-09-211-39/+0
| | | | | | | | | | | | | | | | | | [META] This is a followup to "validation: Move FindFilesToPrune{,Manual} to BlockManager" removing comments and assertions meant only to show that the change is correct.
| * | docs: Move FindFilesToPrune{,Manual} doxygen commentCarl Dong2020-09-211-16/+0
| | | | | | | | | | | | | | | | | | [META] This is a pure comment commit. They belong in the member declarations in the header file.
| * | style: Make FindFilesToPrune{,Manual} match style guideCarl Dong2020-09-211-7/+12
| | | | | | | | | | | | [META] This is a pure style commit.
| * | validation: Move FindFilesToPrune{,Manual} to BlockManagerCarl Dong2020-09-211-15/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | [META] No behaviour change is intended in this commit. [META] This commit should be followed up by removing the comments and assertions meant only to show that the change is correct. Also stop FindFilesToPrune{,Manual} from unnecessary reaching for ::ChainActive() by passing in the necessary information.
| * | validation: Move PruneOneBlockFile to BlockManagerCarl Dong2020-09-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [META] This is a pure refactor commit. Move PruneBlockFile to BlockManager because: 1. PruneOneBlockFile only acts on BlockManager 2. Eliminates the need for callers (FindFilesToPrune{,Manual}) to have a reference to the larger ChainstateManager, just a reference to BlockManager is enough. See following commits.
| * | validation: Pass in chainman to UnloadBlockIndexCarl Dong2020-09-151-2/+2
| | |
| * | validation: Move ~CMainCleanup logic to ~BlockManagerCarl Dong2020-09-141-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | ~CMainCleanup: 1. Is vestigial 2. References the g_chainman global (we should minimize g_chainman refs) 3. Only acts on g_chainman.m_blockman 4. Does the same thing as BlockManager::Unload
* | | Add 'sequence' zmq publisher to track all block (dis)connects, mempool deltasGregory Sanders2020-09-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the zmq notifications to avoid excessive mempool polling can be difficult given the current notifications available. It announces all transactions being added to mempool or included in blocks, but announces no evictions and gives no indication if the transaction is in the mempool or a block. Block notifications for zmq are also substandard, in that it only announces block tips, while all block transactions are still announced. This commit adds a unified stream which can be used to closely track mempool: 1) getrawmempool to fill out mempool knowledge 2) if txhash is announced, add or remove from set based on add/remove flag 3) if blockhash is announced, get block txn list, remove from those transactions local view of mempool 4) if we drop a sequence number, go to (1) The mempool sequence number starts at the value 1, and increments each time a transaction enters the mempool, or is evicted from the mempool for any reason, including block inclusion. The mempool sequence number is published via ZMQ for any transaction-related notification. These features allow for ZMQ/RPC consumer to track mempool state in a more exacting way, without unnecesarily polling getrawmempool. See interface_zmq.py::test_mempool_sync for example usage.
* | | Merge #18267: BIP-325: Signet [consensus]Wladimir J. van der Laan2020-09-211-23/+14
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8258c4c0076bb5f27efdc117a04b27fcd6dd00b2 test: some sanity checks for consensus logic (Anthony Towns) e47ad375bf17557f805bd206e789b8db78c6338a test: basic signet tests (Karl-Johan Alm) 4c189abdc452f08dfa758564b5381bc78c42d481 test: add small signet fuzzer (practicalswift) ec9b25d046793be50da1c11ba61d1b4b13b295b0 test: signet network selection tests (Karl-Johan Alm) 3efe298dccb248f25d6b01ab6a80b1cd6c9e1a1e signet: hard-coded parameters for Signet Global Network VI (2020-09-07) (Karl-Johan Alm) c7898bca4e1ccbc6edafd3b72eaf80df38e3af32 qt: update QT to support signet network (Karl-Johan Alm) a8de47a1c9033fac3355590f1fe2158a95011bb3 consensus: add signet validation (Karl-Johan Alm) e8990f121405af8cd539b904ef082439261e6c93 add signet chain and accompanying parameters (Karl-Johan Alm) 404682b7cdb54494e7c98f0ba0cac8b51f379750 add signet basic support (signet.cpp) (Karl-Johan Alm) a2147d7dadec1febcd9c2b8ebbbf78dce6d0556b validation: move GetWitnessCommitmentIndex to consensus/validation (Karl-Johan Alm) Pull request description: This PR is a part of BIP-325 (https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki), and is a sub-PR of #16411. * Signet consensus (this) * Signet RPC tools (pending) * Signet utility scripts (contrib/signet) (pending) ACKs for top commit: jonatack: re-ACK 8258c4c0076bb5f27efdc117a04b27fcd6dd00b per `git diff dbeea65 8258c4c`, only change since last review is updated `-signet*` config option naming. fjahr: re-ACK 8258c4c laanwj: ACK 8258c4c0076bb5f27efdc117a04b27fcd6dd00b2 MarcoFalke: Approach ACK 8258c4c007 🌵 Tree-SHA512: 5d158add96755910837feafa8214e13695b769a6aec3a2da753cf672618bef377fac43b0f4b772a87b25dd9f0c1c9b29f2789785d7a7d47a155cdcf48f7c975d
| * | | consensus: add signet validationKarl-Johan Alm2020-09-181-0/+11
| | | |
| * | | validation: move GetWitnessCommitmentIndex to consensus/validationKarl-Johan Alm2020-09-101-23/+3
| | | |
* | | | Merge #19940: rpc: Return fee and vsize from testmempoolacceptfanquake2020-09-191-4/+10
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 23c35bf0059bd6270218e0b732959e9c754f9812 [test] add get_vsize util for more programmatic testing (gzhao408) 2233a93a109b10b6fe0f5f26c2bb529c8de3dde7 [rpc] Return fee and vsize from testmempoolaccept (codeShark149) Pull request description: From #19093 and resolves #19057. Difference from #19093: return `vsize` and `fees` object (similar to `getmempoolentry`) when the test accept is successful. Updates release-notes.md. ACKs for top commit: jnewbery: utACK 23c35bf0059bd6270218e0b732959e9c754f9812 fjahr: utACK 23c35bf instagibbs: reACK https://github.com/bitcoin/bitcoin/pull/19940/commits/23c35bf0059bd6270218e0b732959e9c754f9812 Tree-SHA512: dcb81b7b817a4684e9076bc5d427a6f2d549d2edc66544e718260c4b5f8f1d5ae1d47b754175e9f0c8a3bd8371ce116c2dca0583588d513a7d733d5d614f2b04
| * | | | [rpc] Return fee and vsize from testmempoolacceptcodeShark1492020-09-151-4/+10
| | |/ / | |/| | | | | | | | | | Return fee and vsize if tx would pass ATMP.
* | | | Merge #19879: [p2p] miscellaneous wtxid followupsfanquake2020-09-161-9/+6
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a8a64acaf32ac21feeb885671772282b531ef9a2 [BroadcastTransaction] Remove unsafe move operator (Amiti Uttarwar) 125c0381266e0e05a408f8e1818501ab73d29110 [p2p] Remove dead code (Amiti Uttarwar) fc66d0a65cdc52a3b259effe0c29b5eafb1b5ff5 [p2p] Check for nullptr before dereferencing pointer (Adam Jonas) cb79b9dbf4cd06e17c8c65b36bf15c3ea2641de4 [mempool] Revert unbroadcast set to tracking just txid (Amiti Uttarwar) Pull request description: Addresses some outstanding review comments from #18044 - reverts unbroadcast txids to a set instead of a map (simpler, communicates intent better, takes less space, no efficiency advantages of map) - adds safety around two touchpoints (check for nullptr before dereferencing pointer, remove an inaccurate std::move operator) - removes some dead code Links to comments on wtxid PR: [1](https://github.com/bitcoin/bitcoin/pull/18044#discussion_r460495254) [2](https://github.com/bitcoin/bitcoin/pull/18044#discussion_r460496023) [3](https://github.com/bitcoin/bitcoin/pull/18044#discussion_r463532611) thanks to jnewbery & adamjonas for flagging these ! ! ACKs for top commit: sdaftuar: utACK a8a64acaf32ac21feeb885671772282b531ef9a2 naumenkogs: utACK a8a64acaf32ac21feeb885671772282b531ef9a2 jnewbery: utACK a8a64acaf32ac21feeb885671772282b531ef9a2 Tree-SHA512: 7be669cb30cc17fb9e06b50e636ef7887c6a27354697987e4e4d38dba4b8f50e175647587430cd9bc3295bec01ce8b1e6639a50a4249d8fff9b1ca1b9ead3277
| * | | [mempool] Revert unbroadcast set to tracking just txidAmiti Uttarwar2020-09-041-9/+6
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | When I originally implemented the unbroadcast set in 18038, it just tracked txids. After 18038 was merged, I offered a patch to 18044 to make the unbroadcast changes compatible with wtxid relay. In this patch, I updated `unbroadcast_txids` to a map of txid -> wtxid. Post merge review comments shed light on the fact that this update was unnecessary, and distracting. So, this commit updates the unbroadcast ids back to a set.
* | | Remove mempool globalMarcoFalke2020-09-051-1/+0
| | |
* | | Remove mempool global from initMarcoFalke2020-09-051-0/+8
|/ / | | | | | | | | | | Can be reviewed with the git diff options --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space --ignore-all-space
* / Pass mempool reference to chainstate constructorMarcoFalke2020-08-281-21/+30
|/
* Merge #19660: refactor: Make HexStr take a spanWladimir J. van der Laan2020-08-091-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0a8aa626dd69a357e1b798b07b64cf4177a464a3 refactor: Make HexStr take a span (Wladimir J. van der Laan) Pull request description: Make `HexSt`r take a span of bytes, instead of an awkward pair of templated iterators. This simplifies most of the uses. ACKs for top commit: elichai: Code review ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3 hebasto: re-ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3 jonatack: re-ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3 Tree-SHA512: 6e178ece5cbac62119c857a10299b1e85422938084c3f03063e17119a5129e0c28016e05a6fabaa4c271a7e0a37c7cd89fa47c435ee19b38a5acfe80d00de992
| * refactor: Make HexStr take a spanWladimir J. van der Laan2020-08-061-2/+2
| | | | | | | | | | Make HexStr take a span of bytes, instead of an awkward pair of templated iterators.
* | Merge #19620: Add txids with non-standard inputs to reject filterfanquake2020-08-071-2/+3
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 9f88ded82b2898ca63d44c08072f1ba52f0e18d7 test addition of unknown segwit spends to txid reject filter (Gregory Sanders) 7989901c7eb62ca28b3d1e5d5831041a7267e495 Add txids with non-standard inputs to reject filter (Suhas Daftuar) Pull request description: Our policy checks for non-standard inputs depend only on the non-witness portion of a transaction: we look up the scriptPubKey of the input being spent from our UTXO set (which is covered by the input txid), and the p2sh checks only rely on the scriptSig portion of the input. Consequently it's safe to add txids of transactions that fail these checks to the reject filter, as the witness is irrelevant to the failure. This is helpful for any situation where we might request the transaction again via txid (either from txid-relay peers, or if we might fetch the transaction via txid due to parent-fetching of orphans). Further, in preparation for future witness versions being deployed on the network, ensure that WITNESS_UNKNOWN transactions are rejected in AreInputsStandard(), so that transactions spending v1 (or greater) witness outputs will fall into this category of having their txid added to the reject filter. ACKs for top commit: ajtowns: ACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7 - code review jnewbery: Code review ACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7 ariard: Code Review/Tested ACK 9f88ded naumenkogs: utACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7 jonatack: ACK 9f88ded82b2 Tree-SHA512: 1e93c0a5b68cb432524780ffc0093db893911fdfed9e2ed17f888e59114cc75d2a07062aefad4e5ce2e87c9270886117a8abb3c78fb889c9b9f31967f1777148
| * Add txids with non-standard inputs to reject filterSuhas Daftuar2020-08-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our policy checks for non-standard inputs depend only on the non-witness portion of a transaction: we look up the scriptPubKey of the input being spent from our UTXO set (which is covered by the input txid), and the p2sh checks only rely on the scriptSig portion of the input. Consequently it's safe to add txids of transactions that fail these checks to the reject filter, as the witness is irrelevant to the failure. This is helpful for any situation where we might request the transaction again via txid (either from txid-relay peers, or if we might fetch the transaction via txid due to parent-fetching of orphans). Further, in preparation for future witness versions being deployed on the network, ensure that WITNESS_UNKNOWN transactions are rejected in AreInputsStandard(), so that transactions spending v1 (or greater) witness outputs will fall into this category of having their txid added to the reject filter.
* | Make CHash256/CHash160 output to SpanPieter Wuille2020-07-301-2/+2
| |
* | Make CHash256 and CHash160 consume SpansPieter Wuille2020-07-301-2/+2
| |
* | Pass mempool pointer to GetCoinsCacheSizeStateMarcoFalke2020-07-291-4/+4
| |
* | Pass mempool pointer to UnloadBlockIndexMarcoFalke2020-07-291-2/+2
| |
* | Merge #18637: coins: allow cache resize after initMarcoFalke2020-07-291-4/+67
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | f19fdd47a6371dcbe0760ef6f3c3c5adb31b1bb4 test: add test for CChainState::ResizeCoinsCaches() (James O'Beirne) 8ac3ef46999ed676ca3775f7b2f461d92f09a542 add ChainstateManager::MaybeRebalanceCaches() (James O'Beirne) f36aaa6392fdbdac6891d92202d3efeff98754f4 Add CChainState::ResizeCoinsCaches (James O'Beirne) b223111da2e0e9ceccef75df8a20252b0094b7bc txdb: add CCoinsViewDB::ChangeCacheSize (James O'Beirne) Pull request description: This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11): Parent PR: #15606 Issue: #15605 Specification: https://github.com/jamesob/assumeutxo-docs/tree/master/proposal --- In the assumeutxo implementation draft (#15056), once a UTXO snapshot is loaded, a new chainstate object is created after initialization. This means that we have to reclaim some of the cache that we've allocated to the original chainstate (per `dbcache=`) to repurpose for the snapshot chainstate. Furthermore, it makes sense to have different cache allocations depending on which chainstate is more active. While the snapshot chainstate is working to get to the network tip (and the background validation chainstate is idle), it makes sense that the snapshot chainstate should have the majority of cache allocation. And contrariwise once the snapshot has reached network tip, most of the cache should be given to the background validation chainstate. This set of changes (detailed in the commit messages) allows us to dynamically resize the various coins caches. None of the functionality introduced here is used at the moment, but will be in the next AU PR (which introduces `ActivateSnapshot`). `ChainstateManager::MaybeRebalanceCaches()` defines the (somewhat normative) cache allocations between the snapshot and background validation chainstates. I'd be interested in feedback if anyone has thoughts on the proportions I've set there. ACKs for top commit: ajtowns: weak utACK f19fdd47a6371dcbe0760ef6f3c3c5adb31b1bb4 -- didn't find any major problems, but not super confident that I didn't miss anything fjahr: Code review ACK f19fdd4 ryanofsky: Code review ACK f19fdd47a6371dcbe0760ef6f3c3c5adb31b1bb4. Only change since last review is constructor cleanup (no change in behavior). I think the suggestions here from ajtowns and others are good, but shouldn't delay merging the PR (and hold up assumeutxo) Tree-SHA512: fffb7847fb6993dd4a1a41cf11179b211b0b20b7eb5f7cf6266442136bfe9d43b830bbefcafd475bfd4af273f5573500594aa41fff03e0ed5c2a1e8562ff9269
| * add ChainstateManager::MaybeRebalanceCaches()James O'Beirne2020-07-011-0/+30
| | | | | | | | | | Aside from in unittests, this method is unused at the moment. It will be used in upcoming commits that enable utxo snapshot activation.
| * Add CChainState::ResizeCoinsCachesJames O'Beirne2020-07-011-4/+37
| | | | | | | | | | | | | | | | | | | | Also adds CCoinsViewCache::ReallocateCache() to attempt to free memory that the cacheCoins's allocator may be hanging onto when downsizing the cache. Adds `CChainState::m_coins{tip,db}_cache_size_bytes` data members so that we can reference cache size on a per-chainstate basis for flushing.
* | rpc: Avoid useless mempool query in gettxoutproofMarcoFalke2020-07-261-25/+13
| |
* | Merge #18044: Use wtxid for transaction relayWladimir J. van der Laan2020-07-221-8/+11
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0a4f1422cd1c20e12a05d7ff1a2ef1d5e7c654bb Further improve comments around recentRejects (Suhas Daftuar) 0e20cfedb704c1f76bb727e2009867d3d503a03d Disconnect peers sending wtxidrelay message after VERACK (Suhas Daftuar) cacd85209e20fc0fd08f86eed23b6ef93484ffcf test: Use wtxid relay generally in functional tests (Fabian Jahr) 8d8099e97ab8af2126f6fbd223fbd82c52f2e85e test: Add tests for wtxid tx relay in segwit test (Fabian Jahr) 9a5392fdf67f1c5c90f52d3cdb3dea4f35d1609f test: Update test framework p2p protocol version to 70016 (Fabian Jahr) dd78d1d641178b473ab1156b71a837b9e686792b Rename AddInventoryKnown() to AddKnownTx() (Suhas Daftuar) 4eb515574e1012bc8ea5dafc3042dcdf4c766f26 Make TX_WITNESS_STRIPPED its own rejection reason (Suhas Daftuar) 97141ca442daea8fc9c307cf81a02b38dcc28fd8 Delay getdata requests from peers using txid-based relay (Suhas Daftuar) 46d78d47dea345329ba094310eec56ab00a02ddc Add p2p message "wtxidrelay" (Suhas Daftuar) 2d282e0cba9761574b6b43d134ca95f3052d7fd2 ignore non-wtxidrelay compliant invs (Anthony Towns) ac88e2eb619821ad7ae1d45d4b40be69051d3999 Add support for tx-relay via wtxid (Suhas Daftuar) 8e68fc246d09f1e6c6dfa8c676969d97c2eb4334 Add wtxids to recentRejects instead of txids (Suhas Daftuar) 144c38582042c3b9ec53bb97ba0644fc0114f8fb Add wtxids of confirmed transactions to bloom filter (Suhas Daftuar) 85c78d54af462996a0bca6cf97f91e1aa8778ae8 Add wtxid-index to orphan map (Suhas Daftuar) 08b39955ec7f84e835ab0b1366f0dd28dfd6ce03 Add a wtxid-index to mapRelay (Suhas Daftuar) 60f0acda713e7b9dc188aef54ef93981a93f4e44 Just pass a hash to AddInventoryKnown (Suhas Daftuar) c7eb6b4f1fe5bd76388a023529977674534334a7 Add wtxid to mempool unbroadcast tracking (Amiti Uttarwar) 2b4b90aa8f0440deacefb5997d7bd1f9f5c591b3 Add a wtxid-index to the mempool (Suhas Daftuar) Pull request description: Using txids (a transaction's hash, without witness) for transaction relay is problematic, post-segwit -- if a peer gives us a segwit transaction that fails policy checks, it could be because the txid associated with the transaction is definitely unacceptable to our node (regardless of the witness), or it could be that the transaction was malleated and with a different witness, the txid could be accepted to our mempool. We have a bloom filter of recently rejected transactions, whose purpose is to help us avoid redownloading and revalidating transactions that fail to be accepted, but because of this potential for witness malleability to interfere with relay of valid transactions, we do not use the filter for segwit transactions. This issue is discussed at some length in #8279. The effect of this is that whenever a segwit transaction that fails policy checks is relayed, a node would download that transaction from every peer announcing it, because it has no way presently to cache failure. Historically this hasn't been a big problem, but if/when policy for accepting segwit transactions were to change (eg taproot, or any other change), we could expect older nodes talking to newer nodes to be wasting bandwidth because of this. As discussed in that issue, switching to wtxid-based relay solves this problem -- by using an identifier for a transaction that commits to all the data in our relay protocol, we can be certain if a transaction that a peer is announcing is one that we've already tried to process, or if it's something new. This PR introduces support for wtxid-based relay with peers that support it (and remains backwards compatible with peers that use txids for relay, of course). Apart from code correctness, one issue to be aware of is that by downloading from old and new peers alike, we should expect there to be some bandwidth wasted, because sometimes we might download the same transaction via txid-relay as well as wtxid-relay. The last commit in this PR implements a heuristic I want to analyze, which is to just delay relay from txid-relay peers by 2 seconds, if we have at least 1 wtxid-based peer. I've just started running a couple nodes with this heuristic so I can measure how well it works, but I'm open to other ideas for minimizing that issue. In the long run, I think this will be essentially a non-issue, so I don't think it's too big a concern, we just need to bite the bullet and deal with it during upgrade. Finally, this proposal would need a simple BIP describing the changes, which I haven't yet drafted. However, review and testing of this code in the interim would be welcome. To do items: - [x] Write BIP explaining the spec here (1 new p2p message for negotiating wtxid-based relay, along with a new INV type) - [ ] Measure and evaluate a heuristic for minimizing how often a node downloads the same transaction twice, when connected to old and new nodes. ACKs for top commit: naumenkogs: utACK 0a4f1422cd1c20e12a05d7ff1a2ef1d5e7c654bb laanwj: utACK 0a4f1422cd1c20e12a05d7ff1a2ef1d5e7c654bb Tree-SHA512: d8eb8f0688cf0cbe9507bf738e143edab1f595551fdfeddc2b6734686ea26e7f156b6bfde38bad8bbbe8bec1857c7223e1687f8f018de7463dde8ecaa8f450df
| * | Make TX_WITNESS_STRIPPED its own rejection reasonSuhas Daftuar2020-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, TX_WITNESS_MUTATED could be returned during transaction validation for either transactions that had a witness that was non-standard, or for transactions that had no witness but were invalid due to segwit validation rules. However, for txid/wtxid-relay considerations, net_processing distinguishes the witness stripped case separately, because it affects whether a wtxid should be able to be added to the reject filter. It is safe to add the wtxid of a witness-mutated transaction to the filter (as that wtxid shouldn't collide with the txid, and hence it wouldn't interfere with transaction relay from txid-relay peers), but it is not safe to add the wtxid (== txid) of a witness-stripped transaction to the filter, because that would interfere with relay of another transaction with the same txid (but different wtxid) when relaying from txid-relay peers. Also updates the comment explaining this logic, and explaining that we can get rid of this complexity once there's a sufficient deployment of wtxid-relaying peers on the network.
| * | Add wtxid to mempool unbroadcast trackingAmiti Uttarwar2020-07-181-7/+10
| | |
* | | Merge #19526: log: Avoid treating remote misbehvior as local system errorWladimir J. van der Laan2020-07-221-2/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fa56eda58e5ec2f2345bbe14c798e83f2abb4728 log: Avoid treating remote misbehvior as local system error (MarcoFalke) fa492895b572a1196ca8652006b6fc2fa1d16951 refactor: Switch ValidationState mode to C++11 enum class (MarcoFalke) Pull request description: When logging failures of `CheckBlockHeader` (high-hash), they are always logged as system error. This is problematic for several reasons: * Submitting a blockheader that fails `CheckBlockHeader` over RPC will result in a debug log line that starts with `ERROR`. Proper behaviour should be to log not anything and instead only return the failure reason to the RPC user. This pull does not fix this issue entirely, but is a good first step in the right direction. * A misbehaving peer that sends us an invalid block header that fails `CheckBlockHeader` will result in a debug log line that starts with `ERROR`. Proper behavior should be to log the remote peer misbehavior if logging for that category was enabled. This pull fixes this issue for `CheckBlockHeader` and other functions can be adjusted as well if needed in follow-ups. This should be a good first step in the right direction. ACKs for top commit: practicalswift: re-ACK fa56eda58e5ec2f2345bbe14c798e83f2abb4728 Tree-SHA512: 9793191f5cb57bdff7c93926e94877e8ca2ef89dcebcf9eb155899c733961839ec7c3f9b9f001dc082ada4234fe6e75f6df431301678d6822325840771166d77
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-12 07:30:42 +0000