## 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)_
Some conditions won't trigger when reorging exactly from the forkpoint
pls see individual commits, tl;dr: you can't get correct results with
`GetAncestor` cause the answer is in the future
reorg to 850000 and back on testnet
```
invalidateblock 0000003eddb94218e7a3f41b2ac6e26143f8a748b50cd26e86bdbbab9ebe50aa
reconsiderblock 0000003eddb94218e7a3f41b2ac6e26143f8a748b50cd26e86bdbbab9ebe50aa
```
this fails on develop and work with this patch
n/a
- [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
Some conditions won't trigger when reorging exactly from the forkpoint
## What was done?
pls see individual commits, tl;dr: you can't get correct results with
`GetAncestor` cause the answer is in the future
## How Has This Been Tested?
reorg to 850000 and back on testnet
```
invalidateblock 0000003eddb94218e7a3f41b2ac6e26143f8a748b50cd26e86bdbbab9ebe50aa
reconsiderblock 0000003eddb94218e7a3f41b2ac6e26143f8a748b50cd26e86bdbbab9ebe50aa
```
this fails on develop and work with this patch
## 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)_
Same as #5428 but with a lower block number this time. This should let
us simply reorg testnet with 18.2.2 at deeper blocks instead of bumping
v19 testnet activation params for 19.2.
n/a
- [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
Same as #5428 but with a lower block number this time. This should let
us simply reorg testnet with 18.2.2 at deeper blocks instead of bumping
v19 testnet activation params for 19.2.
## 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)_
