aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
2020-09-02Merge #14687: zmq: enable tcp keepaliveJonas Schnelli
c276df775914e4e42993c76e172ef159e3b830d4 zmq: enable tcp keepalive (mruddy) Pull request description: This addresses https://github.com/bitcoin/bitcoin/issues/12754. These changes enable node operators to address the silent dropping (by network middle boxes) of long-lived low-activity ZMQ TCP connections via further operating system level TCP keepalive configuration. For example, ZMQ sockets that publish block hashes can be affected in this way due to the length of time it sometimes takes between finding blocks (e.g.- sometimes more than an hour). Prior to this patch, operating system level TCP keepalive configurations would not take effect since the SO_KEEPALIVE option was not enabled on the underlying socket. There are additional ZMQ socket options related to TCP keepalive that can be set. However, I decided not to implement those options in this changeset because doing so would require adding additional bitcoin node configuration options, and would not yield a better outcome. I preferred a small, easily reviewable patch that doesn't add a bunch of new config options, with the tradeoff that the fine tuning would have to be done via well-documented operating system specific configurations. I tested this patch by running a node with: `./src/qt/bitcoin-qt -regtest -txindex -datadir=/tmp/node -zmqpubhashblock=tcp://127.0.0.1:28332 &` and connecting to it with: `python3 ./contrib/zmq/zmq_sub.py` Without these changes, `ss -panto | grep 28332 | grep ESTAB | grep bitcoin` will report no keepalive timer information. With these changes, the output from the prior command will show keepalive timer information consistent with the configuration at the time of connection establishment, e.g.-: `timer:(keepalive,119min,0)`. I also tested with a non-TCP transport and did not witness any adverse effects: `./src/qt/bitcoin-qt -regtest -txindex -datadir=/tmp/node -zmqpubhashblock=ipc:///tmp/bitcoin.block &` ACKs for top commit: adamjonas: Just to summarize for those looking to review - as of c276df775914e4e42993c76e172ef159e3b830d4 there are 3 tACKs (n-thumann, Haaroon, and dlogemann), 1 "looks good to me" (laanwj) with no NACKs or any show-stopping concerns raised. jonasschnelli: utACK c276df775914e4e42993c76e172ef159e3b830d4 Tree-SHA512: b884c2c9814e97e666546a7188c48f9de9541499a11a934bd48dd16169a900c900fa519feb3b1cb7e9915fc7539aac2829c7806b5937b4e1409b4805f3ef6cd1
2020-09-01Merge #19668: Do not hide compile-time thread safety warningsMarcoFalke
ea74e10acf17903e44c85e3678853414653dd4e1 doc: Add best practice for annotating/asserting locks (Hennadii Stepanov) 2ee7743fe723227f2ea1b031eddb14fc6863f4c8 sync.h: Make runtime lock checks require compile-time lock checks (Anthony Towns) 23d71d171e6e22ba5e4a909d597a54595b2a2c1f Do not hide compile-time thread safety warnings (Hennadii Stepanov) 3ddc150857178bfb1c854c05bf9b526777876f56 Add missed thread safety annotations (Hennadii Stepanov) af9ea55a72c94678b343f5dd98dc78f3a3ac58cb Use LockAssertion utility class instead of AssertLockHeld() (Hennadii Stepanov) Pull request description: On the way of transit from `RecursiveMutex` to `Mutex` (see #19303) it is crucial to have run-time `AssertLockHeld()` assertion that does _not_ hide compile-time Clang Thread Safety Analysis warnings. On master (65e4ecabd5b4252154640c7bac38c92a3f3a7018) using `AssertLockHeld()` could hide Clang Thread Safety Analysis warnings, e.g., with the following patch applied: ```diff --- a/src/txmempool.h +++ b/src/txmempool.h @@ -607,7 +607,7 @@ public: void addUnchecked(const CTxMemPoolEntry& entry, setEntries& setAncestors, bool validFeeEstimate = true) EXCLUSIVE_LOCKS_REQUIRED(cs, cs_main); void removeRecursive(const CTransaction& tx, MemPoolRemovalReason reason) EXCLUSIVE_LOCKS_REQUIRED(cs); - void removeForReorg(const CCoinsViewCache* pcoins, unsigned int nMemPoolHeight, int flags) EXCLUSIVE_LOCKS_REQUIRED(cs, cs_main); + void removeForReorg(const CCoinsViewCache* pcoins, unsigned int nMemPoolHeight, int flags) EXCLUSIVE_LOCKS_REQUIRED(cs_main); void removeConflicts(const CTransaction& tx) EXCLUSIVE_LOCKS_REQUIRED(cs); void removeForBlock(const std::vector<CTransactionRef>& vtx, unsigned int nBlockHeight) EXCLUSIVE_LOCKS_REQUIRED(cs); ``` Clang compiles the code without any thread safety warnings. See "Add missed thread safety annotations" commit for the actual thread safety warnings that are fixed in this PR. ACKs for top commit: MarcoFalke: ACK ea74e10acf 🎙 jnewbery: ACK ea74e10acf17903e44c85e3678853414653dd4e1 ajtowns: ACK ea74e10acf17903e44c85e3678853414653dd4e1 Tree-SHA512: 8cba996e526751a1cb0e613c0cc1b10f027a3e9945fbfb4bd30f6355fd36b9f9c2e1e95ed3183fc254b42df7c30223278e18e5bdb5e1ef85db7fef067595d447
2020-09-01Merge #19671: wallet: Remove -zapwallettxesfanquake
3340dbadd38f5624642cf0e14dddbe6f83a3863b Remove -zapwallettxes (Andrew Chow) Pull request description: It's not clear what use there is to keeping `-zapwallettxes` given that it's intended usage has been superseded by `abandontransaction`. So this removes it outright. Alternative to #19700 ACKs for top commit: meshcollider: utACK 3340dbadd38f5624642cf0e14dddbe6f83a3863b fanquake: ACK 3340dbadd38f5624642cf0e14dddbe6f83a3863b - remaining manpage references will get cleaned up pre-release. Tree-SHA512: 3e58e1ef6f4f94894d012b93e88baba3fb9c2ad75b8349403f9ce95b80b50b0b4f443cb623cf76c355930db109f491b3442be3aa02972e841450ce52cf545fc8
2020-08-31Remove -zapwallettxesAndrew Chow
-zapwallettxes is made a hidden option to inform users that it is removed and they should be using abandontransaction to do the stuck transaction thing.
2020-08-31Merge #18244: rpc: fundrawtransaction and walletcreatefundedpsbt also lock ↵Samuel Dobson
manually selected coins 6d1f51343cf11b07cd401fbd0c5bc3603e185a0e [rpc] fundrawtransaction, walletcreatefundedpsbt lock manually selected coins (Sjors Provoost) Pull request description: When using `fundrawtransaction` and `walletcreatefundedpsbt` with `lockUnspents`, it would only lock automatically selected coins, not manually selected coins. That doesn't make much sense to me if the goal is to prevent accidentally double-spending yourself before you broadcast a transaction. Note that when creating a transaction, manually selected coins are automatic "unlocked" (or more accurately: the lock is ignored). Earlier versions of this PR introduced an error when a locked coin is manually selected, but this idea was abandoned after some discussion. An application that uses this RPC should either rely on automatic coin selection (with `lockUnspents`) or handle lock concurrency itself with manual coin selection. In particular it needs to make sure to avoid/pause calls with automatic coin selection between calling `lockunspent` and the subsequent spending RPC. See #7518 for historical background. ACKs for top commit: meshcollider: Code review ACK 6d1f51343cf11b07cd401fbd0c5bc3603e185a0e fjahr: Code review ACK 6d1f51343cf11b07cd401fbd0c5bc3603e185a0e Tree-SHA512: 8773c788d92f2656952e1beac147ba9956b8c5132d474e0880e4c89ff53642928b4cbfcd1cb3d17798b9284f02618a8830c93a9f7a4733e5bded96adff1d5d4d
2020-08-29doc: Add best practice for annotating/asserting locksHennadii Stepanov
2020-08-25Merge #19628: net: change CNetAddr::ip to have flexible sizeMarcoFalke
102867c587f5f7954232fb8ed8e85cda78bb4d32 net: change CNetAddr::ip to have flexible size (Vasil Dimov) 1ea57ad67406b3aaaef5254bc2fa7e4134f3a6df net: don't accept non-left-contiguous netmasks (Vasil Dimov) Pull request description: (chopped off from #19031 to ease review) Before this change `CNetAddr::ip` was a fixed-size array of 16 bytes, not being able to store larger addresses (e.g. TORv3) and encoded smaller ones as 16-byte IPv6 addresses. Change its type to `prevector`, so that it can hold larger addresses and do not disguise non-IPv6 addresses as IPv6. So the IPv4 address `1.2.3.4` is now encoded as `01020304` instead of `00000000000000000000FFFF01020304`. Rename `CNetAddr::ip` to `CNetAddr::m_addr` because it is not an "IP" or "IP address" (TOR addresses are not IP addresses). In order to preserve backward compatibility with serialization (where e.g. `1.2.3.4` is serialized as `00000000000000000000FFFF01020304`) introduce `CNetAddr` dedicated legacy serialize/unserialize methods. Adjust `CSubNet` accordingly. Still use `CSubNet::netmask[]` of fixed 16 bytes, but use the first 4 for IPv4 (not the last 4). Do not accept invalid netmasks that have 0-bits followed by 1-bits and only allow subnetting for IPv4 and IPv6. Co-authored-by: Carl Dong <contact@carldong.me> ACKs for top commit: sipa: utACK 102867c587f5f7954232fb8ed8e85cda78bb4d32 MarcoFalke: Concept ACK 102867c587f5f7954232fb8ed8e85cda78bb4d32 ryanofsky: Code review ACK 102867c587f5f7954232fb8ed8e85cda78bb4d32. Just many suggested updates since last review. Thanks for following up on everything! jonatack: re-ACK 102867c587f5f7954232fb8ed8e85cda78bb4d32 diff review, code review, build/tests/running bitcoind with ipv4/ipv6/onion peers kallewoof: ACK 102867c587f5f7954232fb8ed8e85cda78bb4d32 Tree-SHA512: d60bf716cecf8d3e8146d2f90f897ebe956befb16f711a24cfe680024c5afc758fb9e4a0a22066b42f7630d52cf916318bedbcbc069ae07092d5250a11e8f762
2020-08-24net: don't accept non-left-contiguous netmasksVasil Dimov
A netmask that contains 1-bits after 0-bits (the 1-bits are not contiguous on the left side) is invalid [1] [2]. The code before this PR used to parse and accept such non-left-contiguous netmasks. However, a coming change that will alter `CNetAddr::ip` to have flexible size would make juggling with such netmasks more difficult, thus drop support for those. [1] https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#Subnet_masks [2] https://tools.ietf.org/html/rfc4632#section-5.1
2020-08-24Merge #19731: net, rpc: expose nLastBlockTime/nLastTXTime as last ↵Wladimir J. van der Laan
block/last_transaction in getpeerinfo 5da96210fc2fda9fbd79531f42f91262fd7a9257 doc: release note for getpeerinfo last_block/last_transaction (Jon Atack) cfef5a2c98b9563392a4a258fedb8bdc869c9749 test: rpc_net.py logging and test naming improvements (Jon Atack) 21c57bacda766a4f56ee75a2872f5d0f94e3901e test: getpeerinfo last_block and last_transaction tests (Jon Atack) 8a560a7d57cbd9f473d6a3782893a0e2243c55bd rpc: expose nLastBlockTime/TXTime as getpeerinfo last_block/transaction (Jon Atack) 02fbe3ae0bd91cbab2828cb7aa46f6493c82f026 net: add nLastBlockTime/TXTime to CNodeStats, CNode::copyStats (Jon Atack) Pull request description: This PR adds inbound peer eviction criteria `nLastBlockTime` and `nLastTXTime` to `CNodeStats` and `CNode::copyStats`, which then allows exposing them in the next commit as `last_transaction` and `last_block` Unix Epoch Time fields in RPC `getpeerinfo`. This may be useful for writing missing eviction tests. I'd also like to add `lasttx` and `lastblk` columns to the `-netinfo` dashboard as described in https://github.com/bitcoin/bitcoin/pull/19643#issuecomment-671093420. Relevant discussion at the p2p irc meeting http://www.erisian.com.au/bitcoin-core-dev/log-2020-08-11.html#l-549: ```text <jonatack> i was specifically trying to observe and figure out how to test https://github.com/bitcoin/bitcoin/issues/19500 <jonatack> which made me realise that i didn't know what was going on with my peer conns in enough detail <jonatack> i'm running bitcoin locally with nLastBlockTime and nLastTXTime added to getpeerinfo for my peer connections dashboard <jonatack> sipa: is there a good reason why that (eviction criteria) data is not exposed through getpeerinfo currently? <sipa> jonatack: nope; i suspect just nobody ever added it <jonatack> sipa: thanks. will propose. ``` The last commit is optional, but I think it would be good to have logging in `rpc_net.py`. ACKs for top commit: jnewbery: Code review ACK 5da96210fc2fda9fbd79531f42f91262fd7a9257 theStack: Code Review ACK 5da96210fc2fda9fbd79531f42f91262fd7a9257 darosior: ACK 5da96210fc2fda9fbd79531f42f91262fd7a9257 Tree-SHA512: 2db164bc979c014837a676e890869a128beb7cf40114853239e7280f57e768bcb43bff6c1ea76a61556212135281863b5290b50ff9d24fce16c5b89b55d4cd70
2020-08-20Merge #19550: rpc: Add getindexinfo RPCWladimir J. van der Laan
124e1ee1343f8bfb3748393ced9debdbdee60d3b doc: Add release notes for getindexinfo RPC (Fabian Jahr) c447b09458c89c946957a211a4f5373b92af44bf test: Add tests for getindexinfo RPC (Fabian Jahr) 667bc7a7f7c5d9a15eaf6957c3d8841a75efa7bc rpc: Add getindexinfo RPC (Fabian Jahr) Pull request description: As I was playing with indices a I was missing an RPC that gives information about the active indices in the node. I think this can be helpful for many users, especially since there are some new index candidates coming up (#14053, #18000) that can give a quick overview without the user having to parse the logs. Feature summary: - Adds new RPC `listindices` (placed in Util section) - That RPC only lists the actively running indices - For each index it gives the name, whether it is synced and up to which block height it is synced ACKs for top commit: laanwj: Re-ACK 124e1ee1343f8bfb3748393ced9debdbdee60d3b jonatack: Code review re-ACK 124e1ee per `git range-diff a57af89 47a5372 124e1ee` no change since my last re-ACK, rebase only Tree-SHA512: 3b7174c87951e6457fef099f530337803906baf32fb64261410b8def2c0917853d6a1bf3059cd590b1cc1523608f8916dafb327a431d27ecbf8d7454406b5b35
2020-08-18doc: release notes for -maxapsfeeKarl-Johan Alm
2020-08-16doc: Add release notes for getindexinfo RPCFabian Jahr
2020-08-15doc: release note for getpeerinfo last_block/last_transactionJon Atack
2020-08-13Add loadwallet and createwallet RPC load_on_startup optionsRussell Yanofsky
This maintains a persistent list of wallets stored in settings that will automatically be loaded on startup. Being able to load a wallet automatically on startup will be more useful in the GUI when the option to create wallets is added in #15006, but it's reasonable to expose this feature by RPC as well.
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-07[rpc] fundrawtransaction, walletcreatefundedpsbt lock manually selected coinsSjors Provoost
Previously only automatically selected coins were locked when lockUnspents is set. It now also locks selected coins.
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
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-07 12:24:41 +0000