aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2019-02-01Merge #15308: build: Restore compatibility with older boostMarcoFalke
119d360aab travis: Document whether functional tests are run in the job name (Ben Woosley) 64f28545e3 Revert "travis: Compile trusty with depends for now" (Ben Woosley) 267eac00f9 Prefer boost::optional#get_value_or over #value_or (Ben Woosley) 1971f5ba04 Piecewise construct to avoid invalid construction (Ben Woosley) Pull request description: In light of #14979, I realized that only qt 5.5+ was being tested under CI, while compatibility lists 5.2+. In #15276, Marco added Trusty to CI, building with depends. This changes that build to system libraries, in order to ensure ongoing compatibility with our claimed minimum required versions. Fixes #14983, previously open as #14998 Tree-SHA512: 6cff5e28c756ecb8bf797c8f6eb77c1944ba61a8dd6d7d4984e63eef384f6429dc79c505da3241c05b9c4db31c72b2a9846c7365aba9280f2e0620e5f3998d07
2019-02-01Merge #15235: Do not import private keys to wallets with private keys disabledWladimir J. van der Laan
e6c58d3b014ab8ef5cca4be68764af4b79685fcb Do not import private keys to wallets with private keys disabled (Andrew Chow) b5c5021b644731d14a6ef04961320a99466f035a Refactor importwallet to extract data from the file and then import (Andrew Chow) 1f77f6754ce724493b0cb084ae0b35107d58605f tests: unify RPC argument to cli argument conversion and handle dicts and lists (Andrew Chow) Pull request description: Fixes a bug where private keys could be imported to wallets with private keys disabled. Now every RPC which can import private keys checks for whether the wallet has private keys are disabled and errors if it is. Also added an belt-and-suspenders check to `AddKeyPubkeyWithDB` to have it assert that the wallet has private keys enabled. Tree-SHA512: 5cd04febce9aa2bd9bfd02f312c6ff8705e37278cae59efd3895f6d6e2f1b477aefd297e2dd0860791bdd3d4f3cad8eb1a404f8f3d4e2035b91314ad2c1028ae
2019-01-31Prefer boost::optional#get_value_or over #value_orBen Woosley
The latter is not defined in the earliest supported version of boost, 1.47. https://www.boost.org/doc/libs/1_47_0/libs/optional/doc/html/boost_optional/detailed_semantics.html https://travis-ci.org/bitcoin/bitcoin/jobs/486674823
2019-01-31Piecewise construct to avoid invalid constructionBen Woosley
In CMainSignals::RegisterWithMempoolSignals running under Ubuntu 14.04 (QT 5.2), absent piecewise construction this fails to create the pair because the argument is a connection, which is converted into a non-copyable scoped_connection. validationinterface.cpp:80:186: required from here /usr/include/boost/signals2/connection.hpp:234:7: error: ‘boost::signals2::scoped_connection::scoped_connection(const boost::signals2::scoped_connection&)’ is private scoped_connection(const scoped_connection &other); ^ In file included from /usr/include/c++/4.8/utility:70:0, from /usr/include/c++/4.8/algorithm:60, from ./prevector.h:13, from ./script/script.h:10, from ./primitives/transaction.h:11, from ./validationinterface.h:9, from validationinterface.cpp:6: /usr/include/c++/4.8/bits/stl_pair.h:134:45: error: within this context : first(std::forward<_U1>(__x)), second(__y) { } https://travis-ci.org/bitcoin/bitcoin/jobs/473689141#L2172
2019-01-31Do not import private keys to wallets with private keys disabledAndrew Chow
2019-01-31Refactor importwallet to extract data from the file and then importAndrew Chow
Instead of importing keys and scripts as each line in the file is read, first extract the data then import them.
2019-01-31Merge #15299: Fix assertion in CKey::SignCompactWladimir J. van der Laan
3617f117394285c87c395a0ccc92941977f97019 Fix assertion in CKey::SignCompact (João Barbosa) Pull request description: Fixes #15286. Tree-SHA512: b39b6f26f87cf1850b13f625ab6de963937b6ecb5b6d4ac4932134f0491a6c0fa61c6d6e6980e8b1770775578dc365fdd1b6ba426bba1f7c23430f68b3a2339a
2019-01-31Merge #11911: Free BerkeleyEnvironment instances when not in useWladimir J. van der Laan
14bc2a17dd03ccd89f65a302328763ff22c710c2 Trivial: add doxygen-compatible comments relating to BerkeleyEnvironment (Pierre Rochard) 88b1d956fe3e38f2d2dd805feee9dadb0be9e8a9 Tests: add unit tests for GetWalletEnv (Pierre Rochard) f1f4bb7345b90853ec5037478173601035593d26 Free BerkeleyEnvironment instances when not in use (Russell Yanofsky) Pull request description: Instead of adding BerkeleyEnvironment objects permanently to the g_dbenvs map, use reference counted shared pointers and remove map entries when the last BerkeleyEnvironment reference goes out of scope. This change was requested by @TheBlueMatt and makes code that sets up mock databases cleaner. The mock database environment will now go out of scope and be reset on destruction so there is no need to call BerkeleyEnvironment::Reset() during wallet construction to clear out prior state. This change does affect bitcoin behavior slightly. On startup, instead of same wallet environments staying open throughout VerifyWallets() and OpenWallets() calls, VerifyWallets() will open and close an environment once for each wallet, and OpenWallets() will create its own environment(s) later. Tree-SHA512: 219d77a9e2268298435b86088f998795e059fdab1d2050ba284a9ab8d8a44961c9b5cf96e94ee521688108d23c6db680e3e3a999b8cb2ac2a8590f691d50668b
2019-01-31Merge #13926: [Tools] bitcoin-wallet - a tool for creating and managing ↵MarcoFalke
wallets offline 3c3e31c3a4 [tests] Add wallet-tool test (João Barbosa) 49d2374acf [tools] Add wallet inspection and modification tool (Jonas Schnelli) Pull request description: Adds an offline tool `bitcoin-wallet-tool` for wallet creation and maintenance. Currently this tool can create a new wallet file, display information on an existing wallet, and run the salvage and zapwallettxes maintenance tasks on an existing wallet. It can later be extended to support other common wallet maintenance tasks. Doing wallet maintenance tasks in an offline tool makes much more sense (and is potentially safer) than having to spin up a full node. Tree-SHA512: 75a28b8a58858d9d76c7532db40eacdefc5714ea5aab536fb1dc9756e2f7d750d69d68d59c50a68e633ce38fb5b8c3e3d4880db30fe01561e07ce58d42bceb2b
2019-01-31Fix assertion in CKey::SignCompactJoão Barbosa
2019-01-31Merge #15225: GUI: Change the receive button to respond to keypool state ↵Wladimir J. van der Laan
changing 2bc4c3eaf96f5f8490fc79280422916c5d14cde3 Notify the GUI that the keypool has changed to set the receive button (Andrew Chow) 14bcdbe09cffaef9bcc51dd9de1645db3f0a93db Check for more than private keys disabled to show receive button (Andrew Chow) Pull request description: Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. #14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with #14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled. This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool. Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
2019-01-31Merge #15272: doc: correct logging return type and RPC exampleWladimir J. van der Laan
e1c27da30378940095806b2bf9989b162ed8ac07 doc: correct logging rpc return type and example (fanquake) Pull request description: Logging status is returned as a bool. ``` src/bitcoin-cli logging "[\"all\"]" "[\"http\"]" { "net": true, "tor": true, "mempool": true, "http": false, "bench": true, "zmq": true, "db": true, "rpc": true, "estimatefee": true, "addrman": true, "selectcoins": true, "reindex": true, "cmpctblock": true, "rand": true, "prune": true, "proxy": true, "mempoolrej": true, "libevent": true, "coindb": true, "qt": true, "leveldb": true } ``` Also corrects the RPC example so that `libevent` logging will actually be turned off. Tree-SHA512: 2de7130df51688d2d6636c12fd56326362794118a10efc8100f0bf541a7da00a12a6cd9d75e599a104513a050bbe49b418ea460ee8033ac6cf6ffb8e8e9140d6
2019-01-30Merge #15292: Remove 'boost::optional'-related false positive ↵Wladimir J. van der Laan
-Wmaybe-uninitialized warnings on GCC compiler 2d483142a7051389afe74c57a216843e6306f1a8 Remove 'boost::optional'-related gcc warnings (Hennadii Stepanov) Pull request description: #14711 introduced some warnings when building with gcc compiler. See: - https://github.com/bitcoin/bitcoin/pull/14711#issuecomment-454760017 by @laanwj - https://github.com/bitcoin/bitcoin/pull/14711#pullrequestreview-193702611 by @ryanofsky This gcc [issue](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679) has been known since version 4.6.0 and last updated in 2017. From the boost [docs](https://www.boost.org/doc/libs/1_69_0/libs/optional/doc/html/boost_optional/quick_start/optional_automatic_variables.html): > The default constructor of `optional` creates an _uninitialized_ `optional` object. Also: [False positive with -Wmaybe-uninitialized](https://www.boost.org/doc/libs/1_69_0/libs/optional/doc/html/boost_optional/tutorial/gotchas/false_positive_with__wmaybe_uninitialized.html) ([pointed out](https://github.com/bitcoin/bitcoin/pull/15292#issuecomment-459063170) by @Empact) This PR removes these warnings. cc: @Empact @practicalswift Tree-SHA512: 752ae3c3ca6282bbf98726236fbc3069ab9d1aee57ae2ec2668b32e4541e7bc1acb15b7d6fa9e2b6daf1ec29c0987a1053ee1ca0f523b71367ff911221c58c94
2019-01-30[tools] Add wallet inspection and modification toolJonas Schnelli
This commit adds wallet-tool, a tool for creating and interacting with wallet files. Original implementation was by Jonas Schnelli <dev@jonasschnelli.ch> with modifications by John Newbery <john@johnnewbery.com> MSVC files were provided by Chun Kuan Lee <ken2812221@gmail.com>: build: Add MSVC project files for bitcoin-wallet-tool
2019-01-30Remove 'boost::optional'-related gcc warningsHennadii Stepanov
2019-01-30Merge #15043: test: Build fuzz targets into seperate executablesWladimir J. van der Laan
2ca632e5b44a8385989c8539cc4e30e60fdee16c test: Build fuzz targets into seperate executables (MarcoFalke) fab4bed68a3964ace5620a25d32d62ed87003126 [test] fuzz: make test_one_input return void (MarcoFalke) Pull request description: Currently our fuzzer is a single binary that decides on the first few bits of the buffer what target to pick. This is ineffective as the fuzzer needs to "learn" how the fuzz targets are organized and could get easily confused. Not to mention that the (seed) corpus can not be categorized by target, since targets might "leak" into each other. Also the corpus would potentially become invalid if we ever wanted to remove a target... Solve that by building each fuzz target into their own executable. Tree-SHA512: a874febc85a3c5e6729199542b65cad10640553fba6f663600c827fe144543744dd0f844fb62b4c95c6a04c670bfce32cdff3d5f26de2dfc25f10b258eda18ab
2019-01-30Merge #15163: Correct units for "-dbcache" and "-prune"Wladimir J. van der Laan
6f6514a08090b37b5e8c086015ee4881813ef867 Correct units for "-dbcache" and "-prune" (Hennadii Stepanov) Pull request description: Actually, all `dbcache`-related values in the code are measured in MiB (not in megabytes, MB) or in bytes (e.g., `nTotalCache`). See: https://github.com/bitcoin/bitcoin/blob/master/src/txdb.h https://github.com/bitcoin/bitcoin/blob/ba8c8b22272ad40fe2de465d7e745532bab48d3b/src/init.cpp#L1405-L1424 Also, "-prune" is fixed: 1. The GUI values in GB are translated to the node values in MiB correctly. 2. The maximum of the "prune" `QSpinBox` is not limited by default value of 99 (GB). Fix: #15106 Tree-SHA512: 151ec43b31b1074db8b345fedb1dcc10bde225899a5296bfc183f57e1553d13ac27db8db100226646769ad03c9fcab29d88763065a471757c6c41ac51108459d
2019-01-30Merge #15279: wallet: Clarify rescanblockchain docMarcoFalke
fa5e6ef55c wallet: Fixup rescanblockchain result doc (MarcoFalke) Pull request description: This was probably accidentally added to the wrong line when addressing the feedback here: https://github.com/bitcoin/bitcoin/pull/7061#discussion_r142199778 I already added the default values in #14877, but it could be clarified more that this really has no specific block height as default value, since the tip can change during a rescan. Tree-SHA512: 48a3c5143e2b7129ee8f396d2e77550cb393fbe45f5936aeebeb7a201d61560336a3ae47b26bb757a4dbbe217e06abfd67a5a673aef266b6c4d7a80d049a2b49
2019-01-30Merge #15159: [RPC] Remove lookup to UTXO set from GetTransactionMarcoFalke
04da9f4834 [RPC] Update getrawtransaction interface (Amiti Uttarwar) Pull request description: - stop checking unspent UTXOs for a transaction when txindex is not enabled, as per conversation here: https://github.com/bitcoin/bitcoin/issues/3220#issuecomment-377458383 - code contributed by sipa Tree-SHA512: aa07353bccc14b81b7803992a25d076d6bc06d15ec7c1b85828dc10aea7e0498d9b49f71783e352ab8a14b0bb2010cfb7835de3dfd1bc6f2323f460449348e66
2019-01-30Merge #15270: Pull leveldb subtreeWladimir J. van der Laan
4f2e6c8b881b7ccda36233332dfd1bd231389a8e Squashed 'src/leveldb/' changes from 524b7e36a8..f545dfabff (MarcoFalke) Pull request description: Some windows-related fixes. Sanity check with: ``` git fetch https://github.com/bitcoin-core/leveldb ./test/lint/git-subtree-check.sh src/leveldb Tree-SHA512: ff94907ff3075b81cffb733129673a9bfd2abbe84240686b29274382b64b4e5845880236458043d6db0332bf70d12942d9c0e68b4fffab43931103d224cb59d4
2019-01-30Correct units for "-dbcache" and "-prune"Hennadii Stepanov
All dbcache-related values in the code are measured in MiB (not in megabytes, MB) or in bytes. The GUI "-prune" values in GB are translated to the node values in MiB correctly. The maximum of the "-prune" QSpinBox is not limited by the default value of 99 (GB). Also, this improves log readability.
2019-01-30Merge #14711: Remove uses of chainActive and mapBlockIndex in wallet codeMeshCollider
44de1561a Remove remaining chainActive references from CWallet (Russell Yanofsky) db21f0264 Convert CWallet::ScanForWalletTransactions and SyncTransaction to the new Chain apis (Russell Yanofsky) 2ffb07929 Add findFork and findBlock to the Chain interface (Russell Yanofsky) d93c4c1d6 Add time methods to the Chain interface (Russell Yanofsky) 700c42b85 Add height, depth, and hash methods to the Chain interface (Russell Yanofsky) Pull request description: This change removes uses of `chainActive` and `mapBlockIndex` globals in wallet code. It is a refactoring change which does not affect external behavior. This is the next step in the larger #10973 refactoring change, which removes all other accesses to node global variables from wallet code. Doing this is useful to provide a better defined interface between the wallet and node, and necessary to allow wallet and node code to run in separate processes in #10102. Tree-SHA512: 4dcec8a31c458f54e2ea6ecf01e430469b0994c5b41a21a2d150efa67cd209f4c93ae210a101e064b3a87c52c6edfc70b070e979992be0e3a00fd425de6230a8
2019-01-29test: Build fuzz targets into seperate executablesMarcoFalke
2019-01-29Merge #14929: net: Allow connections from misbehavior banned peersJonas Schnelli
0297be61a Allow connections from misbehavior banned peers. (Gregory Maxwell) Pull request description: This allows incoming connections from peers which are only banned due to an automatic misbehavior ban if doing so won't fill inbound. These peers are preferred for eviction when inbound fills, but may still be kept if they fall into the protected classes. This eviction preference lasts the entire life of the connection even if the ban expires. If they misbehave again they'll still get disconnected. The main purpose of banning on misbehavior is to prevent our connections from being wasted on unhelpful peers such as ones running incompatible consensus rules. For inbound peers this can be better accomplished with eviction preferences. A secondary purpose was to reduce resource waste from repeated abuse but virtually any attacker can get a nearly unlimited supply of addresses, so disconnection is about the best we can do. This can reduce the potential from negative impact due to incorrect misbehaviour bans. Tree-SHA512: 03bc8ec8bae365cc437daf70000c8f2edc512e37db821bc4e0fafa6cf56cc185e9ab40453aa02445f48d6a2e3e7268767ca2017655aca5383108416f1e2cf20f
2019-01-29wallet: Fixup rescanblockchain result docMarcoFalke
2019-01-29doc: correct logging rpc return type and examplefanquake
2019-01-29Merge #14987: RPCHelpMan: Pass through Result and ExamplesMarcoFalke
faa1522e5e RPCHelpMan: Pass through Result and Examples (MarcoFalke) Pull request description: Passing the rpc result and rpc examples through `RPCHelpMan` makes it clear in what order they appear in the stringified version. Future improvements could then autoformat or autogenerate them. Tree-SHA512: b32a5c178cc80f50a7e9b93a38e2b26d5994188ecafe9e61bbc599941b44b9b0e4e4be6413d4464fac6e8e73661a191a77d34917f2e6293de19fb59519dd4487
2019-01-28Merge #15248: rpc: Compile on GCC4.8MarcoFalke
fa5f890aeb rpc: Compile on GCC4.8 (MarcoFalke) Pull request description: GCC 4.8 is lacking some C++11 signatures (see "Adjust C++11 signatures to take a const_iterator." in GCC 4.9: https://github.com/gcc-mirror/gcc/commit/3d2b2f494d78e0f4168d2c7ba5a76c05b4f4af71) Fix that by changing the code to use the pre-GCC 4.9 signature. Can be reverted after #13356. Fixes #15172 (reports on `Linux Mint 17.3 Rosa` and `CentOS Linux release 7.5.1804 (Core)`) Tree-SHA512: 0c0b18968270ad4fcd0c2000c57485be881a461135dac3ad0bdab22c1a2292cf6b28ebeb930ccaa0290ff20ce87547fd07ab8189c4c4fb54d652a3d0bc9615f8
2019-01-27rpc: Compile on GCC4.8MarcoFalke
2019-01-27Merge #15254: Trivial: fixup a few doxygen commentsWladimir J. van der Laan
70e7cee96028889ab709fa3c479225e584fcb77f Trivial: Doxygenize existing CBufferedFile and VectorReader comments (Ben Woosley) 9431e1b91598fc255234ede10c22208ad18685cd Trivial: fixup a few doxygen comments (Ben Woosley) Pull request description: These were not declared properly, so their results are not properly processed. E.g.: https://dev.visucore.com/bitcoin/doxygen/rpcdump_8cpp.html#a994c8748aaa60fbb78009ff8a0638dea https://dev.visucore.com/bitcoin/doxygen/coins_8cpp.html#aa03af24ef3570144b045f4fca7a0d603 https://dev.visucore.com/bitcoin/doxygen/wallet_2wallet_8cpp.html#a5c2a7725ff8796f03471f844ecded3d9 > A third alternative is to use a block of at least two C++ comment lines, where each line starts with an additional slash or an exclamation mark. http://www.doxygen.nl/manual/docblocks.html Tree-SHA512: c13fd48ac78f25e51b1281385747e8be4bd6e27e0a0f8704608aa5c66c16715c639f1cf27018b1bf05fc2eaed6c7b9be05a68365ffe1d88dd3f400d453b7bead
2019-01-26[RPC] Update getrawtransaction interfaceAmiti Uttarwar
2019-01-26Pull leveldb subtreeMarcoFalke
2019-01-25[test] fuzz: make test_one_input return voidMarcoFalke
The return value is always 0 and not used, so might as well return void
2019-01-25Trivial: Doxygenize existing CBufferedFile and VectorReader commentsBen Woosley
2019-01-25RPCHelpMan: Pass through Result and ExamplesMarcoFalke
2019-01-25Merge #15233: Prevent mutex lock fail even if --enable-debugMarcoFalke
b09dab0f2d Prevent mutex lock fail even if --enable-debug (Akio Nakamura) Pull request description: This PR intends to resolve #15227. ```configure --enable-debug``` enables ```#ifdef DEBUG_LOCKORDER```. Then ```lockdata``` (in sync.cpp) will be initialized same as other static objects. But unfortunately, ```lockdata.push_lock()``` was called before its initialization (via initializing ```signatureCache``` which is declared in ```script/sigcache.cpp```) on macOS. This PR apply the "Construct On First Use Idiom" to ```lockdata``` to prevent it. edited --- fix typo. Tree-SHA512: 59df99ef78a335b1b7ebed7207d4719ea4412900eea38739f6e8eaaba1f594e1950044851659ce83f4f69813fc96978244bd176676e1aa2277c813ede832e6fb
2019-01-25Prevent mutex lock fail even if --enable-debugAkio Nakamura
This PR intends to resolve #15227. "configure --debug-enabled" enables "#ifdef DEBUG_LOCKORDER". Then "lockdata" (in sync.cpp) will be initialized same as other static objects. But unfortunately, lockdata.push_lock() was called before its initialization (via initializing signatureCache which is declared in script/sigcache.cpp) on macOS. This PR apply the "Construct On First Use Idiom" to "lockdata" to prevent it.
2019-01-24Trivial: fixup a few doxygen commentsBen Woosley
These were not declared properly, so their results are not properly processed. E.g.: https://dev.visucore.com/bitcoin/doxygen/rpcdump_8cpp.html#a994c8748aaa60fbb78009ff8a0638dea https://dev.visucore.com/bitcoin/doxygen/coins_8cpp.html#aa03af24ef3570144b045f4fca7a0d603 https://dev.visucore.com/bitcoin/doxygen/wallet_2wallet_8cpp.html#a5c2a7725ff8796f03471f844ecded3d9
2019-01-24Merge #15193: Default -whitelistforcerelay to offWladimir J. van der Laan
a36d97d866e8a11f205d07c624ace7c3d1a2ded8 Default -whitelistforcerelay to off (Suhas Daftuar) Pull request description: No one seems to use this "feature", and at any rate the behavior of relaying transactions when they violate local policy is error-prone, if we ever consider changing the ban behavior of our software from one version to the next. Defaulting this to off means that users who use -whitelist won't be unexpectedly surprised by this interaction. If anyone is still relying on this feature, it can still be explicitly turned on. Tree-SHA512: 52650ad464a728d1648f496751e3f713077ea3a1de7278ed03531b2e8723e63cf2f6f41b56c98c0f73ffa22c36e01d9170b409ab452c737aca35b7ecd7a6b448
2019-01-23Notify the GUI that the keypool has changed to set the receive buttonAndrew Chow
Whenever the keypool changes (new keys generated, new seed set, keypool runs out, etc.), notify the GUI that the keypool has changed. The receive button can then be enabled and disabled as necessary.
2019-01-22Merge #14353: REST: add blockhash call, fetch blockhash by heightJonas Schnelli
42ff30ec6 [Docs] add short documentation for /rest/blockhashbyheight (Jonas Schnelli) 579d418f7 [QA] add rest tests for /rest/blockhashbyheight/<HEIGHT>.<FORMAT> (Jonas Schnelli) eb9ef04c4 REST: add "blockhashbyheight" call, fetch blockhash by height (Jonas Schnelli) Pull request description: Completes the REST interface for trivial block exploring by adding a call that allows to fetch the blockhash in the main chain by a given height. Tree-SHA512: 94be9e56718f857279b11cc16dfa8d04f3b5a762e87ae54281b4d87247c71c844895f4944d5a47f09056bf851f4c4761ac4fbdbaaee957265d14de5c1c73e8d2
2019-01-22Merge #15208: Qt: remove macOS launch-at-startup when compiled with > macOS ↵Wladimir J. van der Laan
10.11, fix memory missmanagement da6011826a730837b59aef5664f3feab4787c9bc Fix macOS launch-at-startup memory issue (Jonas Schnelli) 516437a1b70b6df87faadfd38c3d84e6dfb5eae8 Qt: remove macOS launch-at-startup option when compiled with > macOS 10.11 (Jonas Schnelli) Pull request description: The launch-at-startup API Bitcoin Core uses on macOS where removed in macOS 10.11 leading to a segmentation-fault due to the weak-linking when not actively compiled against SDK 10.11 (`-mmacosx-version-min=10.11`) This PR removes the launch-at-startup feature on macOS when compiled with macOS min version > 10.11 (the default is always the macOS version you compile on). **The depends built binaries (Gitian) are not affected since we are building with min macOS 10.10.** Users self compiling on macOS > 10.11 can re-enable the feature by compiling with min version <= 10.11 (`CXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" ./configure`) **Isn't there a new API from Apple?** Yes, [there is](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html). It will require to create a helper application which needs to be embedded in the .app folder (needs code signing as well). Developers willing to go down that rabbit hole are welcome. Fixes #15142 Tree-SHA512: fa9cc4e39d5a2d2559919b7e22b7766f5e0269a361719294d4a4a2df2fd9d955e5b23b5907e68023fdeee297f652f844f3c447904bf18f9c1145348ad101c432
2019-01-22Allow connections from misbehavior banned peers.Gregory Maxwell
This allows incoming connections from peers which are only banned due to an automatic misbehavior ban if doing so won't fill inbound. These peers are preferred for eviction when inbound fills, but may still be kept if they fall into the protected classes. This eviction preference lasts the entire life of the connection even if the ban expires. If they misbehave again they'll still get disconnected. The main purpose of banning on misbehavior is to prevent our connections from being wasted on unhelpful peers such as ones running incompatible consensus rules. For inbound peers this can be better accomplished with eviction preferences. A secondary purpose was to reduce resource waste from repeated abuse but virtually any attacker can get a nearly unlimited supply of addresses, so disconnection is about the best we can do.
2019-01-22Default -whitelistforcerelay to offSuhas Daftuar
2019-01-21Fix macOS launch-at-startup memory issueJonas Schnelli
2019-01-21Qt: remove macOS launch-at-startup option when compiled with > macOS 10.11Jonas Schnelli
2019-01-21Check for more than private keys disabled to show receive buttonAndrew Chow
2019-01-21REST: add "blockhashbyheight" call, fetch blockhash by heightJonas Schnelli
2019-01-21Merge #14906: refactor: Make explicit CMutableTransaction -> CTransaction ↵Wladimir J. van der Laan
conversion. b301950df32443e358bc22ca22c6f9ac09d18219 Made expicit constructor CTransaction(const CMutableTransaction &tx). (lucash-dev) faf29dd019efef4b05e8e78885926764134d9c04 Minimal changes to comply with explicit CMutableTransaction -> CTranaction conversion. (lucash-dev) Pull request description: This PR is re-submission of #14156, which was automatically closed by github (glitch?) Original description: This PR makes explicit the now implicit conversion constructor `CTransaction(const CMutableTransaction&)` in `transaction.h`. Minimal changes were made elsewhere to make the code compilable. I'll follow up with other PRs to address individually refactoring functions that should have a `CMutableTransaction` version, or where a `CTransaction` should be reused. The rationale for this change is: - Conversion constructors should not be explicit unless there's a strong reason for it (in the opinion of, for example, https://google.github.io/styleguide/cppguide.html, and https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ro-conversion. Let me know your take on this). - This particular conversion is very costly -- it implies a serialization plus hash of the transaction. - Even though `CTransaction` and `CMutableTransaction` represent the same data, they have very different use cases and performance properties. - Making it explicit allows for easier reasoning of performance trade-offs. - There has been previous performance issues caused by unneeded use of this implicit conversion. - This PR creates a map for places to look for possible refactoring and performance gains (this benefit still holds if the PR is not merged). Tree-SHA512: 2427462e7211b5ffc7299dae17339d27f8c43266e0895690fda49a83c72751bd2489d4471b3993075a18f3fef25d741243e5010b2f49aeef4a9688b30b6d0631
2019-01-21Merge #14955: Switch all RNG code to the built-in PRNGWladimir J. van der Laan
223de8d94d6522f795ec3c2e7db27469f24aa68c Document RNG design in random.h (Pieter Wuille) f2e60ca98530e0a865ff6c6fd3c5633aec11a515 Use secure allocator for RNG state (Pieter Wuille) cddb31bb0a132afa50b5350196cf26f0064fe3e2 Encapsulate RNGState better (Pieter Wuille) 152146e782d401aa1ce7d989d62306aabc85f22e DRY: Implement GetRand using FastRandomContext::randrange (Pieter Wuille) a1f252eda87356fa329c838a7bf569808489648f Sprinkle some sweet noexcepts over the RNG code (Pieter Wuille) 4ea8e50837a0932b31a241988fd68d6730a2048a Remove hwrand_initialized. (Pieter Wuille) 9d7032e4f066777c97c58b1394884716e213790a Switch all RNG code to the built-in PRNG. (Pieter Wuille) 16e40a8b562ad849a5f5e8b21ceb375e46038243 Integrate util/system's CInit into RNGState (Pieter Wuille) 2ccc3d3aa346e96206281a391bc29874cf5ee7f4 Abstract out seeding/extracting entropy into RNGState::MixExtract (Pieter Wuille) aae8b9bf0f4fd2b801ee72cf191588c8b3a67c3c Add thread safety annotations to RNG state (Pieter Wuille) d3f54d1c82b131d817b20cd9daa75f9d3c9475e1 Rename some hardware RNG related functions (Pieter Wuille) 05fde14e3afe6f7156ebb6df6cd0e3ae12635b89 Automatically initialize RNG on first use. (Pieter Wuille) 2d1cc5093949f8ea9487a68724162c8b39035ad8 Don't log RandAddSeedPerfmon details (Pieter Wuille) 6a57ca91da23c6a5d91399ffc7fc09a99b6d4c76 Use FRC::randbytes instead of reading >32 bytes from RNG (Pieter Wuille) Pull request description: This does not remove OpenSSL, but makes our own PRNG the 'main' one; for GetStrongRandBytes, the OpenSSL RNG is still used (indirectly, by feeding its output into our PRNG state). It includes a few policy changes (regarding what entropy is seeded when). Before this PR: * GetRand*: * OpenSSL * GetStrongRand*: * CPU cycle counter * Perfmon data (on Windows, once 10 min) * /dev/urandom (or equivalent) * rdrand (if available) * From scheduler when idle: * CPU cycle counter before and after 1ms sleep * At startup: * CPU cycle counter before and after 1ms sleep After this PR: * GetRand*: * Stack pointer (which indirectly identifies thread and some call stack information) * rdrand (if available) * CPU cycle counter * GetStrongRand*: * Stack pointer (which indirectly identifies thread and some call stack information) * rdrand (if available) * CPU cycle counter * /dev/urandom (or equivalent) * OpenSSL * CPU cycle counter again * From scheduler when idle: * Stack pointer (which indirectly identifies thread and some call stack information) * rdrand (if available) * CPU cycle counter before and after 1ms sleep * Perfmon data (on Windows, once every 10 min) * At startup: * Stack pointer (which indirectly identifies thread and some call stack information) * rdrand (if available) * CPU cycle counter * /dev/urandom (or equivalent) * OpenSSL * CPU cycle counter again * Perfmon data (on Windows, once every 10 min) The interface of random.h is also simplified, and documentation is added. This implements most of #14623. Tree-SHA512: 0120e19bd4ce80a509b5c180a4f29497d299ce8242e25755880851344b825bc2d64a222bc245e659562fb5463fb7c70fbfcf003616be4dc59d0ed6534f93dd20
generated by cgit v1.2.3 (git 2.26.2) at 2024-09-20 17:54:28 +0000