aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
2020-08-10Merge #19605: doc: set CC_FOR_BUILD when building on OpenBSDfanquake
01cd24c22606408d5c0ac74c9a2c5d85eff77846 doc: set CC_FOR_BUILD when building on OpenBSD (fanquake) Pull request description: Closes: #19559 While #19559 has been fixed upstream, it makes sense to not only recommend using `CC_FOR_BUILD`here until the fix is pulled in as part of our next libsecp update, but after discussing with Cory, he suggested we should be setting this on OpenBSD (which still has the an ancient GCC) regardless. ACKs for top commit: real-or-random: ACK 01cd24c22606408d5c0ac74c9a2c5d85eff77846 I looked at the diff (but can't test the instructions on OpenBSD) laanwj: Code review ACK 01cd24c22606408d5c0ac74c9a2c5d85eff77846 Tree-SHA512: 322802b9303771f1be2ad9628f268dfa71dc7ee77948fa2a34f21eceb19b2d8efdd8876c8f0778adbfcde48fa0f88cd4e698ae425428159abca38e8c7980da1d
2020-08-09Merge #19638: Replace `hidden service` with `onion service`Wladimir J. van der Laan
1e72b68ab330c72644981508c8a1b3fa670d086f Replace `hidden service` with `onion service` (Riccardo Masutti) Pull request description: For a couple of years, Tor has made the term `hidden service` obsolete, in favor of `onion service`: [Tor Project | Onion Services](https://community.torproject.org/onion-services/) This PR updates all the references. ACKs for top commit: laanwj: Code review ACK 1e72b68ab330c72644981508c8a1b3fa670d086f hebasto: ACK 1e72b68ab330c72644981508c8a1b3fa670d086f, tested on Linux Mint 20 (x86_64). Tree-SHA512: 6a29e828e1c5e1ec934b5666f67326dbd84d77c8b2641f6740abac6d3d5923b7729763b9ff2230390b0bb23359a5f3731ccd9a30011ca69004f7c820aed17262
2020-08-07Replace `hidden service` with `onion service`Riccardo Masutti
For a couple of years, Tor documentation has made the term hidden service obsolete, in favor of onion service. This PR updates all the references in the code base.
2020-08-06Merge #19667: build: set minimum required Boost to 1.58.0fanquake
70452a070b3b6d4d650a948b3337bc7b8bb2c3c3 build: set minimum required Boost to 1.58 (fanquake) Pull request description: Any systems which only have an older installable Boost can use depends. 1.58.0 retains compatibility with the packages [installable on Ubuntu 16.04](https://packages.ubuntu.com/xenial/libboost-dev). The projects usage of Boost wont be going away any time soon, if ever (i.e #15382), and our usage of the test framework. Fixes: #19506 ACKs for top commit: practicalswift: ACK 70452a070b3b6d4d650a948b3337bc7b8bb2c3c3 -- patch looks correct laanwj: ACK 70452a070b3b6d4d650a948b3337bc7b8bb2c3c3 hebasto: ACK 70452a070b3b6d4d650a948b3337bc7b8bb2c3c3, tested on Linux Mint 20 (x86_64). Tree-SHA512: d290415e3c70a394b3d7659c0480a35b4082bdce8d48b1c64a0025f7ad6e21567b4dc85813869513ad246d27f950706930410587c11c1aa3693ae6245084765c
2020-08-05Merge #15382: util: add RunCommandParseJSONSamuel Dobson
31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0 [util] add RunCommandParseJSON (Sjors Provoost) c17f54ee535faaedf9033717403e1f775b5f1530 [ci] use boost::process (Sjors Provoost) 32128ba682033560d6eb2e4848a9f77a842016d2 [doc] include Doxygen comments for HAVE_BOOST_PROCESS (Sjors Provoost) 3c84d85f7d218fa27e9343c5cd1a55e519218980 [build] msvc: add boost::process (Sjors Provoost) c47e4bbf0b44f2de1278f9538124ec98ee0815bb [build] make boost-process opt-in (Sjors Provoost) 929cda5470f98d1ef85c05b1cad4e2fb9227e3b0 configure: add ax_boost_process (Sjors Provoost) 8314c23d7b39fc36dde8b40b03b6efbe96f85698 [depends] boost: patch unused variable in boost_process (Sjors Provoost) Pull request description: Prerequisite for external signer support in #16546. Big picture overview in [this gist](https://gist.github.com/Sjors/29d06728c685e6182828c1ce9b74483d). This adds a new dependency [boost process](https://github.com/boostorg/process/tree/boost-1.64.0). This is part of Boost since 1.64 which is part of `depends`. Because the minimum Boost version is 1.47, this functionality is skipped for older versions of Boost. Use `./configure --with-boost-process` to opt in, which checks for the presence of Boost::Process. We add `UniValue runCommandParseJSON(const std::string& strCommand)` to `system.{h,cpp}` which calls an arbitrary command and processes the JSON returned by it. This is currently only called by the test suite. ~For testing purposes this adds a new regtest-only RPC method `runcommand`, as well as `test/mocks/command.py` used by functional tests.~ (this is no longer the case) TODO: - [ ] review boost process in #15440 ACKs for top commit: achow101: ACK 31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0 hebasto: re-ACK 31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0, only rebased (verified with `git range-diff`) and removed an unintentional tab character since the [previous](https://github.com/bitcoin/bitcoin/pull/15382#pullrequestreview-458371035) review. meshcollider: Very light utACK 31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0, although I am not very confident with build stuff. promag: Code review ACK 31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0, don't mind the nit. ryanofsky: Code review ACK 31cf68a3ad1f0a5537c8419e2912b55fbfb88fa0. I left some comments below that could be ignored or followed up later. The current change is clean and comprehensive. Tree-SHA512: c506e747014b263606e1f538ed4624a8ad7bcf4e025cb700c12cc5739964e254dc04a2bbb848996b170e2ccec3fbfa4fe9e2b3976b191222cfb82fc3e6ab182d
2020-08-05build: set minimum required Boost to 1.58fanquake
Any systems which only have an older install-able Boost can use depends. Fixes: #19506
2020-08-01doc: Add historical release notes for 0.20.1Wladimir J. van der Laan
2020-07-31[doc] include Doxygen comments for HAVE_BOOST_PROCESSSjors Provoost
2020-07-30doc: list support for BIP 339 in doc/bips.mdPieter Wuille
2020-07-30Merge #18011: Replace current benchmarking framework with nanobenchWladimir J. van der Laan
78c312c983255e15fc274de2368a2ec13ce81cbf Replace current benchmarking framework with nanobench (Martin Ankerl) Pull request description: Replace current benchmarking framework with nanobench This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench ACKs for top commit: laanwj: ACK 78c312c983255e15fc274de2368a2ec13ce81cbf Tree-SHA512: 9e18770b18b6f95a7d0105a4a5497d31cf4eb5efe6574f4482f6f1b4c88d7e0946b9a4a1e9e8e6ecbf41a3f2d7571240677dcb45af29a6f0584e89b25f32e49e
2020-07-28doc: set CC_FOR_BUILD when building on OpenBSDfanquake
Closes: #19559 While #19559 has been fixed upstream, it makes sense to not only recommend using `CC_FOR_BUILD`here until the fix is pulled in as part of our next libsecp update, but after discussing with Cory, he suggested we should be setting this on OpenBSD (which still has the an ancient GCC) regardless.
2020-07-23Merge #15935: Add <datadir>/settings.json persistent settings storageMarcoFalke
9c69cfe4c54e38edd2f54303be2f8a53dcf5bad8 Add <datadir>/settings.json persistent settings storage. (Russell Yanofsky) eb682c5700e7a9176d0104d470b83ff9aa3589e8 util: Add ReadSettings and WriteSettings functions (Russell Yanofsky) Pull request description: Persistent settings are used in followup PRs #15936 to unify gui settings between bitcoin-qt and bitcoind, and #15937 to add a load_on_startup flag to the loadwallet RPC and maintain a dynamic list of wallets that should be loaded on startup that also can be shared between bitcoind and bitcoin-qt. ACKs for top commit: MarcoFalke: Approach re-ACK 9c69cfe4c54e38edd2f54303be2f8a53dcf5bad8 🌾 jnewbery: utACK 9c69cfe4c54e38edd2f54303be2f8a53dcf5bad8 Tree-SHA512: 39fcc6051717117c9141e934de1d0d3f739484be4685cdf97d54de967c8c816502b4fd0de12114433beaa5c5b7060c810fd8ae4e2b3ce7c371eb729ac01ba2e1
2020-07-16Merge #16525: Dump transaction version as an unsigned integer in RPC/TxToUnivWladimir J. van der Laan
e80259f1976545e4f1ab6a420644be0c32261773 Additionally treat Tx.nVersion as unsigned in joinpsbts (Matt Corallo) 970de70bdd3542e75b73c79b06f143168c361494 Dump transaction version as an unsigned integer in RPC/TxToUniv (Matt Corallo) Pull request description: Consensus-wise we already treat it as an unsigned integer (the only rules around it are in CSV/locktime handling), but changing the underlying data type means touching consensus code for a simple cleanup change, which isn't really worth it. See-also, https://github.com/rust-bitcoin/rust-bitcoin/pull/299 ACKs for top commit: sipa: ACK e80259f1976545e4f1ab6a420644be0c32261773 practicalswift: ACK e80259f1976545e4f1ab6a420644be0c32261773 ajtowns: ACK e80259f1976545e4f1ab6a420644be0c32261773 code review -- checked all other uses of tx.nVersion treat it as unsigned (except for policy.cpp:IsStandard anyway), so looks good. naumenkogs: ACK e80259f Tree-SHA512: 6760a2c77e24e9e1f79a336ca925f9bbca3a827ce02003c71d7f214b82ed3dea13fa7d9f87df9b9445cd58dff8b44a15571d821c876f22f8e5a372a014c9976b
2020-07-14gui, doc: rm Ban Score in GUI Peers window/release notes updatesJon Atack
2020-07-14Merge #19464: net: remove -banscore configuration optionMarcoFalke
06059b0c2a6c2db70c87a7715f8a344a13400fa1 net: rename DEFAULT_BANSCORE_THRESHOLD to DISCOURAGEMENT_THRESHOLD (Jon Atack) 1d4024bca8086cceff7539dd8c15e0b7fe1cc5ea net: remove -banscore configuration option (Jon Atack) Pull request description: per https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652684340, https://github.com/bitcoin/bitcoin/pull/19219#discussion_r443074487 and https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652699592. Edit: now split into 3 straightforward PRs: - net: remove -banscore configuration option (this PR) - rpc: deprecate banscore field in getpeerinfo (#19469, *merged*) - gui: no longer display banscores (TBA in the gui repo) ACKs for top commit: MarcoFalke: review ACK 06059b0c2a6c2db70c87a7715f8a344a13400fa1 📙 vasild: ACK 06059b0c Tree-SHA512: 03fad249986e0896697033fbb8ba2cbfaae7d7603b1fb2a38b3d41db697630d238623f4d732b9098c82af249ce5a1767dd432b7ca0fec10544e23d24fbd57c50
2020-07-12doc: move-only release notesMarcoFalke
Review suggestion: --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space
2020-07-12doc: Remove release notes of backportsMarcoFalke
2020-07-12Merge #18202: refactor: consolidate sendmany and sendtoaddress codeSamuel Dobson
08fc6f6cfc3b06fd170452a766696d7b833113fa [rpc] refactor: consolidate sendmany and sendtoaddress code (Sjors Provoost) Pull request description: I consolidated code between these two RPC calls, since `sendtoaddress` is essentially `sendmany` with 1 destination. Unless I overlooked something, the only behaviour change is that some `sendtoaddress` error codes changed from `-4` to `-6`. The release note mentions this. Salvaged from #18201. ACKs for top commit: fjahr: Code review ACK 08fc6f6cfc3b06fd170452a766696d7b833113fa jonatack: ACK 08fc6f6cfc3b06fd170452a766696d7b833113fa meshcollider: Code review & functional test run ACK 08fc6f6cfc3b06fd170452a766696d7b833113fa Tree-SHA512: 7b66c52fa0444a4d02fc3f81d9c2a386794d447616026a30111eda35fb46510475eea6506a9ceda00bb4e0230ebb758da5d236b3ac05c954c044fa68a1e3e909
2020-07-11net: remove -banscore configuration optionJon Atack
2020-07-11Add <datadir>/settings.json persistent settings storage.Russell Yanofsky
Persistent settings are used in followup PRs #15936 to unify gui settings between bitcoin-qt and bitcoind, and #15937 to add a load_on_startup flag to the loadwallet RPC and maintain a dynamic list of wallets that should be loaded on startup that also can be shared between bitcoind and bitcoin-qt.
2020-07-11Merge #19474: doc: Use precise permission flags where possibleMarcoFalke
fab558612278909df93bdf88f5727b04f13aef0f doc: Use precise permission flags where possible (MarcoFalke) Pull request description: Instead of mentioning the all-encompassing `-whitelist*` settings, change the docs to mention the exact permission flag that will influence the behaviour. This is needed because in the future, the too-broad `-whitelist*` settings (they either include *all* permission flags or apply to *all* peers) might be deprecated to require the permission flags to be enumerated. Alternatively, in the future there could be an RPC to set the net permission flags on an existing connection, in which case the `-whitelist*` terminology is of no help. ACKs for top commit: jnewbery: reACK fab558612278909df93bdf88f5727b04f13aef0f fjahr: Code review ACK fab558612278909df93bdf88f5727b04f13aef0f jonatack: ACK fab558612278909df93bdf88f5727b04f13aef0f Tree-SHA512: c7dea3e577d90103bb2b0ffab7b7c8640b388932a3a880f69e2b70747fc9213dc1f437085671fd54c902ec2a578458b8a2fae6dbe076642fb88efbf9fa9e679c
2020-07-10doc: Use precise permission flags where possibleMarcoFalke
2020-07-10Merge #19469: rpc: deprecate banscore field in getpeerinfofanquake
41d55d30579358c805036201664ad6a1c1d48681 doc: getpeerinfo banscore deprecation release note (Jon Atack) dd54e3796e633cfdf6954af306afd26eadc25116 test: getpeerinfo banscore deprecation test (Jon Atack) 8c7647b3fbbab03ea84071cf3cd2d0d2bf8be255 rpc: deprecate banscore field in rpc getpeerinfo (Jon Atack) Pull request description: Per https://github.com/bitcoin/bitcoin/pull/19219#discussion_r443074487 and https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652699592, this PR deprecates returning the `banscore` field in the `getpeerinfo` RPC, updates the help, adds a test, and updates the release notes. Related to #19464. ACKs for top commit: fanquake: ACK 41d55d30579358c805036201664ad6a1c1d48681 Tree-SHA512: 8eca08332581e2fe191a2aafff6ba89ce39413f0491ed0de8b86577739f0ec430b1a8fbff2914b0f3138a229563dfcc1981c0cf5b7dd6061b5c48680a28423bc
2020-07-09Merge #19258: doc: improve subtree check instructionsWladimir J. van der Laan
a4a3fc4cd2e6f53cdffcc2962fd152a4e40c7413 doc: improve subtree check instructions (Sjors Provoost) Pull request description: Running `git-subtree-check.sh` requires adding the subtree repository as a remote. I learned that several years ago and then forgot again. This PR also improves the error message if the subtree commit can't be found. ACKs for top commit: laanwj: ACK a4a3fc4cd2e6f53cdffcc2962fd152a4e40c7413 fanquake: ACK a4a3fc4cd2e6f53cdffcc2962fd152a4e40c7413 - this looks ok. Tree-SHA512: 959bd923726c172d17f9f97f8a56988bf2df5a94d3131e5152a66150b941394cee9e82fdc6b86e09c0ba91d123a496599f07ca454212168d8d301738394c12c8
2020-07-09Merge #19191: net: Extract download permission from nobanMarcoFalke
fa0540cd46eaf44d9e1a9f91c3a937986826c4fa net: Extract download permission from noban (MarcoFalke) Pull request description: It should be possible to grant nodes in a local network (e.g. home, university, enterprise, ...) permission to download blocks even after the maxuploadtarget is hit. Currently this is only possible by setting the `noban` permission, which has some adverse effects, especially if the peers can't be fully trusted. Fix this by extracting a `download` permission from `noban`. ACKs for top commit: jonatack: ACK fa0540c Sjors: re-utACK fa0540cd46eaf44d9e1a9f91c3a937986826c4fa Tree-SHA512: 255566baa43ae925d93f5d0a3aa66b475a556d1590f662a88278a4872f16a1a05739a6119ae48a293011868042e05cb264cffe5822a50fb80db7333bf44376d9
2020-07-09Merge #19452: doc: afl fuzzing comment about afl-gcc and afl-g++fanquake
2b78a11b48bad1fa30120ce851269ca9ce8833a5 doc: afl fuzzing comment about afl-gcc and afl-g++ (nsa) Pull request description: When trying to build the fuzz tests with `--enable-lcov` on a Ubuntu machine, noticed that the documentation was lacking with regards to the afl-gcc and afl-g++ options. `afl-clang-fast` and `afl-clang-fast++` in the examples just need to be replaced with `afl-gcc` and `afl-g++`. I also had to set the `-m` flag as well to get the fuzzers to run. ACKs for top commit: practicalswift: ACK 2b78a11b48bad1fa30120ce851269ca9ce8833a5 MarcoFalke: Concept ACK 2b78a11b48bad1fa30120ce851269ca9ce8833a5, haven't tested Tree-SHA512: d8151afd79de949e8c6da49b69bbbf1470eb478c8ddcbc69b30e86bf9396c0f13835a655d4ae658f7dc4f36c35b02cd23b08358fb73a71e15bf14e76c1f365a4
2020-07-09net: Extract download permission from nobanMarcoFalke
2020-07-08doc: getpeerinfo banscore deprecation release noteJon Atack
2020-07-05doc: afl fuzzing comment about afl-gcc and afl-g++nsa
This commit includes a short comment in doc/fuzzing.md that gives guidance on compiling Bitcoin Core with AFL instrumentation using afl-gcc and afl-g++.
2020-07-03Replace automatic bans with discouragement filterPieter Wuille
This patch improves performance and resource usage around IP addresses that are banned for misbehavior. They're already not actually banned, as connections from them are still allowed, but they are preferred for eviction if the inbound connection slots are full. Stop treating these like manually banned IP ranges, and instead just keep them in a rolling Bloom filter of misbehaving nodes, which isn't persisted to disk or exposed through the ban framework. The effect remains the same: preferred for eviction, avoided for outgoing connections, and not relayed to other peers. Also change the name of this mechanism to better reflect reality; they're not banned, just discouraged. Contains release notes and several interface improvements by John Newbery.
2020-07-01Merge #19408: doc: Windows WSL build recommendation to temporarily disable ↵Wladimir J. van der Laan
Win32 PE support 21a65756f558a2bd50e71c6dfb04143533e59f76 Add Windows WSL build recommendation to temporarily disable Win32 PE support. (Aaron Clauson) Pull request description: This is a solution for the issues described in #17277 and #18348 When cross compiling Bitcoin Code for Windows the `Autoconf` configure scripts attempt to execute Win32 PE files. The configure scripts expect the attempt to fail, however, WSL supports forking the execution of Win32 PE files out to the underlying Windows OS. This can result in the executions failing for unanticipated reasons, which is the case in the two referenced issues. This PR adds an explanatory note and additional instructions to temporarily disable WLS's Win32 support. ACKs for top commit: laanwj: ACK 21a65756f558a2bd50e71c6dfb04143533e59f76 Tree-SHA512: afb014be5a63fa9a827aed30acb2faab15feed34ed89c788a7f6ae6ab1b2238f99e075e6e281d0cc581914db3a4ecc3d5a3d26442f11a520e4e457a40e75e533
2020-06-29Merge #19367: doc: Span pitfallsWladimir J. van der Laan
fab57e2b9bc4577fcfcd9fbddbc35d96046c5d88 doc: Mention Span in developer-notes.md (Pieter Wuille) 3502a60418858a8281ddf2f9cd59daa8f01d2fa8 doc: Document Span pitfalls (Pieter Wuille) Pull request description: This is an attempt to document pitfalls with the use of `Span`, following up on comments like https://github.com/bitcoin/bitcoin/pull/18468#issuecomment-622846597 and https://github.com/bitcoin/bitcoin/pull/18468#discussion_r442998211 ACKs for top commit: laanwj: ACK fab57e2b9bc4577fcfcd9fbddbc35d96046c5d88 Tree-SHA512: 8f6f277d6d88921852334853c2b7ced97e83d3222ce40c9fe12dfef508945f26269b90ae091439ebffddf03f939797cb28126b2387f77959069ef8909c25ab53
2020-06-29Add Windows WSL build recommendation to temporarily disable Win32 PE support.Aaron Clauson
2020-06-29Merge #19390: doc/REST-interface: Remove stale infofanquake
fd9c213c6e42cedd8a03c2f721ff46790cded76b doc/REST-interface: Remove stale info (Luke Dashjr) Pull request description: Clean merge to 0.19+ ACKs for top commit: fanquake: ACK fd9c213c6e42cedd8a03c2f721ff46790cded76b MarcoFalke: ACK fd9c213c6e42cedd8a03c2f721ff46790cded76b Tree-SHA512: ac3ffaa72226380ed8b8ab505518d0dc4350bfcc4625dfd27a2350fbb972a8d2bb4255307926eb331c49232023bcb283a659f0d87e4ecbf654982341242f7d36
2020-06-27Merge #19354: doc: add release note for -getinfo displaying multiwallet balancesMarcoFalke
6d35d0d18f8d534879e982707d01ea5c1bd13b33 doc: add release note for -getinfo displaying multiwallet balances (Jon Atack) Pull request description: Release note for #18594. This is one of the commits from #19089, which had one concept ACK and approach ACK since late May. It seems better to submit the changes atomically. Top commit has no ACKs. Tree-SHA512: 38616d14b02c39f4ee4b93bf14f72043423cef177b595e85181bc9dc610fbe19d8271f2d2c9e5e17bb46423ffe27746e8e510b13a23ae6fd0e5bc4418a00dafa
2020-06-26doc/REST-interface: Remove stale infoLuke Dashjr
2020-06-26doc: Mention Span in developer-notes.mdPieter Wuille
2020-06-25Merge #11413: [wallet] [rpc] sendtoaddress/sendmany: Add explicit feerate optionWladimir J. van der Laan
25dac9fa65243ca8db02df22f484039c08114401 doc: add release notes for explicit fee estimators and bumpfee change (Karl-Johan Alm) 05227a35545d7656450874b3668bf418c73813fb tests for bumpfee / estimate_modes (Karl-Johan Alm) 3404c1b753432c4859a4ca245f01c240610a00cb policy: optional FeeEstimateMode param to CFeeRate::ToString (Karl-Johan Alm) 6fcf4484302d13bd7739b617470d8c8e31974908 rpc/wallet: add two explicit modes to estimate_mode (Karl-Johan Alm) b188d80c2de9ebb114da5ceea78baa46bde7dff6 MOVEONLY: Make FeeEstimateMode available to CFeeRate (Karl-Johan Alm) 5d1a411eb12fc700804ffe5d6e205234d30edd5f fees: add FeeModes doc helper function (Karl-Johan Alm) 91f6d2bc8ff4d4cd1b86daa370ec9d2d9662394d rpc/wallet: add conf_target as alias to confTarget in bumpfee (Karl-Johan Alm) 69158b41fc488e4f220559da17a475eff5923a95 added CURRENCY_ATOM to express minimum indivisible unit (Karl-Johan Alm) Pull request description: This lets users pick their own fees when using `sendtoaddress`/`sendmany` if they prefer this over the estimators. ACKs for top commit: Sjors: re-utACK 25dac9fa65: rebased, more fancy C++, jonatack: ACK 25dac9fa65243ca8db02df2 I think this should be merged after all this time, even though it looks to me like there are needed follow-ups, fixes and test coverage to be added (see further down), which I don't mind helping out with, if wanted. fjahr: Code review ACK 25dac9fa65243ca8db02df22f484039c08114401 Tree-SHA512: f31177e6cabf3187a43cdfe93477144f8e8385c7344613743cbbd16e8490d53ff5144aec7b9de6c9a65eb855b55e0f99d7f164dee4b6bf3cfea4dce51cf11d33
2020-06-24doc: add release notes for explicit fee estimators and bumpfee changeKarl-Johan Alm
2020-06-23doc: add release note for bitcoin-cli -generateJon Atack
2020-06-22doc: add release note for -getinfo displaying multiwallet balancesJon Atack
2020-06-22Merge #19305: doc: add C++17 release note for 0.21.0Wladimir J. van der Laan
f1d21ef1c370898ae10569f2a8569bd98d71a981 doc: add C++17 release note for 0.21.0 (fanquake) Pull request description: TLDR: Mention that the codebase is now compatible with C++17, and that the intention is to require C++17 starting with 0.22.0. Following some discussion with Cory/Carl, and in #16684, I think this is the next step in the C++17 migration. While #16684 mentions a gitian/Guix release with C++17, it's not yet clear how that would be done. Are we just going to pass `--enable-c++17` in gitian/Guix?. Are we changing our default in configure.ac? According to the [last comment](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-643778757) in #16684, we wouldn't be changing anything in depends: > No, everything (including depends) will stay at C++11. However I don't think we want to be mixing C++11 built dependencies, with a C++17 built bitcoind, if there is any potential for compatibility issues. Instead, I'd suggest we build the 0.21.0 release as C++11, and do a complete switch to C++17 for 0.22.0. Also, if we actually wanted to use C++17 in depends for 0.21.0, we couldn't without breaking C++11 compat (Qt). See below. Here is a potential timeline/TODOs for the migration: Potential Timeline * 17 / 6 / 2020 - Today * Some time prior to split-off: * Confirm that compiling with C++17 works. * Confirm that C++11 compatibility has not been broken. * 1 / 11 / 2020 * [0.21.0 split off happens](https://github.com/bitcoin/bitcoin/issues/18947). * 2 / 11 / 2020 * Merge an "incompatible with C++11" change into master. * Switch configure to use C++17 mode by default. * Update minimum compiler requirements. At least: * Clang 5: https://clang.llvm.org/cxx_status.html#cxx17 * GCC 7: https://gcc.gnu.org/projects/cxx-status.html#cxx17 * While GCC has some support from 5, it seems a more complete support landed in GCC 7. * https://gcc.gnu.org/gcc-7/changes.html#cxx * Switch depends packages to use C++17 where applicable. * Bump Qt from 5.9.x (no c++17 mode) to, likely, 5.15.x (LTS). * Drop support for macOS < 10.14.x * The c++ dylib shipped with macOS [doesn't support c++17, prior to macOS 10.14](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-643722538). * Building Qt 5.12 or 5.15 in C++17 mode will also require a minimum macOS deployment target of 10.14. https://codereview.qt-project.org/c/qt/qtbase/+/283832. * Begin merging PRs like #19183 and #19245. * I've left some comments in #19183 if the macOS runtime issue interests anyone. * 3 / 12 / 2020 * 0.21.0 released. * Built as C++11. * Contains warning in release notes that compiling 0.22.0 will require C++17. * 3 / 6 / 2021 * 0.22.0 released. * Full of C++17 code. One thing worth noting, is that we cannot bump our Qt to a newer LTS for 0.21.0, without breaking C++11 compatibility. Qt 5.12 is not compilable in C++11 mode, as the project has started using C++14 features throughout at least the macOS portions of it's codebase, and seemingly "forgotten" that the release is meant to be C++11 compatible. Upstream bug here: https://bugreports.qt.io/browse/QTBUG-77310. > Building Qt requires C+11, at a minimum, but in practice we use later features, usually under a feature define, or with a fallback of some kind. On platforms that support > C11, we've (apparently) not considered the fallback necessary, under the assumption C+14 is always available. ACKs for top commit: MarcoFalke: ACK f1d21ef1c370898ae10569f2a8569bd98d71a981 can't hurt to give an advance warning Sjors: ACK f1d21ef1c370898ae10569f2a8569bd98d71a981 laanwj: ACK f1d21ef1c370898ae10569f2a8569bd98d71a981 theStack: ACK f1d21ef1c370898ae10569f2a8569bd98d71a981 Tree-SHA512: 706baceb07d9584783ba6e437cdf447531c20f586285b9797edc21f3adb1e9d386059d1c543c70eb298d0f8e555dafb6682a55d35c5836979fc12132e8ba06f5
2020-06-21Merge #19200: rpc: remove deprecated getaddressinfo fieldsSamuel Dobson
bc01f7ae0538d3c647ce8dfbc29f7914d5df3fbb doc: release note for rpc getaddressinfo removals (Jon Atack) 90e989390ee50633fff0e4f210a1ea23ff00e012 rpc: getaddressinfo RPCResult fixup (Jon Atack) a8507c99da10791aa69ca277128e06753942e976 rpc: remove deprecated getaddressinfo `labels: purpose` (Jon Atack) 645a8653c895e4fc7717e9e5ac045612b5deaa60 rpc: remove deprecated getaddressinfo `label` field (Jon Atack) Pull request description: These were deprecated in #17578 and #17585, with expected 0.21 removal notified in the 0.20 release notes. ``` - The `getaddressinfo` RPC has had its `label` field deprecated (re-enable for this release using the configuration parameter `-deprecatedrpc=label`). The `labels` field is altered from returning JSON objects to returning a JSON array of label names (re-enable previous behavior for this release using the configuration parameter `-deprecatedrpc=labelspurpose`). Backwards compatibility using the deprecated configuration parameters is expected to be dropped in the 0.21 release. (#17585, #17578) ``` ACKs for top commit: Sjors: utACK bc01f7a adamjonas: utACK bc01f7a meshcollider: utACK bc01f7ae0538d3c647ce8dfbc29f7914d5df3fbb Tree-SHA512: ae1af381e32c4c3bde8b061a56382838513a9a82c88767843cdeae3a2ab8aa7d8c2e66e106d2b31ea07d74bb80c191a2f842c9aaecc7c5438ad9a9bc66d1b251
2020-06-21Merge #16377: [rpc] don't automatically append inputs in walletcreatefundedpsbtSamuel Dobson
e5327f947c310849e1ddbb24321e4c9f85564549 [rpc] fundrawtransaction: add_inputs option to control automatic input adding (Sjors Provoost) 79804fe24bd00e183382dfbcab9343960d158aa5 [rpc] walletcreatefundedpsbt: don't automatically append inputs (Sjors Provoost) Pull request description: When the user doesn't specificy inputs, it makes sense to automatically select them. But when the user does specify inputs, `walletcreatefundedpsbt` now fails if the amount is insufficient, unless `addInputs` is set to `true`. Similarly for `fundrawtransaction` if the original transaction already specified inputs, we only add more if `addInputs` is set to `true`. This protects against fat finger mistakes in the amount or fee rate (see also #16257). The behavior is also more similar to GUI coin selection. ACKs for top commit: achow101: ACK e5327f947c310849e1ddbb24321e4c9f85564549 meshcollider: utACK e5327f947c310849e1ddbb24321e4c9f85564549 Tree-SHA512: d8653b820914396c7c25b0d0a2b7e92de214aa023bc1aa085feb37d3b20fab361ebea90416a7db989f19bdc37e26cf0adfbcb712c80985c87afa67a9bd44fecb
2020-06-19[rpc] refactor: consolidate sendmany and sendtoaddress codeSjors Provoost
The only new behavior is some error codes are changed from -4 to -6.
2020-06-17doc: add C++17 release note for 0.21.0fanquake
Mention that the codebase is now compatible with C++17, and that the intention is to require C++17 starting with 0.22.0.
2020-06-13Replace current benchmarking framework with nanobenchMartin Ankerl
This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench * Adds support for asymptotes This adds support to calculate asymptotic complexity of a benchmark. This is similar to #17375, but currently only one asymptote is supported, and I have added support in the benchmark `ComplexMemPool` as an example. Usage is e.g. like this: ``` ./bench_bitcoin -filter=ComplexMemPool -asymptote=25,50,100,200,400,600,800 ``` This runs the benchmark `ComplexMemPool` several times but with different complexityN settings. The benchmark can extract that number and use it accordingly. Here, it's used for `childTxs`. The output is this: | complexityN | ns/op | op/s | err% | ins/op | cyc/op | IPC | total | benchmark |------------:|--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|----------:|:---------- | 25 | 1,064,241.00 | 939.64 | 1.4% | 3,960,279.00 | 2,829,708.00 | 1.400 | 0.01 | `ComplexMemPool` | 50 | 1,579,530.00 | 633.10 | 1.0% | 6,231,810.00 | 4,412,674.00 | 1.412 | 0.02 | `ComplexMemPool` | 100 | 4,022,774.00 | 248.58 | 0.6% | 16,544,406.00 | 11,889,535.00 | 1.392 | 0.04 | `ComplexMemPool` | 200 | 15,390,986.00 | 64.97 | 0.2% | 63,904,254.00 | 47,731,705.00 | 1.339 | 0.17 | `ComplexMemPool` | 400 | 69,394,711.00 | 14.41 | 0.1% | 272,602,461.00 | 219,014,691.00 | 1.245 | 0.76 | `ComplexMemPool` | 600 | 168,977,165.00 | 5.92 | 0.1% | 639,108,082.00 | 535,316,887.00 | 1.194 | 1.86 | `ComplexMemPool` | 800 | 310,109,077.00 | 3.22 | 0.1% |1,149,134,246.00 | 984,620,812.00 | 1.167 | 3.41 | `ComplexMemPool` | coefficient | err% | complexity |--------------:|-------:|------------ | 4.78486e-07 | 4.5% | O(n^2) | 6.38557e-10 | 21.7% | O(n^3) | 3.42338e-05 | 38.0% | O(n log n) | 0.000313914 | 46.9% | O(n) | 0.0129823 | 114.4% | O(log n) | 0.0815055 | 133.8% | O(1) The best fitting curve is O(n^2), so the algorithm seems to scale quadratic with `childTxs` in the range 25 to 800.
2020-06-12doc: improve subtree check instructionsSjors Provoost
2020-06-08doc: release note for rpc getaddressinfo removalsJon Atack
2020-06-07doc: release note for `db` log category removalJon Atack
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-05 06:59:31 +0000