## Issue being fixed or feature implemented
TL;DR: Should hopefully fix crashes like
https://gitlab.com/dashpay/dash/-/jobs/4522256293
In dashd we flush all callbacks first and then destroy `g_txindex`. In
tests we had to move `g_txindex` to `TestChainSetup` and its dtor is
executed first, so the order is broken. It also explains why this crash
happens so rare. In most cases tx index is up to date and you need some
kind of a hiccup for scheduler to lag behind a bit. Basically, between
`g_txindex.reset()` and `FlushBackgroundCallbacks`
`BaseIndex::BlockConnected` finally arrives. But it’s processed on a
(now) null instance hence a crash. If it’s earlier - it’s processed
normally, if it’s later - it’s flushed without execution, so there is a
tiny window to catch this crash.
## What was done?
Give tx index a bit of time to process everything
## How Has This Been Tested?
run tests (but this crash is rare 🤷♂️ )
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
It's super slow for wallets with 100.000s of txes to process lots of
notifications produced by rescan. Skip them all and simply refresh the
whole wallet instead. In my case (500k+ txes testnet wallet) gui update
after `rescanblockchain` time is down from _forever_ to ~30 seconds.
Same for `wipewallettxes true` (#5451 ). Gui update after
`wipewallettxes`/`wipewallettxes false` is instant (cause there are no
txes anymore) vs _forever_ before the patch.
## What was done?
refresh the whole wallet when notification queue is above 10K operations
actual changes (ignoring whitespaces):
d013cb4f5c
## How Has This Been Tested?
running on top of #5451 and #5452 , wiping and rescanning w/ and w/out
this patch.
## Breaking Changes
should be none
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
It's super slow for wallets with 100.000s of keys and txes to reindex
and to rescan. Batching multiple operations fixes it. In my case (300K+
keys and 500k+ txes testnet wallet) `rescanblockchain` time is down from
6+ hours to ~10 minutes.
Re-calculating `block_time` over and over again inside of the loop in
`AddToWalletIfInvolvingMe` is wasteful, move it out.
## What was done?
batch what's possible, optimize `AddToWalletIfInvolvingMe`
## How Has This Been Tested?
running on top of #5451 , wiping and rescanning w/ and w/out this patch.
## Breaking Changes
should be none
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Given the hard fork that happened on testnet, there is now lots of the
transactions that were made on the fork that is no longer valid. Some
transactions could be relayed and mined again but some like coinjoin
mixing won't be relayed because of 0 fee and transactions spending
coinbases from the forked branch are no longer valid at all.
## What was done?
Introduce `wipewallettxes` RPC and `wipetxes` command for `dash-wallet`
tool to be able to get rid of some/all txes in the wallet.
## How Has This Been Tested?
run tests, use rpc/command on testnet wallet
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Version field should always be the first field of a message for better
readibility.
## What was done?
- Introduced new protocol version `MNLISTDIFF_VERSION_ORDER` (`70229`).
- `nVersion` serialisation order is changed for clients with protocol
version greater than or equal to `70229`.
- For clients with protocol version >= `70225` and < `70229` the old
order is used: can be deprecated in the future.
- Increased functional test P2P mininode's protocol version to `70229`.
## How Has This Been Tested?
`feature_llmq_rotation.py` with new protocol version.
## Breaking Changes
## 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)_
## Issue being fixed or feature implemented
Added the filter `hpmn` for both `masternodelist` and `protx list` rpcs.
## What was done?
## How Has This Been Tested?
Calling this RPC on Testnet.
## Breaking Changes
## 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
- [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)_
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
## Issue being fixed or feature implemented
Disabled or non-enforced Chainlocks does not mean you can safely mine
non-locked txes, you could end up mining a block that is going to be
rejected by everyone else if a conflicting tx (missing on your node)
would be IS-locked. I can't find any reason why we have this besides "if
Chainlocks are disabled then smth is wrong so let them all be mined" but
we have spork_2 and spork_3 to control IS behaviour and we check them in
`IsTxSafeForMining` already, that would be a much more straightforward
way to deal with a potential issue.
Noticed this while reviewing #5150 and also while testing v19.2 during
recent testnet v19 re-fork.
## What was done?
Drop this check, adjust tests
## How Has This Been Tested?
Run tests locally
## Breaking Changes
Not quote breaking changes but a change in behaviour: with CLs disabled
it will now take 10 minutes for non-locked txes to be mined, same as
when CLs are enabled.
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
@ogabrielides @kittywhiskers I somehow failed to add you guys to the
list of v19.2 contributors 🙈 sorry!
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Mining blocks with a specific version can be useful on testnet and
devnets too
## What was done?
lift restrictions for `-blockversion`
## How Has This Been Tested?
it should just work :)
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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 _(for repository
code-owners and collaborators only)_
bump chainparams to some post failed-v19-fork block on mainnet and post
recent-v19-fork block on testnet
- [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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
fix a couple of issues in help texts
develop:
```
protx register "collateralHash" collateralIndex "ipAndPort" "ownerAddress" "operatorPubKey_register" "votingAddress_register" "operatorReward" "payoutAddress_register" ( "feeSourceAddress" submit )
...
3. ipAndPort (string, required) IP and port in the form "IP:PORT".
Must be unique on the network. Can be set to 0, which will require a ProUpServTx afterwards.
...
5. operatorPubKey_register (string, required) The operator BLS public key. The BLS private key does not have to be known.
It has to match the BLS private key which is later used when operating the masternode.
6. votingAddress_register (string, required) The voting key address. The private key does not have to be known by your wallet.
It has to match the private key which is later used when voting on proposals.
If set to an empty string, ownerAddress will be used.
7. operatorReward (string, required) The fraction in %% to share with the operator. The value must be
between 0.00 and 100.00.
8. payoutAddress_register (string, required) The dash address to use for masternode reward payments.
...
```
```
protx update_service "proTxHash" "ipAndPort" "operatorKey" ( "operatorPayoutAddress" "feeSourceAddress" )
...
2. ipAndPort (string, required) IP and port in the form "IP:PORT".
Must be unique on the network. Can be set to 0, which will require a ProUpServTx afterwards.
...
```
fe95dfdd7a97ae5150d8e28ea908f619c6080008:
```
protx register "collateralHash" collateralIndex "ipAndPort" "ownerAddress" "operatorPubKey" "votingAddress" "operatorReward" "payoutAddress" ( "feeSourceAddress" submit )
...
3. ipAndPort (string, required) IP and port in the form "IP:PORT". Must be unique on the network.
Can be set to an empty string, which will require a ProUpServTx afterwards.
...
5. operatorPubKey (string, required) The operator BLS public key. The BLS private key does not have to be known.
It has to match the BLS private key which is later used when operating the masternode.
6. votingAddress (string, required) The voting key address. The private key does not have to be known by your wallet.
It has to match the private key which is later used when voting on proposals.
If set to an empty string, ownerAddress will be used.
7. operatorReward (string, required) The fraction in %% to share with the operator.
The value must be between 0 and 10000.
8. payoutAddress (string, required) The dash address to use for masternode reward payments.
...
```
```
protx update_service "proTxHash" "ipAndPort" "operatorKey" ( "operatorPayoutAddress" "feeSourceAddress" )
...
2. ipAndPort (string, required) IP and port in the form "IP:PORT". Must be unique on the network.
...
```
## What was done?
pls see individual commits
## How Has This Been Tested?
run `dash-qt`, check `help <cmd>` response
## 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 _(for repository
code-owners and collaborators only)_
Removed collateral amount from help text for `protx register_fund_hpmn`
RPC.
- [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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Should fix
https://github.com/dashpay/dash/pull/5424#discussion_r1228654939 and
make `CSimplifiedMNListEntry`'s json a bit more human-friendly (imo) by
having `nVersion` and `nType` at the top of it.
Move `nVersion` up for `CSimplifiedMNListDiff` too.
NOTE: `nVersion` wasn't actually duplicated in rpc results, it was
simply assigned twice inside. still not nice though.
Thanks @thephez ! 👍
## What was done?
## How Has This Been Tested?
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
bump chainparams to some post failed-v19-fork block on mainnet and post
recent-v19-fork block on testnet
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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 _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Should fix
https://github.com/dashpay/dash/pull/5424#discussion_r1228654939 and
make `CSimplifiedMNListEntry`'s json a bit more human-friendly (imo) by
having `nVersion` and `nType` at the top of it.
Move `nVersion` up for `CSimplifiedMNListDiff` too.
NOTE: `nVersion` wasn't actually duplicated in rpc results, it was
simply assigned twice inside. still not nice though.
Thanks @thephez ! 👍
## What was done?
## How Has This Been Tested?
## 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 _(for repository
code-owners and collaborators only)_
