## 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)_
## 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)_
## Issue being fixed or feature implemented
Removed collateral amount from help text for `protx register_fund_hpmn`
RPC.
## 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)_
