7a91ceb5e [QA] Add RPC based rescan test (Jonas Schnelli)
c77170fbd [Wallet] add rescanblockchain <start_height> <stop_height> RPC command (Jonas Schnelli)
Pull request description:
A RPC rescan command is much more flexible for the following reasons:
* You can define the start and end-height
* It can be called during runtime
* It can work in multiwallet environment
Tree-SHA512: df67177bad6ad1d08e5a621f095564524fa3eb87204c2048ef7265e77013e4b1b29f991708f807002329a507a254f35e79a4ed28a2d18d4b3da7a75d57ce0ea5
CWallet::MarkConflicted may acquire the cs_main lock after
CWalletDB::LoadWallet acquires the cs_wallet lock during wallet initialization.
(CWalletDB::LoadWallet calls ReadKeyValue which calls CWallet::LoadToWallet
which calls CWallet::MarkConflicted). This is the opposite order that cs_main
and cs_wallet locks are acquired in the rest of the code, and so leads to
POTENTIAL DEADLOCK DETECTED errors if bitcoin is built with -DDEBUG_LOCKORDER.
This commit changes CWallet::LoadWallet (which calls CWalletDB::LoadWallet) to
acquire both locks in the standard order. It also fixes some tests that were
acquiring wallet and main locks out of order and failed with the new locking in
CWallet::LoadWallet.
Error was reported by Luke Dashjr <luke-jr@utopios.org> in
https://botbot.me/freenode/bitcoin-core-dev/msg/90244330/
a897d0e tests: Remove OldSetKeyFromPassphrase/OldEncrypt/OldDecrypt (practicalswift)
Pull request description:
Reduces the number of non-free:d allocs with four (Δ in use at exit = -928 bytes).
With this patch applied:
```
$ valgrind --leak-check=full --show-leak-kinds=all src/test/test_bitcoin --log_level=test_suite --run_test=wallet_crypto
…
==20243== HEAP SUMMARY:
==20243== in use at exit: 72,704 bytes in 1 blocks
==20243== total heap usage: 53,138 allocs, 53,137 frees, 49,600,420 bytes allocated
==20243==
==20243== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==20243== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20243== by 0x6AA5EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==20243== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==20243== by 0x40107CA: call_init (dl-init.c:30)
==20243== by 0x40107CA: _dl_init (dl-init.c:120)
==20243== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20243== by 0x2: ???
==20243== by 0xFFF0006A2: ???
==20243== by 0xFFF0006B8: ???
==20243== by 0xFFF0006CF: ???
==20243==
==20243== LEAK SUMMARY:
==20243== definitely lost: 0 bytes in 0 blocks
==20243== indirectly lost: 0 bytes in 0 blocks
==20243== possibly lost: 0 bytes in 0 blocks
==20243== still reachable: 72,704 bytes in 1 blocks
==20243== suppressed: 0 bytes in 0 blocks
```
Without this patch applied:
```
$ valgrind --leak-check=full --show-leak-kinds=all src/test/test_bitcoin --log_level=test_suite --run_test=wallet_crypto
…
==19023== HEAP SUMMARY:
==19023== in use at exit: 73,632 bytes in 5 blocks
==19023== total heap usage: 52,718 allocs, 52,713 frees, 49,502,962 bytes allocated
==19023==
==19023== 24 bytes in 1 blocks are still reachable in loss record 1 of 5
==19023== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19023== by 0x642DE77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E5665: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E7BB3: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E87AD: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E883D: ERR_put_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64EAAE4: EVP_DecryptFinal_ex (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x3AD150: wallet_crypto::OldDecrypt(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, secure_allocator<unsigned char> >&, unsigned char const*, unsigned char const*) (crypto_tests.cpp:81)
==19023== by 0x3AF892: wallet_crypto::TestCrypter::TestDecrypt(CCrypter const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&) (crypto_tests.cpp:137)
==19023== by 0x3AD5E9: wallet_crypto::decrypt::test_method() (crypto_tests.cpp:223)
==19023== by 0x3ADC11: wallet_crypto::decrypt_invoker() (crypto_tests.cpp:216)
==19023== by 0x182596: invoke<void (*)()> (callback.hpp:56)
==19023== by 0x182596: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==19023==
==19023== 128 bytes in 1 blocks are still reachable in loss record 2 of 5
==19023== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19023== by 0x642DE77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E5331: lh_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E7862: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E7B7F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E87AD: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E883D: ERR_put_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64EAAE4: EVP_DecryptFinal_ex (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x3AD150: wallet_crypto::OldDecrypt(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, secure_allocator<unsigned char> >&, unsigned char const*, unsigned char const*) (crypto_tests.cpp:81)
==19023== by 0x3AF892: wallet_crypto::TestCrypter::TestDecrypt(CCrypter const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&) (crypto_tests.cpp:137)
==19023== by 0x3AD5E9: wallet_crypto::decrypt::test_method() (crypto_tests.cpp:223)
==19023== by 0x3ADC11: wallet_crypto::decrypt_invoker() (crypto_tests.cpp:216)
==19023==
==19023== 176 bytes in 1 blocks are still reachable in loss record 3 of 5
==19023== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19023== by 0x642DE77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E530F: lh_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E7862: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E7B7F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E87AD: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E883D: ERR_put_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64EAAE4: EVP_DecryptFinal_ex (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x3AD150: wallet_crypto::OldDecrypt(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, secure_allocator<unsigned char> >&, unsigned char const*, unsigned char const*) (crypto_tests.cpp:81)
==19023== by 0x3AF892: wallet_crypto::TestCrypter::TestDecrypt(CCrypter const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&) (crypto_tests.cpp:137)
==19023== by 0x3AD5E9: wallet_crypto::decrypt::test_method() (crypto_tests.cpp:223)
==19023== by 0x3ADC11: wallet_crypto::decrypt_invoker() (crypto_tests.cpp:216)
==19023==
==19023== 600 bytes in 1 blocks are still reachable in loss record 4 of 5
==19023== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19023== by 0x642DE77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E8745: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64E883D: ERR_put_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x64EAAE4: EVP_DecryptFinal_ex (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==19023== by 0x3AD150: wallet_crypto::OldDecrypt(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, secure_allocator<unsigned char> >&, unsigned char const*, unsigned char const*) (crypto_tests.cpp:81)
==19023== by 0x3AF892: wallet_crypto::TestCrypter::TestDecrypt(CCrypter const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&) (crypto_tests.cpp:137)
==19023== by 0x3AD5E9: wallet_crypto::decrypt::test_method() (crypto_tests.cpp:223)
==19023== by 0x3ADC11: wallet_crypto::decrypt_invoker() (crypto_tests.cpp:216)
==19023== by 0x182596: invoke<void (*)()> (callback.hpp:56)
==19023== by 0x182596: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==19023== by 0x596CCB0: ??? (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==19023== by 0x594C995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==19023==
==19023== 72,704 bytes in 1 blocks are still reachable in loss record 5 of 5
==19023== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19023== by 0x6AA5EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==19023== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==19023== by 0x40107CA: call_init (dl-init.c:30)
==19023== by 0x40107CA: _dl_init (dl-init.c:120)
==19023== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==19023== by 0x2: ???
==19023== by 0xFFF0006A2: ???
==19023== by 0xFFF0006B8: ???
==19023== by 0xFFF0006CF: ???
==19023==
==19023== LEAK SUMMARY:
==19023== definitely lost: 0 bytes in 0 blocks
==19023== indirectly lost: 0 bytes in 0 blocks
==19023== possibly lost: 0 bytes in 0 blocks
==19023== still reachable: 73,632 bytes in 5 blocks
==19023== suppressed: 0 bytes in 0 blocks
==19023==
==19023== For counts of detected and suppressed errors, rerun with: -v
==19023== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
Tree-SHA512: 38b6552736a5710a42dbad770c490583cfc762acbec716f5db4cf38314f494ea99430713ea407c73b49d867676ced221a282437f3fcfd8346f8f68386f4fc74d
065039d [tests] Fix incorrect memory_cleanse(…) call in crypto_tests.cpp (practicalswift)
Pull request description:
`chKey` and `chIV` are pointers, not arrays :-)
Probably the result of copy-pasting of old code where the code was operating on arrays instead of pointers.
If I'm reading the code correctly the absence/presence of these `memory_cleanse(…)` calls won't alter the outcome of the test in question (`TestPassphraseSingle`) even if fixed. Therefore removing.
Tree-SHA512: a053b2817bedf6ef889744e546ce9a0f165dee94aef6850d9d6a6bb05b0018789597371ecf154a4aec8588c0ef5626ef08c23c35e35927f6b0497b5f086146fe
This assures that we don't overwrite a random file called
`wallet.backup` that happens to be in the current directory. It also
assures that the temporary file will be cleaned up.
Noticed by Evan Klitzke, came up in discussion here:
https://github.com/bitcoin/bitcoin/pull/10880#discussion_r128460722
c237bd7 wallet: Update formatting (Luke Dashjr)
9cbe8c8 wallet: Forbid -salvagewallet, -zapwallettxes, and -upgradewallet with multiple wallets (Luke Dashjr)
a2a5f3f wallet: Base backup filenames on original wallet filename (Luke Dashjr)
b823a4c wallet: Include actual backup filename in recovery warning message (Luke Dashjr)
84dcb45 Bugfix: wallet: Fix warningStr, errorStr argument order (Luke Dashjr)
008c360 Wallet: Move multiwallet sanity checks to CWallet::Verify, and do other checks on all wallets (Luke Dashjr)
0f08575 Wallet: Support loading multiple wallets if -wallet used more than once (Luke Dashjr)
b124cf0 Wallet: Replace pwalletMain with a vector of wallet pointers (Luke Dashjr)
19b3648 CWalletDB: Store the update counter per wallet (Luke Dashjr)
74e8738 Bugfix: ForceSetArg should replace entr(ies) in mapMultiArgs, not append (Luke Dashjr)
23fb9ad wallet: Move nAccountingEntryNumber from static/global to CWallet (Luke Dashjr)
9d15d55 Bugfix: wallet: Increment "update counter" when modifying account stuff (Luke Dashjr)
f28eb80 Bugfix: wallet: Increment "update counter" only after actually making the applicable db changes to avoid potential races (Luke Dashjr)
Tree-SHA512: 23f5dda58477307bc07997010740f1dc729164cdddefd2f9a2c9c7a877111eb1516d3e2ad4f9b104621f0b7f17369c69fcef13d28b85cb6c01d35f09a8845f23
Start importwallet rescans at the first block with timestamp greater or equal
to the wallet birthday instead of the last block with timestamp less or equal.
This fixes an edge case bug where importwallet could fail to start the rescan
early enough if there are blocks with decreasing timestamps or multiple blocks
with the same timestamp.
An off-by-one-block bug in importmulti rescan logic could cause it to return
success in an edge case even when a rescan was not successful. The case where
this would happen is if there were multiple blocks in a row with the same
GetBlockTimeMax() value, and the last block was scanned successfully, but one
or more of the earlier blocks was not readable.
Abstract database handle from explicit strFilename into
CWalletDBWrapper.
Also move CWallet::Backup to db.cpp - as it deals with representation
details this is a database specific operation.
Change ScanForWalletTransactions return value so it is possible to distinguish
scans that skip reading every block (due to the nTimeFirstKey optimization)
from scans that fail while reading the chainActive.Tip() block. Return value is
now non-null in the non-failing case.
This change doesn't affect any user-visible behavior, it is only an internal
API improvement. The only code currently using the ScanForWalletTransactions
return value is in importmulti, and importmulti always calls
ScanForWalletTransactions with a pindex pointing to the first block in
chainActive whose block time is >= (nLowestTimestamp - 7200), while
ScanForWalletTransactions would only return null without reading blocks when
pindex and every block after it had a block time < (nTimeFirstKey - 7200).
These conditions could never happen at the same time because nTimeFirstKey <=
nLowestTimestamp.
I'm planning to make a more substantial API improvement in the future (making
ScanForWalletTransactions private and exposing a higher level rescan method to
RPC code), but Matt Corallo <git@bluematt.me> pointed out this odd behavior
introduced by e2e2f4c "Return errors from importmulti if complete rescans are
not successful" yesterday, so I'm following up now to get rid of badness
introduced by that merge.
Warnings introduced by commit e2e2f4c "Return errors from importmulti if
complete rescans are not successful" and reported by Pavel Janík
<Pavel@Janik.cz> in https://github.com/bitcoin/bitcoin/pull/9773 and
https://github.com/bitcoin/bitcoin/pull/9827
wallet/test/wallet_tests.cpp: In member function ‘void wallet_tests::rescan::test_method()’:
wallet/test/wallet_tests.cpp:377:17: warning: declaration of ‘wallet’ shadows a global declaration [-Wshadow]
CWallet wallet;
cee1612 reduce number of lookups in TransactionWithinChainLimit (Gregory Sanders)
af9bedb Test for fix of txn chaining in wallet (Gregory Sanders)
5882c09 CreateTransaction: Don't return success with too-many-ancestor txn (Gregory Sanders)
0b2294a SelectCoinsMinConf: Prefer coins with fewer ancestors (Gregory Sanders)
Change CCrypter to use vectors with secure allocator instead of buffers
on in the object itself which will end up on the stack. This avoids
having to call LockedPageManager to lock stack memory pages to prevent the
memory from being swapped to disk. This is wasteful.
There are only a few uses of `insecure_random` outside the tests.
This PR replaces uses of insecure_random (and its accompanying global
state) in the core code with an FastRandomContext that is automatically
seeded on creation.
This is meant to be used for inner loops. The FastRandomContext
can be in the outer scope, or the class itself, then rand32() is used
inside the loop. Useful e.g. for pushing addresses in CNode or the fee
rounding, or randomization for coin selection.
As a context is created per purpose, thus it gets rid of
cross-thread unprotected shared usage of a single set of globals, this
should also get rid of the potential race conditions.
- I'd say TxMempool::check is not called enough to warrant using a special
fast random context, this is switched to GetRand() (open for
discussion...)
- The use of `insecure_rand` in ConnectThroughProxy has been replaced by
an atomic integer counter. The only goal here is to have a different
credentials pair for each connection to go on a different Tor circuit,
it does not need to be random nor unpredictable.
- To avoid having a FastRandomContext on every CNode, the context is
passed into PushAddress as appropriate.
There remains an insecure_random for test usage in `test_random.h`.
This reverts PR #4906, "Coinselection prunes extraneous inputs from
ApproximateBestSubset".
Apparently the previous behavior of slightly over-estimating the set of
inputs was useful in cleaning up UTXOs.
See also #7664, #7657, as well as 2016-07-01 discussion on #bitcoin-core-dev IRC.
Verify that results correct (match known values), consistent (encrypt->decrypt
matches the original), and compatible with the previous openssl implementation.
Also check that failed encrypts/decrypts fail the exact same way as openssl.
* Introduce new constant MIN_CHANGE and use it instead of the
hardcoded "CENT"
* Add test case for MIN_CHANGE
* Introduce new constant for -mintxfee default:
DEFAULT_TRANSACTION_MINFEE = 1000
