faa18ca046 wallet: Erase wtxOrderd wtx pointer on removeprunedfunds (MarcoFalke)
Pull request description:
This prevents segfaults, when reading from the freed memory.
Tree-SHA512: 04f8190dea7901cf1cc298d5db98c83b02858f27114c5ef4da738accd176d6647d6b81f3dc39f3d5912b1a981cf0599370fd391c4154ffbde97afc1fac389123
fafa270328 Make ReceivedBlockTransactions return void (MarcoFalke)
Pull request description:
Instead of always returning `bool{true}` and forcing the caller to handle the return code, make it void and remove "a bunch" of dead code at the call sites.
Tree-SHA512: 10e41461c0516c0441d8b8eedcf6385874355c224b9e9d65e89addb142b4cf3e3be2d4ca0a7f2bd95c76aecdaa8537b6bd2d25631bf804bc42863ad5e84fa271
1e1eb6367f Improve coverage of SHA256 SelfTest code (Pieter Wuille)
Pull request description:
The existing SelfTest code does not cover the specialized double-SHA256-for-64-byte-inputs transforms added in #13191. Fix this.
Tree-SHA512: 593c7ee5dc9e77fc4c89e0a7753a63529b0d3d32ddbc015ae3895b52be77bee8a80bf16b754b30a22c01625a68db83fb77fa945a543143542bebb5b0f017ec5b
55771b7c6a Removed unused == operator from CMutableTransaction. (lucash.dev@gmail.com)
Pull request description:
This removes the unused == operator from `CMutableTransaction`.
The motivation is that unused code has a cost but offers no benefit (in general), while also adding the risk of introducing silent bugs. On top of that this particular code is quite inefficient, unnecessarily calculating the hash (it could, say, compare serializations). So if anyone ever needs to use a == comparison on `CMutableTransaction`, they'd be better of having to reimplement it (and add tests) than relying on code that's not being maintained.
Note: after this, trying to use the == operator on CMutableTransactions results in a compilation error:
```
./primitives/transaction.h:405:15: error: invalid operands to binary expression ('CMutableTransaction' and
'CMutableTransaction')
```
Tree-SHA512: a565af563e09d99347b6fe419f6d48c750b1377295af293a3e0c3c0d815e58aede8d7058987a68d66cfa7ed023e5d3285b12afabd17d0ff9cf11322ba3ce20fe
47776a958b Add linter: Make sure all shell scripts opt out of locale dependence using "export LC_ALL=C" (practicalswift)
3352da8da1 Add "export LC_ALL=C" to all shell scripts (practicalswift)
Pull request description:
~~Make sure `LC_ALL=C` is set when using `grep` range expressions.~~
Make sure `LC_ALL=C` is set in all shell scripts.
From the `grep(1)` documentation:
> Within a bracket expression, a range expression consists of two characters separated by a hyphen. It matches any single character that sorts between the two characters, inclusive, using the locale's collating sequence and character set. For example, in the default C locale, `[a-d]` is equivalent to `[abcd]`. Many locales sort characters in dictionary order, and in these locales `[a-d]` is typically not equivalent to `[abcd]`; it might be equivalent to `[aBbCcDd]`, for example. To obtain the traditional interpretation of bracket expressions, you can use the C locale by setting the `LC_ALL` environment variable to the value C.
Context: [Locale issue found when reviewing #13450](https://github.com/bitcoin/bitcoin/pull/13450/files#r194877736)
Tree-SHA512: fd74d2612998f9b49ef9be24410e505d8c842716f84d085157fc7f9799d40e8a7b4969de783afcf99b7fae4f91bbb4559651f7dd6578a6a081a50bdea29f0909
9b72c988a0 scripted-diff: Avoid temporary copies when looping over std::map (Ben Woosley)
Pull request description:
The ::value_type of the std::map/std::multimap/std::unordered_map containers is
std::pair<const Key, T>. Dropping the const results in an unnecessary copy,
for example in C++11 range-based loops.
For this I started with a more general scripted diff, then narrowed it down
based on the inspection showing that all actual map/multimap/unordered_map
variables used in loops start with m or have map in the name.
Tree-SHA512: b656d66b69ffa1eb954124aa8ae2bc5436ca50262abefa93bdda55cfcdaffc5ff90cd40539051a2bd06355ba69ddf245265cc8764eebff66d761b3aec06155a9
25bc9615b7 Document validationinterace callback blocking deadlock potential. (Matt Corallo)
Pull request description:
From the branches-I've-had-lying-around-and-forgot-to-PR department...
This is a comment-only PR, but the comments point out an API quirk that isn't exactly trivial. None of our use-cases right now hit this, but if we were to call SyncWithValidationInterfaceQueue (eg to limit queue depth) in ATMP, I'm pretty sure we'd hit a deadlock there.
Tree-SHA512: 889dd8fc9eb15d1f2aa5ca467e783bc8f07bc543b166b032741795b0db7a0df11a2846d3cb7c69bafa8d1acf970021001b742f52be06725a932813230c5b4a7b
86edf4a2a5 expose CBlockIndex::nTx in getblock(header) (Gregory Sanders)
Pull request description:
Recent publication of a weakness in Bitcoin's merkle tree construction demonstrates many SPV applications vulnerable to an expensive to pull off yet still plausible attack: https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/
Including the coinbase in the txoutproof seems the most effective fix, however results in a significant efficiency downgrade. Transactors will not even know a priori what the size of their proof will be within a couple orders of magnitude, unless they use the mid-state of SHA2 as detailed in the blog post.
Some applications, like Elements blockchain platform that take SPV-style proofs have optional access to a bitcoind to verify these proofs of inclusion and check depth in the chain. Returning `CBlockIndex::nTx` would allow an extremely easy and compact way of checking the depth of the tree, with no additional overhead to the codebase, and works with pruned nodes.
`getblockheader` is arguably not the place for it, but as mentioned before, is a natural workflow for us checking depth of a block in a possibly pruned node.
We should also ensure that `verifytxoutproof` ends up validating this depth fact as well, but left this for another PR.
Tree-SHA512: af4cf48e704c6088f8da06a477fda1aaa6f8770cee9b876c4465d1075966d6a95831a88817673fe5a0d6bbcdc1ffcbc1892e2be0d838c60fc6958d33eacdcc14
c2dfbb4a97 Add unavailable options to hidden options category (Andrew Chow)
Pull request description:
From IRC:
```
<ossifrage> FYI, bitcoin-qt from the head I built today won't start if you have "daemon=0" in the config file, so you can't use the same config for either bitcoind or bitcoin-qt
<ossifrage> Seems like bitcoin-qt should ignore this option?
<provoostenator> ossifrage: probably caused by 13112. Another problem is disablewallet=1 will prevent a launch if you compile bitcoind without wallet. It probably needs to be relaxed slightly.
```
Adds all of the options that are unavailable due to compiling options to the hidden category so that shared config files do not break with the alternative binaries.
Tree-SHA512: 1ef43f5f7ad46ecc2865d22ee683ef22831e8f131ec99b732bb36d90381f7964bf64829595e993c2d435823fe4425a20323c8e65307cf2463a9e40b8049ab559
faf52f953b tests: Drop variadic macro (MarcoFalke)
Pull request description:
The C++11 constructor of `std::vector` that takes an initializer list, is not `explicit`. Thus, the macro is not required and can be dropped.
Hopefully fixes#13456
Tree-SHA512: 4095ed205f88138a7cd5b14790cc426899966f622a924a9b3f7de646a0d801a48ffb8921da760f1f93d5481298477c8a64dbec291381bb9aa77b075bdd2659f2
f6f8026e40 validation: check the specified number of blocks (off-by-one) (Karl-Johan Alm)
Pull request description:
```
echeveria | 2018-06-11 02:03:03.384975 Verifying last 3 blocks at level 3
echeveria | 2018-06-11 02:03:23.676793 No coin database inconsistencies in last 4 blocks (6564 transactions)
echeveria | off by one?
sipa | echeveria: possibly!
kallewoof | Looks like it checks one more block than suggested. `if (pindex->nHeight < chainActive.Height()-nCheckDepth) break;` should probably be `<=`.
sipa | kallewoof: agree
```
Post-commit:
```
2018-06-11T05:24:02Z Verifying last 6 blocks at level 3
2018-06-11T05:24:02Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2018-06-11T05:25:07Z No coin database inconsistencies in last 6 blocks (7258 transactions)
```
Pre-commit:
```
2018-06-11T05:27:11Z Verifying last 6 blocks at level 3
2018-06-11T05:27:11Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2018-06-11T05:27:12Z No coin database inconsistencies in last 7 blocks (9832 transactions)
```
Tree-SHA512: 6e68dc4ba74232518c2ba8ea624d65893534f3619d43ccdf0b9c65992f25b68cb52cf54fa35e6e3d092d1eee5c9a8887057828895f1acdafc0ebb48f683fffdc
Options that are not available (but known in the source code) will
cause an error if they are specified.
Make these options "available" by adding them to the hidden options
category to prevent conf files from failing when shared between binaries
that have different options available.
57ba401abc Enable double-SHA256-for-64-byte code on 32-bit x86 (Pieter Wuille)
Pull request description:
The SSE4 and AVX2 double-SHA256-for-64-byte input code from #13191 compiles fine on 32-bit x86 systems, but the autodetection logic in sha256.cpp doesn't enable it. Fix this.
Note that these instruction sets are only available on CPUs that support 64-bit mode as well, so it is only beneficial in the (perhaps unlikely) scenario where a 64-bit CPU is running a 32-bit Bitcoin Core binary.
Tree-SHA512: 39d5963c1ba8c33932549d5fe98bd184932689a40aeba95043eca31dd6824f566197c546b60905555eccaf407408a5f0f200247bb0907450d309b0a70b245102
fa7a6cf1b3 policy: Treat segwit as always active (MarcoFalke)
Pull request description:
Now that segwit is active for a long time, there is no need to reject transactions with the reason that segwit hasn't activated.
Strictly speaking, this is a bug fix, because with the release of 0.16, we create segwit transactions in our wallet by default without checking if they are allowed by local policy.
More broadly, this simplifies the code as if "premature witness" was always set to true with the corresponding command line args.
Tree-SHA512: 484c26aa3a66faba6b41e8554a91a29bfc15fbf6caae3d5363a3966283143189c4bd5333a610b0669c1238f75620691264e73f6b9f1161cdacf7574d946436da
e56771365b Do not use uppercase characters in source code filenames (practicalswift)
419a1983ca docs: Add a note about the source code filename naming convention (practicalswift)
Pull request description:
Add a note about the source code filename naming convention.
Tree-SHA512: 8d329bd9e19bcd26e74b0862fb0bc2369b46095dbd3e69d34859908632763abd7c3d00ccc44ee059772ad4bae4460c2bcc1c0e22fd9d8876d57e5fcd346cea4b
The ::value_type of the std::map/std::multimap/std::unordered_map containers is
std::pair<const Key, T>. Dropping the const results in an unnecessary copy,
for example in C++11 range-based loops.
For this I started with a more general scripted diff, then narrowed it down
based on the inspection showing that all actual map/multimap/unordered_map
variables used in loops start with m or have map in the name.
-BEGIN VERIFY SCRIPT-
sed -i -E 's/for \(([^<]*)std::pair<([^c])(.+) : m/for (\1std::pair<const \2\3 : m/' src/*.cpp src/**/*.cpp
sed -i -E 's/for \(([^<]*)std::pair<([^c])(.+) : (.*)map/for (\1std::pair<const \2\3 : \4map/' src/*.cpp src/**/*.cpp
-END VERIFY SCRIPT-
16e3cd380a Clarify include recommendation (practicalswift)
6d10f43738 Enforce the use of bracket syntax includes ("#include <foo.h>") (practicalswift)
906bee8e5f Use bracket syntax includes ("#include <foo.h>") (practicalswift)
Pull request description:
When analysing includes in the project it is often assumed that the preferred bracket include syntax (`#include <foo.h>`) mentioned in `developer-docs.md` is used consistently. @sipa:s excellent circular dependencies script [`circular-dependencies.py`](50c69b7801/contrib/devtools/circular-dependencies.py) (#13228) is an example of a script making this reasonable assumption.
This PR enables automatic Travis checking of the include syntax making sure that the bracket syntax includes (`#include <foo.h>`) is used consistently.
Tree-SHA512: a414921aabe8e487ebed42f3f1cbd02fecd1add385065c1f2244cd602c31889e61fea5a801507ec501ef9bd309b05d3c999f915cec1c2b44f085bb0d2835c182
f77e1d34fd test: Add MempoolAncestryTests (Karl-Johan Alm)
a08d76bcfe mempool: Calculate descendant maximum thoroughly (Karl-Johan Alm)
6d3568371e wallet: Switch to using ancestor/descendant limits (Karl-Johan Alm)
6888195b06 wallet: Strictly greater than for ancestor caps (Karl-Johan Alm)
322b12ac4e Remove deprecated TransactionWithinChainLimit (Karl-Johan Alm)
4784751547 Switch to GetTransactionAncestry() in OutputEligibleForSpending (Karl-Johan Alm)
475a385a80 Add GetTransactionAncestry to CTxMemPool for general purpose chain limit checking (Karl-Johan Alm)
46847d69d2 mempool: Fix max descendants check (Karl-Johan Alm)
b9ef21dd72 mempool: Add explicit max_descendants (Karl-Johan Alm)
Pull request description:
Currently, `TransactionWithinChainLimit` is restricted to single-output use, and needs to be called every time for different limits. If it is replaced with a chain limit value calculator, that can be called once and reused, and is generally more flexible (see e.g. #12257).
Update: this PR now corrects usage of max ancestors / max descendants, including calculating the correct max descendant value, as advertised for the two limits.
~~This change also makes `nMaxAncestors` signed, as the replacement method will return `-1` for "not in the mempool", which is different from "0", which means "no ancestors/descendants in mempool".~~
~~This is a subset of #12257.~~
Tree-SHA512: aa59c849360542362b3126c0e29d44d3d58f11898e277d38c034dc4b86a5b4500f77ac61767599ce878c876b5c446fec9c02699797eb2fa41e530ec863a00cf9
67e0e04140 [wallet] [docs] Update release notes for removing `getlabeladdress` (John Newbery)
81608178cf [wallet] [rpc] Remove getlabeladdress RPC (John Newbery)
Pull request description:
labels are associated with addresses (rather than addresses being
associated with labels, as was the case with accounts). The
getlabeladdress does not make sense in this model, so remove it.
getaccountaddress is still supported for one release as the accounts
API is deprecated.
Tree-SHA512: 7f45d0456248ebcc4e54dd34e2578a09a8ea8e4fceda75238ccea9d731dc99a3f3c0519b18a9739de17d2e6e59c9c2259ba67c9ae2e3cb2a40ddb14b9193fe29
f68049dd87 crypto: cleanup sha256 build (Cory Fields)
Pull request description:
Requested by @sipa in #13386.
Rather than appending all possible cpu variants to all targets, create a convenience variable that encompasses all.
Tree-SHA512: 8e9ab2185515672b79bb7925afa4f3fbfe921bfcbe61456833d15457de4feba95290de17514344ce42ee81cc38b252476cd0c29432ac48c737c2225ed515a4bd
cbede7dbfd [qt] OptionsDialog: add prune setting (Sjors Provoost)
Pull request description:
The default suggested value is 2 GB. Minimum is 1 GB (550 MB rounded up).
When the user toggles this setting, a strong warning appears that undoing requires re-downloading the chain:
<img width="478" alt="schermafbeelding 2018-05-15 om 12 35 24" src="https://user-images.githubusercontent.com/10217/40051858-7939cc20-583c-11e8-9120-327a75376732.png">
Tooltip points out that actual disk usage can be higher. It's a bit vague on the "advanced features", because I'm assuming anyone who needs to use `-rescan` and `-txindex` will read the documentation, and a more detailed text would needlessly confuse everyone else.
<img width="450" alt="schermafbeelding 2018-05-15 om 12 33 51" src="https://user-images.githubusercontent.com/10217/40051791-49d6156a-583c-11e8-97b9-7de6dfd8c481.png">
The UI uses gigabytes for readability and easy of use. There is also no manual pruning UI (`prune=1`). The user will have to use `bitcoin.conf` for those things.
Fixes#6461. When combined with #13029 the user, after pruning their node, can safely reset settings and/or use bitcoind without having to edit `bitcoin.conf`. However I don't think that's an essential prerequisite.
Tree-SHA512: e17aff276d7235fbd40796adb6431d430620788a753ee13bc064abd35d2edc4280a3d3cddc18e42b4e00edff13ed18fd4f2a966c6f0b43b689afd13673e0c4bf
Instead of combining the -limitancestorcount and -limitdescendantcount into a nMaxChainLength, this commit uses each one separately in the coin eligibility filters.
The chain limits check for max descendants would check the descendants of the transaction itself even though the description for -limitdescendantcount says 'any ancestor'. This commit corrects the descendant count check by finding the top parent transaction in the mempool and comparing against that.
TransactionWithinChainLimits would take a 'limit' and check it against ascendants and descendants. This is changed to take an explicit
max ancestors and max descendants value, and to test the corresponding value against its corresponding max.
e9a1881b90 refactor: add a function for determining if a block is pruned or not (Karl-Johan Alm)
Pull request description:
The check for whether a block is pruned or not is sufficiently obscure that it deserves a macro. It is also used in 2 places, ~~with more coming, e.g. #10757~~ (turns out it was a move, not an addition).
Tree-SHA512: b9aeb60663e1d1196df5371d5aa00b32ff5d4cdea6a77e4b566f28115cce09570c18e45e4b81a4033f67c4135c8e32c027f67bae3b75c2ea4564285578a3f4dd
2acd1d6716 Drop uint 256 not operator (Ben Woosley)
Pull request description:
All the other operators are integer or bitwise operations, and this is unused
apart from tests.
Note attempting to call `!` on `arith_uint256` results in a build error after this change:
```
test/arith_uint256_tests.cpp:201:17: error: invalid argument type 'const arith_uint256' to unary expression
BOOST_CHECK(!ZeroL);
```
Tree-SHA512: 5791b643f426dac9829e9499d678786f1ad294edb2d840879252a1b642bda55941632114f64048660a5991a984aeba49eeb5dfe64ba0a6275cbe7b1c049d7095
ec3073a274 index: Move index DBs into index/ directory. (Jim Posen)
89eddcd365 index: Remove TxIndexDB from public interface of TxIndex. (Jim Posen)
2318affd27 MOVEONLY: Move BaseIndex to its own file. (Jim Posen)
f376a49241 index: Generalize logged statements in BaseIndex. (Jim Posen)
61a1226d87 index: Extract logic from TxIndex into reusable base class. (Jim Posen)
e5af5fc6fb db: Make reusable base class for index databases. (Jim Posen)
9b0ec1a7f9 db: Remove obsolete methods from CBlockTreeDB. (Jim Posen)
Pull request description:
This refactors most of the logic in TxIndex into a reusable base class for other indices. There are two commits moving code between files, which may be be more easily reviewed using `git diff --color-moved` (https://blog.github.com/2018-04-05-git-217-released/).
The motivation for this is to support BIP 157 by indexing block filters.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/bitcoin/bitcoin/13243)
<!-- Reviewable:end -->
Tree-SHA512: 0857f04df2aa920178dab2eb8e57984d8eb4d5010deca9971190358479e05b6672ccca2a08af0a7ac9fe02afb947be84cf35a3693204d0667263c6add2959cbf
ebebedce20 speed up of tx_validationcache_tests by reusing of CTransaction. (lucash.dev@gmail.com)
Pull request description:
The code was converting CMutableTransaction to CTransaction multiple times, which implies recalculating the hash multiple times. This commit fixes this by reusing a single CTransaction.
Run-time results:
```
Before: 6.7s
After: 5.5s
--------------
Saved: 1.2s
```
This PR was split from #13050. Also, see #10026.
Tree-SHA512: 61fb81972a08299085a7d3d0060485b265aefc7a4f82ab548e5f94371c8643cfb97bf0ef34f4e1211bf853d0217fa1c3338e4117f36fda1b37d203f690e86d60
0231ef6c6d cli: Ignore libevent warnings (Cory Fields)
Pull request description:
Should fix rpc tests that fail due to an unclean stderr.
Untested as I'm not seeing these warnings. @promag mind seeing if this fixes your problem?
Tree-SHA512: fba5ae3f239b515e93e19f9c3eca659eb7fb21f1b1fec25b68285695bfd1ecbdcd9b2235543689aaf97bff85cbb762840f65365a67e791314e9a6b8db2c9e246
The code was converting CMutableTransaction to CTransaction multiple times, which implies recalculating the hash multiple times. This commit fixes this by reusing a single CTransaction.
