Age | Commit message (Collapse) | Author |
|
All the other operators are integer or bit operations, and this is unused
apart from tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4defdfab94504018f822dc34a313ad26cedc8255 [MOVEONLY] Move unused Merkle branch code to tests (Pieter Wuille)
4437d6e1f3107a20a8c7b66be8b4b972a82e3b28 8-way AVX2 implementation for double SHA256 on 64-byte inputs (Pieter Wuille)
230294bf5fdeba7213471cd0b795fb7aa36e5717 4-way SSE4.1 implementation for double SHA256 on 64-byte inputs (Pieter Wuille)
1f0e7ca09c9d7c5787c218156fa5096a1bdf2ea8 Use SHA256D64 in Merkle root computation (Pieter Wuille)
d0c96328833127284574bfef26f96aa2e4afc91a Specialized double sha256 for 64 byte inputs (Pieter Wuille)
57f34630fb6c3e218bd19535ac607008cb894173 Refactor SHA256 code (Pieter Wuille)
0df017889b4f61860092e1d54e271092cce55f62 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
|
|
|
|
boost::lexical_cast<double>(...)
f41d339b781f41f05946e965da3e1bf5d0a9e50b 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
|
|
1e4eec47beb5d910b99f4c062fa4388337106d14 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
|
|
boost::lexical_cast<double>(...)
|
|
|
|
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.
|
|
|
|
faac7a2db4f9f511c901cb1b4d4e7c599b92884f 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
|
|
fa26cf015658ac2aa52b5e5656e38af9a12160cc 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
|
|
f7e153e95 [wallets] [docs] Add release notes for createwallet RPC. (John Newbery)
32167e830 [wallet] [tests] Add tests for `createwallet` RPC. (John Newbery)
942131774 [wallet] [rpc] Add `createwallet` RPC (John Newbery)
Pull request description:
Adds a `createwallet` RPC to dynamically create a new wallet at runtime.
Includes tests and release notes.
Tree-SHA512: e0d89e3ae498234e9db5b827c56804cbab64f18a1875e2b5e676172c110278ea1b9e93a8a61b8dd80e2f2a691490bf229e923e4ccb284a1d3e420b8317815866
|
|
using GNU grep specific regexp handling
db56755ca4a0e53785b5bf322d3b65ffe328b60a 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
|
|
|
|
|
|
fa2d83eb44 travis: Skip cache for lint stage (MarcoFalke)
Pull request description:
* Disable cache for lint stage according to https://docs.travis-ci.com/user/caching/#Explicitly-disabling-caching
* Skip fetching of keys for non-cron branch pushes.
Tree-SHA512: 300a0353a5ac0d2431eaff0a98e0e7f52429694737c136d13ff03334ea223a79436473a60db03a0ce4e4009d2a87d11612c7ac8d3a2e38d2bbdd3d800ff10000
|
|
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
|
|
6b8b63af1461dc11ffd813401e2c36fa44656715 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
|
|
specific regexp handling
|
|
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.
|
|
|
|
The node will often disconnect before sending a reject code. A more
robust solution would be to read from the debug log.
|
|
d8c4998f31 Fix typos (practicalswift)
Pull request description:
Fix typos.
Tree-SHA512: 9af52a9799e6892b162e4aa1bcd6585502e10650b8aced59e7346dbb2f08544330081eb79328255fad1d358c095507956e049d354c4383b6965d4d5a7d635425
|
|
|
|
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
|
|
4b62bdf5136c174621509bf7866fbd89b61cc66a 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.
|
|
c814e2e7e81fd01fcb07f4a28435741bdc463801 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
|
|
CMutableTransaction
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
|
|
|
|
83102388c0 doc: update bitcoin-dot-org links in release-process.md (fanquake)
Pull request description:
Tree-SHA512: 664756780843e69a1b88eab573d451dfe4779281ad086406f35d641ca62b8369c7a8ccbd5eec2c81014da67233de5a8d8d77abcb65298d4783915cadbc102572
|
|
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.
|
|
|
|
|