fadf60e381 qa: Note on test order in test_runner (MarcoFalke)
Pull request description:
C.f. #11964
Tree-SHA512: 5f087965093722d9e7a3febddcc187e412bd0636a7ed2da60111668fe3bba6668110e25a38ddcccc0d0aae132611c56fa72f3f0c473fb3fb59e38be445edfcd5
0d663f8 Fixes issue #12067 `sendmany` curl example is wrong. (251)
Pull request description:
The example curl command in the `sendmany` RPC help results in an error:
```
{"result":null,"error":{"code":-1,"message":"JSON value is not an object as expected"},"id":"curltest"}
```
because - as reported in #12067 - the second element in the `params` array should be a JSON object.
This PR removes the escaped backslash and quote characters that serialize the JSON object to a string and make it a plain JSON object:
```
curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendmany", "params": ["", {"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XX":0.01,"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz":0.02}, 6, "testing"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
```
which (when executed with valid addresses) yields the expected result:
```
{"result":"c446213f06ee4489660ed5dc47d65daca27345d0b5fc5bd344ebca78b2d87356","error":null,"id":"curltest"}
```
Tree-SHA512: 9be055515175f633d21cbe2f6735e08709af306639b31e9f2bf83d9eb1cf4dbbf807951728649f3c091fde96dbf4ea732ee903dec9589f90ea1e046b832b90d0
The boolean expression model && model->haveWatchOnly() can be simplified to model->haveWatchOnly(), because if (!model || !model->getOptionsModel()) { return; } guards against a potential dereferenced null pointer.
5ec3eae remove brew c++ flag (Pablo Fernandez)
Pull request description:
the c++ is not needed since the listed brew formulas no longer have this option. It also raises a warning that may generate confusion.
Tree-SHA512: 37c0ebee2901947a21abfcd646ae0c7e73293568f37db9b130d1c521aa4222b0e82e21614e6ac60bb5347c34ef15bbd24eb8066ebf576ea3da9f365be9a4d062
6915f93 doc: Update OpenBSD build instructions for 6.2 (Wladimir J. van der Laan)
Pull request description:
(this continues #11442)
There is no more need to install a new compiler. This simplifies instructions a lot.
From discussion with @fanquake on IRC I first wanted to add a new section for 6.2, but that made the document a complex mess. I think it's good enough (and more maintainable too) to only support the most recent release.
Includes #11976.
I moved the "resource limits" section to the end as I didn't seem to need it with clang, but this may vary based on source changes and the phase of the moon so it's good to keep it as optional extra information.
Tree-SHA512: 15794afec6d682323d0aa13c7616d009acb7fce8b0ef5d2106261f2ebd86b7b2fe66040c04860d9bf2f0c1934fbdc2b594b8c09a98accfaac04f3daf9a6cadf3
Implements a virtual destructor on the BaseRequestHandler class to protect against undefined behavior in
the event that a derived BaseRequestHandler class has a destructor and an object of such derived class
is destroyed through a pointer to its base class.
97d2b09c12 Add helper to wait for validation interface queue to catch up (Matt Corallo)
36137497f1 Block ActivateBestChain to empty validationinterface queue (Matt Corallo)
5a933cefcc Add an interface to get the queue depth out of CValidationInterface (Matt Corallo)
a99b76f269 Require no cs_main lock for ProcessNewBlock/ActivateBestChain (Matt Corallo)
a734896038 Avoid cs_main in net_processing ActivateBestChain calls (Matt Corallo)
66aa1d58a1 Refactor ProcessGetData in anticipation of avoiding cs_main for ABC (Matt Corallo)
818075adac Create new mutex for orphans, no cs_main in PLV::BlockConnected (Matt Corallo)
Pull request description:
This should fix#11822.
It ended up bigger than I hoped for, but its not too gnarly. Note that "
Require no cs_main lock for ProcessNewBlock/ActivateBestChain" is mostly pure code-movement.
Tree-SHA512: 1127688545926f6099449dca6a4e6609eefc3abbd72f1c66e03d32bd8c7b31e82097d8307822cfd1dec0321703579cfdd82069cab6e17b1024e75eac694122cb
* Now that we have bip176, change "µBTC" to the more colloquial "bits"
* We retain the `µBTC (bits)` description in dropdowns and status bars.
The more concise "bits" is used when appended to numbers.
Signed-off-by: William Casarin <jb55@jb55.com>
This requires the removal of some very liberal (incorrect) cs_mains
sprinkled in some tests. It adds some chainActive.Tip() races, but
the tests are all single-threaded anyway.
760af84 Removed CCheckQueueSpeed benchmark (Martin Ankerl)
00721e6 Improved microbenchmarking with multiple features. (Martin Ankerl)
Pull request description:
The benchmark's KeepRunning() used to make a function call for each call, inflating measurement times for short running code. This change inlines the critical code that is executed each run and moves the slow timer updates into a new function.
This change increases the average runtime for Trig from 0.000000082339208 sec to 0.000000080948591.
Tree-SHA512: 36b3bc55fc9b1d4cbf526b7103af6af18e9783e6b8f3ad3adbd09fac0bf9401cfefad58fd1e6fa2615d3c4e677998f912f3323d61d7b00b1c660d581c257d577
3e1ee31 [Tests] Adding unit tests for GetDifficulty in blockchain.cpp. (sean)
Pull request description:
blockchain.cpp has low unit test coverage. This commit is intended
to start improving its code coverage to reasonable levels. One or more
follow up commits will complete the task that this commit is starting
(though the usefulness of this commit is not dependent upon later
commits).
Note that these tests were not written based upon a specification of how
GetDifficulty *should* work, but rather how it actually *does* work. As
a result, if there are any bugs in the current GetDifficulty
implementation, these unit tests serve to lock them in rather than
expose them.
-- Why has blockchain.cpp been modified if this is a unit testing change?
Since the existing GetDifficulty function relies on a global variable,
chainActive, it was not suitable for unit testing purposes. Both the
existing GetDifficulty function and the unit tests now call through to
a new, more modular version of GetDifficulty that can work on any chain,
not just chainActive.
-- Why does blockchain_tests.cpp directly include blockchain.cpp instead
of blockchain.h?
While the new GetDifficulty function's signature is arguably better than
the old one's, it still isn't great, and doesn't seem to warrant inclusion
as part of the blockchain.h API, especially since only test code is
directly using it. If a better way of exposing the new GetDifficulty
function to unit tests exists, please mention it and the commit will be
updated accordingly.
-- Why is the test fixture named blockchain_difficulty_tests rather than
blockchain_tests?
The Bitcoin Core policy for naming unit test files is to match the the
file under test ("blockchain" becomes "blockchain_tests"). While this
commit complies with that, blockchain.cpp is a massive file, such that
having all of the unit tests in one file will tend towards disorder.
Since there will be a lot more tests added to this file, the intention
is to divide up different types of tests into different test fixtures
within the same file.
Tree-SHA512: a7dda9c2a9414d4819b4d2911f5637891dc19cecbecfc1463846161d2a78793151927a5ab911c69a5d3013f7668e75a1d78a65667cb9d83910cda439cbe84d62
* inline performance critical code
* Average runtime is specified and used to calculate iterations.
* Console: show median of multiple runs
* plot: show box plot
* filter benchmarks
* specify scaling factor
* ignore src/test and src/bench in command line check script
* number of iterations instead of time
* Replaced runtime in BENCHMARK makro number of iterations.
* Added -? to bench_bitcoin
* Benchmark plotly.js URL, width, height can be customized
* Fixed incorrect precision warning
31a013563 Add required package dependencies for depends cross compilation [skip-ci] (Jonas Schnelli)
Pull request description:
Stumbled over this during a setup of a new depends compile system.
Related to #8913.
Tree-SHA512: 67e2fdf9ca3cbedeb02982fa73771dd36978b319e9291ea5a41ede7fdf772c4505ccc9523b48fe66ead927f141efefbdf1e3eaa19a9d8a1304861a8ede040056
a6365c5 depends: fix libzmq's needless linking against libstdc++ (Cory Fields)
Pull request description:
Broken gitian builds were introduced with #9254. Big thanks to @jonasschnelli for narrowing down the bisection.
This is broken for a number of reasons, including:
- g++ understands "-static-libstdc++ -lstdc++" to mean "link against whatever libstdc++ exists, probably shared", which in itself is buggy.
- another stdlib (libc++ for example) may be in use
Tree-SHA512: d84968ee680f32ea799034ee516e9477fff2b1ef1b7c9a8ef1941631520ab196ecd50f5d64f3ed1c84113ead44be5e3ddf6ff2ae0277625bdeed05f1da89e017
GUI wallet uses RBF by default, regardless of -walletrbf.
RPC and debug console in the GUI remain unchanged; they don't
use RBF by default, unless launched with -walletrbf=1.
This is broken for a number of reasons, including:
- g++ understands "-static-libstdc++ -lstdc++" to mean "link against whatever
libstdc++ exists, probably shared", which in itself is buggy.
- another stdlib (libc++ for example) may be in use
656fde5 Add script birthtime metadata to dump and import wallet (MeshCollider)
1bab9b2 Add script dump note to RPC help text and release notes (MeshCollider)
68c1e00 Add test for importwallet (MeshCollider)
9e1184d Add dumpwallet scripts test (MeshCollider)
ef0c730 Add scripts to importwallet RPC (MeshCollider)
b702ae8 Add CScripts to dumpwallet RPC (MeshCollider)
cdc260a Add GetCScripts to CBasicKeyStore (MeshCollider)
Pull request description:
As discussed in https://github.com/bitcoin/bitcoin/pull/11289#issuecomment-334600457, adds the CScripts from the wallet to the `dumpwallet` RPC and then allows them to be imported with the `importwallet` RPC. Includes a basic test, and modifies the helptext of the dumpwallet RPC.
Notes:
- Reviewers: use `?w=1` to avoid the indentation-only change in commit `Add scripts to importwallet RPC `
- currently the scripts are followed with `# addr=` comments just as the other keys are, unsure if this might confuse users into thinking all the scripts are for valid P2SH addresses though, but I don't think that should be an issue.
- there are no birthtimes for scripts, so script imports don't affect rescans
- `importwallet` imports the CScripts but I'm not sure how to approach specifying whether scripts are for P2SH addresses, BIP173 addresses, etc. whether that matters or not. Otherwise the RPC helptext might just need modification.
Fixes#11715
Tree-SHA512: 36c55837b3a58b9d3499d4c0c2ae82153d62aa71919e751574651b63a1d2b8ecc83796db4553cc65dad9b5341c3a42ae2fcf4d62598c30af267f8e1461ba8272
2712742 doc: Update FreeBSD build instructions to use bdb4 (Wladimir J. van der Laan)
d95c83d contrib: FreeBSD compatibility in install_db4.sh (Wladimir J. van der Laan)
c0298b0 contrib: Make X=Y arguments work in install_db4 (Wladimir J. van der Laan)
b798f9b contrib: New clang patch for install_db4 (Wladimir J. van der Laan)
Pull request description:
This PR improves the BSD compatibility of the bdb4 installer script.
See #11921, #11868.
I've tested this on OpenBSD 6.2 (clang) and Ubuntu 16.04 (gcc).
This needs testing on OSX at least, ~~and on gcc/Linux to make sure that applying the patch unconditionally doesn't negatively affect gcc~~.
~~NB: this is not yet sufficient to make `install_db4.sh` work on FreeBSD, as we need to use yet another `sha256` tool there. But it's a step in the right direction.~~
### contrib: New clang patch for install_db4
Replace the clang patch with a new and improved version that also fixes the build issues with OpenBSD and FreeBSD's clang, and apply it unconditionally.
Thanks to @fanquake for finding the patch.
### contrib: Make X=Y arguments work in install_db4
Trailing X=Y arguments are supposed to be passed through unchanged to bdb's configure. This was not the case, at least with OpenBSD 6.2's shell.
Fix this by not storing the arguments in a temporary variable but passing "$@" through directly.
### contrib: FreeBSD compatibility in install_db4.sh
Unfortunately, FreeBSD uses yet another syntax for `sha256`.
Support FreeBSD's syntax too. Using `uname` is a bit of a hack but it works and I found no way to distinguish the two.
Tree-SHA512: 12461a58dfeb4834701891762efc747c8187d834f41d98c8451edee1402a3958c4842bbc02c61bacbc7b0d90cc6b020a2ca158b65304d9760c9f0d2052ff36d4
aac6b3f067 Update files.md for new wallets/ subdirectory (MeshCollider)
b67342906c Cleanups for walletdir PR (MeshCollider)
Pull request description:
This addresses the remaining nits from https://github.com/bitcoin/bitcoin/pull/11466
- Updates `doc/files.md` with respect to the new default wallet directory
- Fixes @promag and @laanwj's error message nit, and Jonas' release notes nit
- ~Addresses @laanwj's net-specific wallet subdirectory concern in the case that a walletdir is specified~
- Changes the #includes from "" to <> style after #11651
Tree-SHA512: b86bf5fdc4de54c1b0f65b60a83af3cf82b35d216ce9c0de724803bfba6934796238b6c412659dcc29ae2e3e856d4eb97ae777c80f36f4089d8acecfddefe9aa
git keeps changing the number of digits in abbreviated hashes, resulting in the GitHub archive hash changing because we include it here.
To workaround this and avoid hashes that become increasingly ambiguous later on, just include the full commit hash when building from git.
This has no effect on tagged releases.
f455a24 [net] add seed.testnet.bitcoin.sprovoost.nl to testnet DNS seeds (Sjors Provoost)
Pull request description:
I tested it myself by:
* `dig seed.testnet.bitcoin.sprovoost.nl` (should have propagated by now, but if you only see two records with `A 66.111... ` try again later)
* deleting the other seeds and all data in `.../testnet3`, recompiling and then starting the node. Log shows `21 addresses found from DNS seeds`.
ACK https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md
I'm willing to keep it up and running at least throughout 2018, unless something bad happens.
About my setup:
* Amazon EC2 instance in Europe, running Ubuntu 16.04; I use this instance for some other chores, but only port 53 is world reachable (for mainnet I'd probably run a dedicated instance, and perhaps a location I have physical control over)
* running [sipa/bitcoin-seeder](https://github.com/sipa/bitcoin-seeder) with default settings (and the non-root port redirect)
* feedback about my domain / DNS setup is welcome, I can provide more details via private email
I can use guidance on _Any hosting services contracted by the operator are equally expected to uphold these expectations_. Although I assume the requirements for testnet are less strict than for mainnet, in case I want to pursue the latter in the future: what unpleasant things can Amazon, my domain registrar and other intermediaries do? How would I mitigate that?
Also note that The Netherlands passed some pretty onerous legislation creating uncertainty over what the secret service can compel people like myself to do. However these laws won't take effect before mid 2018, there's probably more interesting targets than myself to go after, and it's easier for them to just monitor all unencrypted P2P traffic everywhere, or monitor some intermediary I depend on.
Any good tools for monitoring uptime?
Tree-SHA512: 386fe688e5006ab8352d93ab3954fc07dc566876ae002891baa51acfaa5bb113f51b1f5ca08c7394a530b10a2f5008c56d57153af3ed07544a305586dda06b97
2862b56 [tests] remove redundant univalue_tests.cpp (John Newbery)
Pull request description:
univalue unit tests were added in #4730 , and exist at `/src/test/univalue_tests.cpp` (outside the univalue tree). That test was brought into the univalue repository in https://github.com/bitcoin-core/univalue/pull/4 , which was pulled into the github repository in https://github.com/bitcoin/bitcoin/pull/11420.
That means that the univalue test exists in two places:
1. `/src/test/univalue_tests.cpp`
2. `/src/univalue/test/object.cpp`
(2) is a strict superset of (1). It adds some macros to work around boost not being a univalue dependency, and adds a few extra lines of test.
Therefore remove `/src/test/univalue_tests.cpp`
Tree-SHA512: 3747b10bbf62e9f12363905488b29945ad559ddca68c5c03d8a362de612a51f408f41a04d3712c6889bfc1632fb1a5fa0d7df0fbf02c322b3981a6d698f501b0
88411e9 Squashed 'src/univalue/' changes from fe805ea74f..07947ff2da (MarcoFalke)
Pull request description:
Pulls in the test changes to the univalue subtree.
Beside looking at the code, reviewers should refer to https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#git-subtree-checksh on how to verify the subtree pull.
Tree-SHA512: 09493625a573dca1140570326ee90c1bb84e4893e1dab2cdd51bc23ae1fba1e33c43ed771ca9e112ac71b0242e8a8d058071334562c738d502587eadd5a0f114
Unfortunately, FreeBSD uses yet another syntax for `sha256`.
Support FreeBSD's syntax too. Using `uname` is a bit of a hack but it
works and I found no way to distinguish the two.
