4defdfab94 [MOVEONLY] Move unused Merkle branch code to tests (Pieter Wuille)
4437d6e1f3 8-way AVX2 implementation for double SHA256 on 64-byte inputs (Pieter Wuille)
230294bf5f 4-way SSE4.1 implementation for double SHA256 on 64-byte inputs (Pieter Wuille)
1f0e7ca09c Use SHA256D64 in Merkle root computation (Pieter Wuille)
d0c9632883 Specialized double sha256 for 64 byte inputs (Pieter Wuille)
57f34630fb Refactor SHA256 code (Pieter Wuille)
0df017889b Benchmark Merkle root computation (Pieter Wuille)
Pull request description:
This introduces a framework for specialized double-SHA256 with 64 byte inputs. 4 different implementations are provided:
* Generic C++ (reusing the normal SHA256 code)
* Specialized C++ for 64-byte inputs, but no special instructions
* 4-way using SSE4.1 intrinsics
* 8-way using AVX2 intrinsics
On my own system (AVX2 capable), I get these benchmarks for computing the Merkle root of 9001 leaves (supported lengths / special instructions / parallellism):
* 7.2 ms with varsize/naive/1way (master, non-SSE4 hardware)
* 5.8 ms with size64/naive/1way (this PR, non-SSE4 capable systems)
* 4.8 ms with varsize/SSE4/1way (master, SSE4 hardware)
* 2.9 ms with size64/SSE4/4way (this PR, SSE4 hardware)
* 1.1 ms with size64/AVX2/8way (this PR, AVX2 hardware)
Tree-SHA512: efa32d48b32820d9ce788ead4eb583949265be8c2e5f538c94bc914e92d131a57f8c1ee26c6f998e81fb0e30675d4e2eddc3360bcf632676249036018cff343e
f41d339b78 bench: Use non-throwing ParseDouble(...) instead of throwing boost::lexical_cast<double>(...) (practicalswift)
Pull request description:
* Non-Boost is better than Boost.
* Non-throwing is better than throwing.
* Explicit error handling is better than implicit error handling.
* `ParseDouble(…)` deserves to be used outside of its unit tests :-)
Tree-SHA512: a8cf04a5f8363cb7ced0bcaf1fed00e1e5dd6a63a6c11e5f0ba4e5c845b0df7c2b050d887075f158cd62dc7e02843ecaafc15e42e383c066461c6d7399e06b49
1e4eec47be doc: split FreeBSD build instructions out of build-unix.md (steverusso)
Pull request description:
I've found that the instructions for how to build on FreeBSD are difficult to find. (They are located at the very bottom of the `build-unix.md` guide.)
In the beginning of the `build-unix.md` guide, there is a list for "BSD specific instructions" which has links to the `build-netbsd.md` and `build-openbsd.md` guides. I figured that the FreeBSD build instructions should be linked to as well in that list which would make them easier to discover.
(I also think the argument could be made to separate out the FreeBSD build instructions into a `build-freebsd.md` guide, which I'd be happy to do, but I'll leave that for discussion.)
Tree-SHA512: 02d7939778ae2b9a4ef8f053ff296455be05023c1c557dcc25a963eb829d84524bd34d39e6863f2e68b655832194d38bffec3286106588ae32f006686a1b36a9
docs: Linked to the 'Building on FreeBSD' section of the Unix guide where it lists BSD specific guides.
Created a FreeBSD build guide (doc/build-freebsd.md).
Added in warning about the version of 'gdb' installed by default.
Removed the FreeBSD build instructions now that they have their own guide (doc/build-freebsd.md).
Updated the sentence to refer to the BSD guides in the 'doc' directory for more specific BSD build instructions.
Minor grammatical fix.
faac7a2db4 qa: Avoid checking reject code for now (MarcoFalke)
Pull request description:
The node will often disconnect before sending a reject code. A more
robust solution would be to read from the debug log. See #13006
Tree-SHA512: 1dabf8a43dabbc722f4ffe4fbc1f870090253a66290b2d1a95e7a24e14c6442b493c314480c0314587164eb65e5d468aa9eb5e107ad90bb3ca821a97ea4d373c
fa26cf0156 qa: Fixup setting of PATH env var (MarcoFalke)
Pull request description:
This was an oversight of mine in #13188
Can be trivially tested with `BITCOIND=bitcoin-qt ./test/functional/wallet_disable.py` before and after this fix.
Tree-SHA512: 06c7b2f12158855eb2b6392861943821bd7ad3152cf0dd49ac4abd878e5b937ebee55e256ce5bdc1c2a9c775a452112c34533366c934ff5f0f412b3a7e1c8118
db56755ca4 Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (practicalswift)
Pull request description:
Fixes#13337 (!)
GNU grep and BSD grep differs in the way they handle regexps when extended regular expressions are not enabled via the `-E` flag:
```
$ grep --version | head -1
grep (GNU grep) 3.1
$ echo "BOOST_FIXTURE_TEST_SUITE(foo)" | grep "BOOST_FIXTURE_TEST_SUITE(\|BOOST_AUTO_TEST_SUITE("
BOOST_FIXTURE_TEST_SUITE(foo)
$
```
```
$ grep --version | head -1
grep version 0.9
$ echo "BOOST_FIXTURE_TEST_SUITE(foo)" | grep "BOOST_FIXTURE_TEST_SUITE(\|BOOST_AUTO_TEST_SUITE("
$
```
The portable way to do it is:
```
$ echo "BOOST_FIXTURE_TEST_SUITE(foo)" | grep -E "(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()"
BOOST_FIXTURE_TEST_SUITE(foo)
$
```
Tree-SHA512: d83c78f34421504dd8efc3921c98527f499045b702bd34715a5bc78e04ef2a5f49f601a55ad08632e870f137b1edada94a3f530291bc9107d8d6b16fe11e640b
493a166948 bench: Don't return a bool from main (Wladimir J. van der Laan)
Pull request description:
Return `1` from `main()` on error, not the bool `false` (introduced in #13112). This is the correct value to return on error, and also shuts up a clang warning.
Tree-SHA512: 52a0f1b2f6ae2697555f71ee2019ce657046f7f379f1f4faf3cce9d5f3fb21fcdc43a4c84895a2a8b6929997ba70bbe87c231f2f9553215b84c22333810d58d9
6b8b63af14 Generic TransactionSignatureCreator works with both CTransaction and CMutableTransaction (Martin Ankerl)
Pull request description:
Refactored `TransactionSignatureCreator` into a templated `GenericTransactionSignatureCreator` that works with both `CMutableTransaction` and `CTransaction`.
The advantage is that now in `SignSignature`, the `MutableTransactionSignatureCreator` can now operate directly with the `CMutableTransaction` without the need to copy the data into a `CTransaction`.
Running all unit tests brings a very noticable speedup on my machine:
48.4 sec before this change
36.4 sec with this change
--------
12.0 seconds saved
running only `--run_test=transaction_tests/test_big_witness_transaction`:
16.7 sec before this change
5.9 sec with this change
--------
10.8 seconds saved
This relates to my first attempt with the const_cast hack #13202, and to the slow unit test issue #10026.
Also see #13050 which modifies the tests but not the production code (like this PR) to get a speedup.
Tree-SHA512: 2cff0e9699f484f26120a40e431a24c8bc8f9e780fd89cb0ecf20c5be3eab6c43f9c359cde244abd9f3620d06c7c354e3b9dd3da41fa2ca1ac1e09386fea25fb
Return `EXIT_SUCCESS` from `main()` on error, not the bool `false`
(introduced in #13112). This is the correct value to return on error,
and also shuts up a clang warning.
Also add a final return for clarity.
903055730b Test gArgs erroring on unknown args (Andrew Chow)
4f8704d57f Give an error and exit if there are unknown parameters (Andrew Chow)
174f7c8080 Use a struct for arguments and nested map for categories (Andrew Chow)
Pull request description:
Following #13190, gArgs is aware of all of the command line arguments. This PR has gArgs check whether the arguments provided are actually valid arguments. When an unknown argument is encountered, an error is printed to stderr and the program exist.
Since gArgs is used for everything that has command line arguments, `bitcoind`, `bitcoin-cli`, `bitcoin-qt`, `bitcoin-tx`, and `bench_bitcoin` are all effected by this change and all now have the same argument checking behavior.
Closes#1044
Tree-SHA512: 388201319a7d6493204bb5433da47e8e6c8266882e809f6df45f86d925f1f320f2fd13edb3e57ffc6a37415dfdfc689f83929452bca224229783accb367032e7
4b62bdf513 Wallet: Refactor ReserveKeyFromKeyPool for safety (Ben Woosley)
Pull request description:
ReserveKeyFromKeyPool's previous behaviour is to set nIndex to -1 if the keypool is
empty, OR throw an exception for technical failures. Instead, we now return false
if the keypool is empty, true if the operation succeeded.
This is to make failure more easily detectable by calling code.
Tree-SHA512: 753f057ad13bd4c28d121f426bf0967ed72b827d97fb24582f9326ec60072abc5482e3db69ccada7c5fc66de9957fc59098432dd223fc4116991cab44c6d7aef
If an unknown option is given via either the command line args or
the conf file, throw an error and exit
Update tests for ArgsManager knowing args
Ignore unknown options in the config file for bitcoin-cli
Fix tests and bitcoin-cli to match actual options used
Instead of a single map with the category and name as the key,
make m_available_args contain maps. The key will be the category and
the value is a map which actually contains the arguments for that
category. The nested map's key is the argument name, while the value
is a struct that contains the help text and whether the argument is
a debug only argument.
c814e2e7e8 Remove template matching and pseudo opcodes (Pieter Wuille)
Pull request description:
The current code contains a rather complex script template matching engine, which is only used for 3 particular script types (P2PK, P2PKH, multisig). The first two of these are trivial to match for otherwise, and a specialized matcher for multisig is both more compact and more efficient than a generic one.
The goal is being more flexible, so that for example larger standard multisigs inside SegWit outputs are easier to implement.
As a side-effect, it also gets rid of the pseudo opcodes hack.
Tree-SHA512: 643b409c5c36821519f613a43efd399af0ec99b6131f35cd4024decfb2d483d719e0e921cd088bc9832a7ac797cb4a6b1158b8574c82f7fbebb75f1b31b359df
Templated version so that no copying of CMutableTransaction into a CTransaction is
necessary. This speeds up the test case transaction_tests/test_big_witness_transaction
from 7.9 seconds to 3.1 seconds on my machine.
3d4fa83587 Stop translating command line options (Wladimir J. van der Laan)
Pull request description:
Many options are extremely technical, and refer internals, making it difficult to translate usefully. This came up in discussion of e.g. #10949. If a message is not understood by translators (which are typically end-users, not developers) they'll either translate it literally, making it harder to understand instead of easier, with the added drawback of the user no longer being able to google it.
Also the translation was only working for bitcoin-qt as with the console programs, there is no translation backend. So it was injecting never-used translation messages for bitcoin-cli, -tx.
For these reasons, stop translating options help completely. This should not affect the output **in any way** \* except for bitcoin-qt when a non-English language is configured in the locale.
This implements #10962.
\*) I checked this, but please do verify this.
Tree-SHA512: 46c5f2ac0d4dbe9a6710fab498781e442dd6d6ac17613a99fcfe7a62bf6811fa1c92400d35bd389772cb4b31c6918df261548cbc677addba653f44083b9aeeda
Many options are extremely technical, and refer internals, making it
difficult to translate usefully. This came up in discussion of e.g.
#10949. If a message is not understood by translators (which are
typically end-users, not developers) they'll either translate it
literally, making it harder to understand instead of easier, with the
added drawback of the user no longer being able to google it.
Also the translation was only working for bitcoin-qt as with
the console programs, there is no translation backend. So it was
injecting never-used translation messages for bitcoin-cli, -tx.
For these reasons, stop translating options help completely. This should
not affect the output **in any way** except for bitcoin-qt when a
non-English language is configured in the locale.
This implements #10962.
The current code contains a rather complex script template matching engine,
which is only used for 3 particular script types (P2PK, P2PKH, multisig).
The first two of these are trivial to match for otherwise, and a specialized
matcher for multisig is both more compact and more efficient than a generic
one.
The goal is being more flexible, so that for example larger standard multisigs
inside SegWit outputs are more easy to implement.
As a side-effect, it also gets rid of the pseudo opcodes hack.
59e9688eda Travis: Build tests on Ubuntu 18.04 with docker (Chun Kuan Lee)
Pull request description:
Compile and run tests on Ubuntu 18.04 docker.
Tree-SHA512: 4ae5f0cf666abeff2f3e3f541d33e5c76970c5129e60d0299317d73621fafa6f0f1c6cfe7a7d1089200f29ecb1a0a61a22bc116474eb5226282939e0beb37cb8
fa3c910bfe test: Move linters to test/lint, add readme (MarcoFalke)
Pull request description:
This moves the checks and linters from `devtools` to a subfolder in `test`. (Motivated by my opinion that the dev tools are mostly for generating code and updating the repo whereas the linters are read-only checks.)
Also, adds a readme to clarify that checks and linters are only meant to prevent bugs and user facing issues, not merely stylistic preference or inconsistencies. (This is motivated by the diversity in developers and work flows as well as existing code styles. It would be too disruptive to change all existing code to a single style or too burdensome to force all developers to adhere to a single style. Also note that our style guide is changing, so locking in at the wrong style "too early" would only waste resources.)
Tree-SHA512: 9b10e89f2aeaf0c8a9ae248aa891d74e0abf0569f8e5dfd266446efa8bfaf19f0ea0980abf0b0b22f0d8416ee90d7435d21a9f9285b66df43f370b7979173406
87fe292d89 doc: Mention disabling BIP61 in bips.md (Wladimir J. van der Laan)
fe16dd8226 net: Add option `-enablebip61` to configure sending of BIP61 notifications (Wladimir J. van der Laan)
Pull request description:
This commit adds a boolean option `-peersendreject`, defaulting to `1`, that can be used to disable the sending of [BIP61](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki) `reject` messages. This functionality has been requested for various reasons:
- security (DoS): reject messages can reveal internal state that can be used to target certain resources such as the mempool more easily.
- bandwidth: a typical node sends lots of reject messages; this counts against upstream bandwidth. Also the reject messages tend to be larger than the message that was rejected.
On the other hand, reject messages can be useful while developing client software (I found them indispensable while creating bitcoin-submittx), as well as for our own test cases, so whatever the default becomes on the long run, IMO the functionality should be retained as option. But that's a discussion for later, for now it's simply a node operator decision.
Also adds a RPC test that checks the functionality.
Tree-SHA512: 9488cc53e13cd8e5c6f8eb472a44309572673405c1d1438c3488f627fae622c95e2198bde5ed7d29e56b948e2918bf1920239e9f865889f4c37c097c37a4d7a9
13c3a659c0 Qt/Bugfix: fix handling default wallet with no name (João Barbosa)
Pull request description:
If one loads a wallet via RPC (`loadwallet w2`), then select w2, select back to the default wallet (which is an empty string), that default wallet cannot be access through the RPC console because the current code only points to the wallet endpoint if the wallet name is not empty.
This is a quick fix that reenables accessing the default wallet in case an additional wallet has been loaded.
Using "" for the default wallet may not be ideal in other cases and it may make more sense to change it at a deeper level (wallet.cpp). See discussion here which where the reasons for the current behaviour in master:
https://github.com/bitcoin/bitcoin/pull/11687#issuecomment-370862718
@jnewbery @promag @ryanofsky
Tree-SHA512: 74b935886b4e4a6033a2f5e1f44bb69a252e31f4021e19a2054445a8e3e4db1d8ee256290850a84d8569d2d0e21412fce0170e7f0e881259156057587181ee05
