d3a56be77a9d112cde4baef4314882170b9f228f Revert "gui: Avoid Wallet::GetBalance in WalletModel::pollBalanceChanged" (Russell Yanofsky)
bf0a510981ddc28c754881ca21c50ab18e5f2b59 gui: Avoid wallet tryGetBalances calls before TransactionChanged or BlockTip notifications (Russell Yanofsky)
2bc9b92ed8b7736ad67876398a0bb8287f57e9b3 Cancel wallet balance timer when shutdown requested (Russell Yanofsky)
83f69fab3a1ae97c5cff8ba1e6fd191b0fa264bb Switch transaction table to use wallet height not node height (Russell Yanofsky)
Pull request description:
Main commit `gui: Avoid wallet tryGetBalances calls` is one-line change to `WalletModel::pollBalanceChanged` that returns early if there hasn't been a new `TransactionChanged` or `BlockTip` notification since the previous poll call. This is the same behavior that was implemented in #18160, now implemented in a simpler way.
The other commits are a straight revert of #18160, and two tweaks to avoid relying on `WalletModel::m_client_model` lifetime which were causing travis failures with earlier versions of this PR.
Motivation for this change is to be able to revert #18160 and cut down on unnecessary cross-process calls that happen when #18160 is combined with #10102
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/projects/10).# This is a combination of 2 commits.
0933a37078e1ce3a3d70983c3e7f4b3ac6c3fa37 gui: Avoid Wallet::GetBalance in WalletModel::pollBalanceChanged (João Barbosa)
Pull request description:
Each 250ms the slot `WalletModel::pollBalanceChanged` is called which, at worst case, calls `Wallet::GetBalance`. This is a waste of resources since most of the time there aren't new transactions or new blocks. Fix this by early checking if cache is dirty or not.
The actual balance computation can still hang the GUI thread but that is tracked in #16874 and should be fixed with a solution similar to #17135.
ACKs for top commit:
hebasto:
ACK 0933a37078e1ce3a3d70983c3e7f4b3ac6c3fa37, I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged.
jonasschnelli:
utACK 0933a37078e1ce3a3d70983c3e7f4b3ac6c3fa37
instagibbs:
ACK 0933a37078e1ce3a3d70983c3e7f4b3ac6c3fa37
ryanofsky:
Code review ACK 0933a37078e1ce3a3d70983c3e7f4b3ac6c3fa37, but I would prefer (not strongly) for #17905 to be merged first. This PR can be simpler if it is based on #17905, so tryGetBalances can just be left alone instead of changing into to a more complicated tryGetBalancesIfNeeded function, and then getting changed back later when we want to optimize it out.
jonatack:
ACK 0933a37078e based primarily on code review, despite a lot of manual testing with a large 177MB wallet.
Tree-SHA512: 18db35bf33a7577666658c8cb0b57308c8474baa5ea95bf1468cd8531a69857d8915584f6ac505874717aa6aabeb1b506ac77630f8acdb6651afab89275e38a1
It's highly unlikely the test will ever deal with chains with >4500
blocks, so only the subset of the subsidy logic that is needed to
validate `gettxoutsetinfo` output has been included
Dash uses the height and difficulty of the previous block to calculate
the subsidy for the current block... which in the case of the genesis
block is block -1, which doesn't exist.
Attempting in reading `pprev` which is will evaluate to a `nullptr`, so
for any blocks <=0, we fetch the subsidy expected from block 0 from
CChainParams.
## Issue being fixed or feature implemented
There's one type of output that potentially can be useful for bloom
filter.
It's follow-up for TODO for dashpay/dash#4857.
Asset Lock transactions have:
- standard inputs (covered by regular bloom filter implementation)
- standard outputs (covered by regular bloom filter implementation)
- special outputs that have public key to proof owing this credits on
platform and claiming it.
Asset Unlock transactions have:
- no inputs (no need bloom)
- standard outputs (covered by regular bloom filter implementation)
So far as there's only one special case, let's have this data in the
bloom filter because it can potentially help to show information such as
"Deposit to platform" on mobile clients.
## What was done?
- added special case for Asset Lock transactions for bloom filter
## How Has This Been Tested?
Run unit/functional tests. Doesn't actually tested how bloom filter
works.
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
1816327e533d359c237c53eb6440b2f3a7cbf4fa p2p: Put disconnecting logs into BCLog::NET category (Hennadii Stepanov)
Pull request description:
It's too noisy:
```
$ cat debug.log | wc -l
28529
$ cat debug.log | grep "Disconnecting and discouraging peer" | wc -l
10177
```
ACKs for top commit:
MarcoFalke:
noban, addnode and local peers are still unconditionally logged (as they should), but this one can go into a category, so cr-ACK 1816327e533d359c237c53eb6440b2f3a7cbf4fa
practicalswift:
ACK 1816327e533d359c237c53eb6440b2f3a7cbf4fa for the reasons MarcoFalke gave above.
ajtowns:
ACK 1816327e533d359c237c53eb6440b2f3a7cbf4fa
Tree-SHA512: c312c1009090840659b2cb1364d8ad9b6ab8e742fc462aef169996d93c76c248507639a00257ed9d73a6916c01176b1793491b2305e92fdded5f9de0935b6ba6
fac7ab1d5b58fb9cfd80d5cf74ac4d2e5cb8eff2 refactor: Use C++17 std::array where possible (MarcoFalke)
Pull request description:
Using the C++11 std::array with explicit template parameters is problematic because overshooting the size will fill the memory with default constructed types.
For example,
```cpp
#include <array>
#include <iostream>
int main()
{
std::array<int, 3> a{1, 2};
for (const auto& i : a) {
std::cout << i << std::endl; // prints "1 2 0"
}
}
```
ACKs for top commit:
jonasschnelli:
Code Review ACK fac7ab1d5b58fb9cfd80d5cf74ac4d2e5cb8eff2
practicalswift:
cr ACK fac7ab1d5b58fb9cfd80d5cf74ac4d2e5cb8eff2
vasild:
ACK fac7ab1d
promag:
Code review ACK fac7ab1d5b58fb9cfd80d5cf74ac4d2e5cb8eff2.
Tree-SHA512: ef7e872340226e0d6160e6fd66c6ca78b2ef9c245fa0ab27fe4777aac9fba8d5aaa154da3d27b65dec39a6a63d07f1063c3a8ffb667a98ab137756a1a0af2656
cadb77a6ab8a3e6f56062cfaec4dd8168c71b39d net: Add compat.h header for htonl function (Hennadii Stepanov)
f796f0057bc7dad8e7065831b07f432fc0fb9f08 net: Drop unneeded headers when compat.h included (Hennadii Stepanov)
467c34644861a5267601255650e27c7aadab31dc net: Drop unneeded Windows headers in compat.h (Hennadii Stepanov)
Pull request description:
It is the `compat.h` header's job to provide platform-agnostic interfaces for internet operations.
No need in `#include <arpa/inet.h>` scattered around.
ACKs for top commit:
practicalswift:
re-ACK cadb77a6ab8a3e6f56062cfaec4dd8168c71b39d: patch looks even better
laanwj:
Code review ACK cadb77a6ab8a3e6f56062cfaec4dd8168c71b39d
Tree-SHA512: 625ff90b2806310ab856a6ca1ddb6d9a85aa70f342b323e8525a711dd12219a1ecec8373ec1dca5a0653ffb11f9b421753887b25615d991ba3132c1cca6a3c6e
1e62350ca20898189904a88dfef9ea11ddcd8626 refactor: Improve use of explicit keyword (Fabian Jahr)
c502a6dbfb854ca827a5a3925394f9e09d29b898 lint: Use c++17 std in cppcheck linter (Fabian Jahr)
Pull request description:
I found the `extended-lint-cppcheck` linter still uses `std=c++11` when reviewing #20471. The only difference in the output after this change is one line is missing:
```
src/script/descriptor.cpp:159:5: warning: Struct 'PubkeyProvider' has a constructor with 1 argument that is not explicit. [noExplicitConstructor]
```
After some digging, I am still not sure why this one is ignored with c++17 when 40 other`noExplicitConstructor` warnings were still appearing.
In the second commit, I fix these warnings, adding `explicit` where appropriate and adding fixes to ignore otherwise.
ACKs for top commit:
practicalswift:
cr ACK 1e62350ca20898189904a88dfef9ea11ddcd8626: patch looks correct!
MarcoFalke:
review ACK 1e62350ca20898189904a88dfef9ea11ddcd8626
Tree-SHA512: dff7b324429a57160e217cf38d9ddbb6e70c6cb3d3e3e0bd4013d88e07afc2292c3df94d0acf7122e9d486322821682ecf15c8f2724a78667764c05d47f89a12
fa40168ab3102b9ad850f967a0e7fa22dbfbd0c6 Remove unused bits from service flags enum (MarcoFalke)
Pull request description:
Remove service bits that haven't been observed on the active network for years and won't ever be observed on the network with this meaning. Keeping this dead assignment in our source code forever doesn't add any value.
I somehow forgot to do this in commit fa0d0ff6e1bee60fde63724ae28a51aac5a94d4a.
ACKs for top commit:
laanwj:
Code review ACK fa40168ab3102b9ad850f967a0e7fa22dbfbd0c6
practicalswift:
cr ACK fa40168ab3102b9ad850f967a0e7fa22dbfbd0c6
fanquake:
ACK fa40168ab3102b9ad850f967a0e7fa22dbfbd0c6
Tree-SHA512: 376e5ac05940493cf2209fea60515c843e978c4b476f2524f6bf7a37a646d237c3ddcf6c0fa23641f9ba550f625609703d9b51b4be631a7f2a90e1092b557232
fa8abdc9953e381715493b259908e246914793b0 rpc: Use FeeModes doc helper in estimatesmartfee (MarcoFalke)
Pull request description:
Not sure why this doesn't use the doc helper, probably an oversight?
ACKs for top commit:
laanwj:
Code review ACK fa8abdc9953e381715493b259908e246914793b0
Tree-SHA512: 1f2dc8356e3476ddcf9cafafa7f9865ad95bed1e3067c0edab8e3c483e374bdbdbecc066167554b4a1b479e28f6a52c4ae6a75a70c67ee4e1ff4f3ba36b04001
6690adba08006739da0060eb4937126bdfa1181a Warn when binaries are built from a dirty branch. (Tyler Chambers)
Pull request description:
- Adjusted `--version` flag behavior in bitcoind and bitcoin-wallet to have the same behavior.
- Added `--version` flag to bitcoin-tx to match.
- Added functionality in gen-manpages.sh to error when attempting to generate man pages for binaries built from a dirty branch.
mitigates problem with issue #20412
ACKs for top commit:
laanwj:
Tested ACK 6690adba08006739da0060eb4937126bdfa1181a
Tree-SHA512: b5ca509f1a57f66808c2bebc4b710ca00c6fec7b5ebd7eef58018e28e716f5f2358e36551b8a4df571bf3204baed565a297aeefb93990e7a99add502b97ee1b8
## Issue being fixed or feature implemented
Issues with rebasing non-conflicting pull requests on top of the updated
target branch:
1. It's ~impossible~ _annoying_ to run `gfd` _on each rebase_ to verify
that it was indeed a clean rebase ~if you did not pull the
original/previous version~ (it is possible actually, must use full
commit hash)
2. Github GUI is pretty much useless if a target branch update was huge
Because of (1) and (2) if a rebase was done in the middle of your review
you have to basically start your review from scratch which is super
annoying and should be avoided. Rebasing a conflicting PR or rebasing on
top of the same `HEAD` as before is ok.
cc @kittywhiskers @vijaydasmp @knst
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
40% smaller CI job artifacts. Should help with issues like
https://gitlab.com/dashpay/dash/-/jobs/4759700026 in #5493.
## What was done?
## How Has This Been Tested?
https://gitlab.com/UdjinM6/dash/-/jobs/4773517599
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
Used to avoid the following error:
```
In file included from test/fuzz/addition_overflow.cpp:7:
In file included from ./test/fuzz/util.h:26:
In file included from ./test/util/setup_common.h:16:
In file included from ./txmempool.h:31:
In file included from /builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/optional.hpp:15:
In file included from /builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/optional/optional.hpp:47:
In file included from /builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/type_traits/is_nothrow_move_assignable.hpp:16:
/builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/type_traits/has_nothrow_assign.hpp:65:7: error: builtin __has_nothrow_assign is deprecated; use __is_nothrow_assignable instead [-Werror,-Wdeprecated-builtins]
BOOST_HAS_NOTHROW_ASSIGN(T)
^
/builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/type_traits/intrinsics.hpp:205:43: note: expanded from macro 'BOOST_HAS_NOTHROW_ASSIGN'
^
/builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/serialization/serialization.hpp:61:1: note: in instantiation of template class 'boost::has_nothrow_assign<unsigned int>' requested here
BOOST_STRONG_TYPEDEF(unsigned int, version_type)
^
/builds/dashpay/dash/depends/x86_64-pc-linux-gnu/include/boost/serialization/strong_typedef.hpp:42:57: note: expanded from macro 'BOOST_STRONG_TYPEDEF'
D& operator=(const D& rhs) BOOST_NOEXCEPT_IF(boost::has_nothrow_assign<T>::value) {t = rhs.t; return *this;} \
```
clang warnings are quite noisy and easily cause gitlab's logs
to spill over, preventing logging of dash-specific warnings and errors
from making it to the CI logs.
our dependencies mostly track upstream so regardless, we cannot
act upon those warnings, so it's better to just suppress them if they're
too noisy.
## Issue being fixed or feature implemented
Since v19, Evo nodes are paid 4x blocks in a row.
This needs to be reverted when MN Reward Reallocation activates.
## What was done?
Starting from MN Reward Reallocation activation, Evo nodes are paid one
block in a row (like regular masternodes).
In addition, `nConsecutivePayments` isn't incremented anymore for Evo
nodes.
## How Has This Been Tested?
`feature_llmq_hpmn.py` with MN Reward Reallocation activation.
## Breaking Changes
no
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
---------
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
## Issue being fixed or feature implemented
It partially resolves issue https://github.com/dashpay/dash/issues/5471
Better unit tests are needed to validate changes in ProTx implementation
such as this PR: https://github.com/dashpay/dash/pull/5463
## What was done?
- Invalid ProTx transactions are checked more strictly. The flag "tx is
failed" is not enough now for test to succeed, but error code should
matched with expected error.
- Duplicated implementations of tests for "valid" and "invalid
transaction" are changed to more general code.
- Added extra log output with tx ID for easier debug - to see which
exactly tx is failed in test
- Supported more by 256 txes in one json file
## How Has This Been Tested?
Run unit tests
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
