## Issue being fixed or feature implemented
Legacy IS messages are gone long time ago, no need to keep them in code.
## What was done?
Drop `MSG_LEGACY_TXLOCK_REQUEST`/`LEGACYTXLOCKREQUEST`
## How Has This Been Tested?
Run tests
## 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)_
5 minute profiling shows previous usage around ~7% and current usage
around ~2%
## Issue being fixed or feature implemented
Due to us rapidly receiving multiple duplicates of DSQueue's, we start
processing them before it's added the the vector of processed ones, we
probably at one point tried to minimize locked time, but that's not
productive here
## What was done?
Expand the locked scope to ensure we don't double process.
## How Has This Been Tested?
Ran full node for 5-10 minutes
## Breaking Changes
Should be none
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] 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)_
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
## Issue being fixed or feature implemented
Implementation of Randomness Beacon Part 3.
Starting from v20 activation fork, members for quorums are sorted using
(if available) the best CL signature found in Coinbase.
If no CL signature is present yet, then the usual way is used (By using
Blockhash instead)
The actual new way to shuffle is already implemented in
https://github.com/dashpay/dash/pull/5366.
SPV clients also need to calculate members, but they only know block
headers.
Since Coinbase is in the actual block, then they lack the required
information to correctly calculate quorum members.
## What was done?
- Message `MNLISTIDFF` is enriched with a new field `quorumsCLSigs`.
This field holds the Chainlock Signature required for each set of
indexes corresponding to quorums in field `newQuorums`.
- Protocol version has been bumped to `70230`.
- Clients with protocol version greater or equal to `70230` will receive
the new field `quorumsCLSigs`.
- The same field is returned in `protx diff` RPC.
Note:
- Field `quorumsCLSigs` will populated only after v20 activation
- If for one or more quorums, no non-null CL sig was found in CbTx then
a null signature is returned in `quorumsCLSigs`.
## How Has This Been Tested?
- Functional test mininode's protocol version was bumped to `70230`.
- `feature_llmq_rotation.py` checks that `quorumsCLSigs` match in both
P2P and RPC messages.
## Breaking Changes
No
## 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 _(for repository
code-owners and collaborators only)_
---------
Co-authored-by: thephez <thephez@users.noreply.github.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: pasta <pasta@dashboost.org>
## Issue being fixed or feature implemented
It splits from https://github.com/dashpay/dash/pull/5150/ by
@PastaPastaPasta request.
## What was done?
See commits
## How Has This Been Tested?
Run unit/functional tests
## 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
b1f59d55d920d2b35269b474762f94fec87bfb16 RPC/Wallet: unloadwallet: Clarify docs/error when both the RPC endpoint and wallet_name parameter specify a wallet (Luke Dashjr)
Pull request description:
Just documentation clarifications from #20448
ACKs for top commit:
MarcoFalke:
review ACK b1f59d55d920d2b35269b474762f94fec87bfb16
jonatack:
re-ACK b1f59d55d920d2b35269b474762f94fec87bfb16 per `git diff e8303a0 b1f59d5`
Tree-SHA512: ac068b0aa7ceed49496367fdd9425b59dbba18b56e89b26afc22a6c8ece51f0b92a169cacd55740b1cadab2b32f4f8e8700e609066ab7e59d3b53c7891da585e
c91b241b48d7f97b3e6b39d84ec780f2a3e3a0a7 Updated outdated help command for getblocktemplate (fixes#19625) (Jake Leventhal)
Pull request description:
**Summary of Changes**
* Removed coinbasetxn from the help outputs
* Added the missing name for transactions in the help outputs
* Added help outputs for longpollid and default_witness_commitment
* Added more clarity to capabilities, rules, and coinbaseaux
**Rationale**
The outputs from the help command for `getblocktemplate` are outdated and don't reflect the actual results from `getblocktemplate` (see #19625 for more details)
Fixes#19625.
ACKs for top commit:
laanwj:
ACK c91b241b48d7f97b3e6b39d84ec780f2a3e3a0a7
fjahr:
utACK c91b241b48d7f97b3e6b39d84ec780f2a3e3a0a7
Tree-SHA512: ee443af4bc3b2838dfd92e2705f344256ee785ae720e505fffea9b0ec5b75930e3b1374bae59b36d5da57c85c9aefe4d62504b028b893d6f2914dccf1e34c658
fa30d5282cb07b6de0160d7df8b649332db97dde doc: Remove label from good first issue template (MarcoFalke)
Pull request description:
Good first issues aren't that frequent that manually assigning the label is a problem, but this fixes the spam problem (e.g. https://twitter.com/GoodFirstIssues/status/1295455089491161088 )
ACKs for top commit:
jnewbery:
ACK fa30d5282cb07b6de0160d7df8b649332db97dde
Tree-SHA512: 59e7c707637cc328e2443c2b7e5d2c82ef151739ad5afb6cea1a60501318dc8c4c81c95591eed8172581ac99d43cf826dcdd547e096eff1038137853af67a975
f110b7c722eb150816a26cab161ac2b8c0f58609 rpc: document returned error fields as optional if applicable (Sebastian Falbesoner)
Pull request description:
The following RPCs return error fields (named `"error"` or `"errors"`) that are optional, but don't show up as optional in the help text yet:
* `analyzepsbt`
* `estimatesmartfee`
* `signrawtransactionwithkey`
* `signrawtransactionwithwallet`
The following RPC has the errors field already marked as optional, but doesn't match the usual format in the description (like `"if there are any"` in parantheses):
* `estimaterawfee`
This PR adds the missing optional flags and adapts the description strings. Inspired by a recent PR #19634 by justinmoon.
The instances were found via `git grep "RPCResult.*\"error"`. Note that there is one RPC so far where the return error is not optional (i.e. in case of no error, the field is included in the result, but is just empty), namely `bumpfee`.
ACKs for top commit:
adaminsky:
ACK `f110b7c`
laanwj:
ACK f110b7c722eb150816a26cab161ac2b8c0f58609, new documentation looks consistent with actual behavior
achow101:
ACK f110b7c722eb150816a26cab161ac2b8c0f58609
meshcollider:
utACK f110b7c722eb150816a26cab161ac2b8c0f58609
Tree-SHA512: 30c00f78a575b60e32b4536496af986d53a25f33e6ebbf553adcdcf825ad21a44f90267f3d1ea53326dac83bcfa9983fdb3dad6d3126e20f97f3c08ce286e188
f916847d2b56f2935c169e1b95b350a477c804cc rpc: Document getwalletinfo's unlocked_until field as optional (Justin Moon)
Pull request description:
The `getwalletinfo` RPC command's `unlocked_until` field is [optional in the code](f916847d2b/src/wallet/rpcwallet.cpp (L2397)), but wasn't marked as optional in the docs.
ACKs for top commit:
theStack:
ACK f916847d2b
achow101:
ACK f916847d2b56f2935c169e1b95b350a477c804cc
kristapsk:
ACK f916847d2b56f2935c169e1b95b350a477c804cc
Tree-SHA512: 8d82f0992fdaf8160000acf4a6e7e7f9ff289a90a983be2e078cf754f4b03601637e5f405afa66bd55adef9b347fa5eac5cc1822033b2ac08c587609cf3dfe0f
501e6ab4e778d8f4e95fdc807eeb8644df16203b doc: Add documentation for 'checklevel' argument in 'verifychain' RPC call (Calvin Kim)
Pull request description:
Rationale: When ```bitcoin-cli help verifychain``` is called, the user doesn't get any documentation about the ```checklevel``` argument, leading to issues like #18995.
This PR addresses that issue and adds documentation for what each level does, and that each level includes the checks of the previous levels.
ACKs for top commit:
jonatack:
ACK 501e6ab4e778d8f4e95fdc807eeb8644df16203b `git diff 292ed3c 501e6ab` shows only change since last review is the verifychain RPCHelpMan edit; rebuild and retested manually anyway
MarcoFalke:
ACK 501e6ab4e778d8f4e95fdc807eeb8644df16203b 🚝
Tree-SHA512: 09239f79c25b5c3022b8eb1f76198ba681305d7e8775038e46becffe5f6a14c572e0c5d06b0723fe9d4a015ec42c9f7ca7b80a2a93df0b1b66f5a84a80eeeeb1
## Issue being fixed or feature implemented
see warnings in https://github.com/dashpay/dash/actions/runs/5462770856
## What was done?
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
## How Has This Been Tested?
n/a
## 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)_
before 12%
<img width="1538" alt="image"
src="https://github.com/dashpay/dash/assets/6443210/fa5043fb-4e48-4728-bfaf-8636d5c20a8c">
after 10%
<img width="1544" alt="image"
src="https://github.com/dashpay/dash/assets/6443210/1df6aff4-2901-4af1-b421-3604f54df157">
## Issue being fixed or feature implemented
Redundant rehash
## What was done?
Avoid redundant rehash
## How Has This Been Tested?
Reindexed 0-500000 on testnet
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] 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
Building with develop docker container on aarch64
## What was done?
Only install i386 stuff on non-arm builders
## How Has This Been Tested?
Building on aarch64 / m1
## Breaking Changes
Should be none
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] 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
- [ ] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
`IsEnabled()` is checked inside anyway. Not starting the scheduler on
init results in no mixing on nodes with dynamically loaded wallets.
## 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
During implementation #5469 (master node hard-fork) I noticed that some
parts of `CChainParams` are deprecated and can be removed.
## What was done?
1. removed methods from `CChainParams` that have no implementation at
all:
- UpdateSubsidyAndDiffParams
- UpdateLLMQChainLocks
- UpdateLLMQTestParams
- UpdateLLMQDevnetParams
2. removed method `BIP9CheckMasternodesUpgraded` from `CChainParams` and
a flag `check_mn_protocol` from `versionbitsinfo`.
(to follow-up dashpay/dash#2594)
## How Has This Been Tested?
Run functional/unit tests.
## 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
Current implementation of BLS wrapper has an unclear interface related
to `checkMalleable` flag.
There are 2 methods Unserialize, that has both default arguments:
```
template
inline void Unserialize(Stream& s, const bool specificLegacyScheme, bool checkMalleable = true);
template
inline void Unserialize(Stream& s, bool checkMalleable = true);
```
Let's assume that I am calling `Unserialize(s, true)` - it's very
non-obvious which one will be called and not error prune at all.
It should be re-implemented, and there should not be default argument.
Pasta noticed that this flag can be useful from performance point of
view - let's have better new method such as `UnserializeNoMalleable` or
similar and use it when reindexing/etc. It should be specified explicit.
Reverting this change and adding new interface in future won't be
difficult task so far as changes are quite trivial.
## What was done?
Removed flag checkMalleable to simplify code because it's always true.
It splits from https://github.com/dashpay/dash/pull/5443
## How Has This Been Tested?
Run unit functional tests.
## Breaking Changes
No breaking changes - flag is always true.
## 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
## Issue being fixed or feature implemented
As noticed by Udjin in #5393, there should be `dash_ents` in the config.
## What was done?
Updated config `.tx/config`
## How Has This Been Tested?
@UdjinM6 please help to test, I have no access to
`https://www.transifex.com` translations
## 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
## Issue being fixed or feature implemented
There are useless debug logs "CDEF" in `wallet_tests` unit tests.
## What was done?
removes it
## How Has This Been Tested?
Run unit/functional tests
## 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
## Issue being fixed or feature implemented
Many usages of `CBLS{Signature,PrivateKey,PublicKey}` assume using
global variable, even if can be specified explicitly.
Some of these usages have been deglobalized in this PR.
Some prior improvements and fixes are here:
[#5403](https://github.com/dashpay/dash/pull/5403)
## What was done?
- Refactored the uses of global variable of `bls_legacy_scheme` from
`SetHex`, `SetByteVector`, some rpc calls.
- Removed flag `checkMalleable` to simplify code because it's always
`true`.
- Removed dependency from `txmempool.h` on `bls.h` to speed up
compilation.
## How Has This Been Tested?
Run unit/functional tests.
## Breaking Changes
No breaking changes assumed. But in theory behaviour of some RPC can be
more explicit and predictable.
## 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
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
Allow `upgradetohd` in IBD, better errors, no GUI lock-up
## What was done?
Pls see individual commits. Most of it is changes in whitespaces, might
want to use ?w=1 to review i.e.
https://github.com/dashpay/dash/pull/5455/files?w=1
## How Has This Been Tested?
run tests, try `upgradetohd` on testnet
## 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)_
