f30e9be4c1 RPC Docs: gettxout*: clarify bestblock and unspent counts (David A. Harding)
Pull request description:
Expounds on two things I've seen confuse inexperienced users:
- transactions/outputs in `gettxoutsetinfo`: a user thought this was the total number of transactions or outputs ever seen on the chain, whereas it's only the number in the UTXO.
- bestblock in `gettxout`: a user thought this was the block that included the output, not realizing it was the tip of the current best block chain. I also copied this text to `gettxoutsetinfo` for congruency. I skimmed other uses of "bestblock" in the RPC docs and they seemed clear to me.
Tree-SHA512: c2161c497bef5fe15ee9f1e2a4413fa099b5baa36205ba1ba4b3822885b3ccd1badb9c118a0334f47ba6fa7fff5818ac359cfac6a1108c6847a876b1a251bb7c
Introduced in 4e0eed88ac
When an invalid block is found during a reorg, we know the last of the blocks in
the was-to-be-connected chain is invalid, but not necessarily the first. As
vpIndexToConnect is ordered in decreasing height, the end of the reorg is the
front of the vector, and not the back.
This only affected the warning system.
ab3f4dd tests: Add test for 64-bit PE, modify 32-bit test results (Chun Kuan Lee)
Pull request description:
9a75d29b6f change the error result from `PIE` to `DYNAMIC_BASE`. And there are no test for 64-bit, so I made one
Tree-SHA512: 9d5643dadf4d9fc34ea32d94655bfb98eec2f7bc2820b4b0f525d5acf1cd22f3acf38bf8904dda4f50fd9ca5a5e56d566a392e6f804eea6e50e03cba40048621
16be13345 Fix rescanblockchain rpc to property report progress (Ben Woosley)
Pull request description:
Previously it assumed tip in all cases. This also extracts a RescanVerificationProgress helper object whose role is to manage reporting, in order to simplify ScanForWalletTransactions - more lines in total, but much simpler to follow the core logic.
Tree-SHA512: 5ebed0c56fae4ccfe613ff1d7082cb6da5a86635a8993ed3af70b500a4ea43074121aea9219b2f0321fbfeb7efcb964bdc2199297a64ca0fa85d9d07aa637d40
ddebde7 Add Windows shutdown handler (Chun Kuan Lee)
Pull request description:
Exit properly when clicked the red X of Windows Console
Tree-SHA512: f030edd08868390662b42abfa1dc6bd702166c6c19f5b1f8e7482e202451e79fb6f37ea672c26c2eb0d32c367bfca86160fbee624696c53828f280b7070be6a0
20ce5af Print a log message if we fail to shrink the debug log file (practicalswift)
29c9bdc Handle unsuccessful fseek(...):s (practicalswift)
Pull request description:
Handle unsuccessful `fseek(...)`:s.
**Note to reviewers:** What is the most appropriate course of actions for each of these unsuccessful `fseek(...)`:s?
Tree-SHA512: 5b3d82dbdd15d434d3f08dcb4df62888da4df8541d2586f56a4e529083005f6782c39e10645acd1ec403da83061bbfd8dbf2dddc66e09268d410ad0918c61876
43f3dec00 Remove enum specifier (to avoid re-declare scoped enum as unscoped) (donaloconnor)
Pull request description:
MSVC fails to compile with the changes made in #10742
The problem is enum types were changed to scoped (`enum class`) but in some places `enum` as an unscoped is used.
This is a very simple fix and I've tested it.
Edit: Had to remove enum altogether - `enum class` doesn't compile on clang.
Tree-SHA512: 13e21666243585a133c74c81249a1fa4098d6b7aa3cda06be871fa017c0ad9bb7b0725f801160b9d31678448d668718197941fd84702ebdef15128c27d92cd70
fad63eb [logging] Don't incorrectly log that REJECT messages are unknown. (John Newbery)
Pull request description:
Reject messages are logged to debug.log if NET debug logging is enabled.
Because of the way the `ProcessMessages()` function is structured,
processing for REJECT messages will also drop through to the default
branch and incorrectly log `Unknown command "reject" from peer-?`. Fix
that by exiting from `ProcessMessages()` early.
without this PR:
```
2018-05-03T17:37:00.930600Z received: reject (21 bytes) peer=0
2018-05-03T17:37:00.930620Z Reject message code 16: spammy spam
2018-05-03T17:37:00.930656Z Unknown command "reject" from peer=0
```
with this PR:
```
2018-05-03T17:35:04.751246Z received: reject (21 bytes) peer=0
2018-05-03T17:35:04.751274Z Reject message code 16: spammy spam
```
Tree-SHA512: 5c84c98433ab99e0db2dd481f9c2db6f87ff0d39022ff317a791737e918714bbcb4a23e81118212ed8e594ebcf098ab7f52f7fd5e21ebc3f07b1efb279b9b30b
Replaces the slow modulo operation with a much faster 32bit multiplication & shift. This works
because the hash should be uniformly distributed between 0 and 2^32-1. This speeds up the benchmark
by a factor of about 1.3:
RollingBloom, 5, 1500000, 3.73733, 4.97569e-07, 4.99002e-07, 4.98372e-07 # before
RollingBloom, 5, 1500000, 2.86842, 3.81630e-07, 3.83730e-07, 3.82473e-07 # FastMod
Be aware that this changes the position of the bits that are toggled, so this should probably
not be used for CBloomFilter which is serialized.
cbba1d2da4 Add compile time checking for all ::mempool.cs runtime locking assertions (practicalswift)
Pull request description:
Add compile time checking for `::mempool.cs` runtime locking assertions.
This PR is a subset of #12665. The PR was broken up to make reviewing easier.
The intention is that literally all `EXCLUSIVE_LOCKS_REQUIRED`/`LOCKS_EXCLUDED`:s added in this PR should follow either directly or indirectly from `AssertLockHeld(…)`/`AssertLockNotHeld(…)`:s already existing in the repo.
Consider the case where function `A(…)` contains `AssertLockHeld(cs_foo)` (without
first locking `cs_foo` in `A`), and that `B(…)` calls `A(…)` (without first locking `cs_main`):
* It _directly_ follows that: `A(…)` should have an `EXCLUSIVE_LOCKS_REQUIRED(cs_foo)` annotation.
* It _indirectly_ follows that: `B(…)` should have an `EXCLUSIVE_LOCKS_REQUIRED(cs_foo)` annotation.
Tree-SHA512: 1b5ec1cfca6be67edd1298fea1a52b5572ce833dd4ad05c4583f753c2d3229402663373675df87e950151d5c41aeb3ee02f0ad935ed83fe2f45ca8e4d55d901e
c3f34d06be Make it clear which functions that are intended to be translation unit local (practicalswift)
Pull request description:
Make it clear which functions that are intended to be translation unit local.
Do not share functions that are meant to be translation unit local with other translation units. Use internal linkage for those consistently.
Tree-SHA512: 05eebd233d5cfbf6116724eec3a99b465bf534ca220f2b6f5e56341a7da41387454d3cb6ceadd8ab6714a5df94069e4ad0dcab8801ccc7e8949be7199a19fb53
A transaction with 1 segwit input and 1 P2WPHK output has non-witness size of 82 bytes. Anything smaller than this have unnecessary malloc overhead and are not relayed/mined.
This disables OP_CODESEPARATOR in non-segwit scripts (even in an unexecuted branch), and makes a positive FindAndDelete result invalid. This ensures that the scriptCode serialized in SignatureHash() is always the same as the script passing to the EvalScript.
a508091c59 doc: Mention good first issue list in CONTRIBUTING.md (fanquake)
Pull request description:
Tree-SHA512: a954cda62d6dc8ab78809565be392a1c9f55c543e8d5c1a5a8588c0062e1a11bd4968991646e4aa5bd9b9761b1765fde4ceab8fea7a973148122ff249d728b92
Reject messages are logged to debug.log if NET debug logging is enabled.
Because of the way the `ProcessMessages()` function is structured,
processing for REJECT messages will also drop through to the default
branch and incorrectly log `Unknown command "reject" from peer-?`. Fix
that by exiting from `ProcessMessages()` early.
without this PR:
```
2018-05-03T17:37:00.930600Z received: reject (21 bytes) peer=0
2018-05-03T17:37:00.930620Z Reject message code 16: spammy spam
2018-05-03T17:37:00.930656Z Unknown command "reject" from peer=0
```
with this PR:
```
2018-05-03T17:35:04.751246Z received: reject (21 bytes) peer=0
2018-05-03T17:35:04.751274Z Reject message code 16: spammy spam
```
CWallet::ScanForWalletTransactions did not previously take into account
pindexStop when calculating progress.
Renamed progress vars to progress_*.
rescanblockchain is the only rpc that uses this parameter.
According to the BerkeleyDB docs, the DbEnv handle may not be accessed
after close() has been called. This change ensures that we create a new
handle after close() is called. This avoids a segfault when the first
connection attempt fails and then a second connection attempt tries to
call open() on the already closed DbEnv handle.
a59dac3 refactor: Avoid extra lookups of mapAddressBook in listunspent RPC (João Barbosa)
d76962e rpc: Reduce cs_main lock in listunspent (João Barbosa)
Pull request description:
On my system, where the wallet has 10000 unspents, the `cs_main` lock duration changed from 191ms to 36ms. The loop that generates the response takes around 155ms. So, the lock duration is reduced to around 20%.
Tree-SHA512: ddaae591f39da59a9d1a8e9ffe773d857687789476f566ca273d310ad531da6dacff80cac69f3334c601c251ac7c5ed4136656c725aa3d611c6bbf734111946e
1e46d8a Get rid of ambiguous OutputType::NONE value (Russell Yanofsky)
Pull request description:
Based on suggestion by @sipa https://github.com/bitcoin/bitcoin/pull/12119#issuecomment-357982763
After #12119, the NONE output type was overloaded to refer to either an output type that couldn't be parsed, or to an automatic change output mode. This change drops the NONE enum and uses a simple bool to indicate parse failure, and a new CHANGE_AUTO enum to refer the change output type.
This change is almost a pure refactoring except it makes RPCs reject empty string ("") address types instead of treating them like they were unset. This simplifies the parsing code a little bit and could prevent RPC usage mistakes. It's noted in the release notes.
Follows up #12408 by @MarcoFalke
Followups for future PRs:
- [ ] Add explicit support for specifying "auto" in `ParseOutputType` as suggested by promag and sipa: https://github.com/bitcoin/bitcoin/pull/12729#issuecomment-374799567 and https://github.com/bitcoin/bitcoin/pull/12729#discussion_r175969481
- [ ] Add wallet `AddressChangeType` method to complement `TransactionChangeType`: https://github.com/bitcoin/bitcoin/pull/12729#discussion_r175969618.
Tree-SHA512: 8b08b272bcb177a0a9e556dcd965840a7fe601ef83ca97938b879c9b1a33b5b3f96939e1bceef11ba7c644ac21bfd6c1dbc6ca715cd1da4ace50475240e4ee48
