111880aaf7e12a12f0797f1b19673e3d96328edd [test] Add coverage to estimaterawfee and estimatesmartfee (Ben Woosley)
Pull request description:
This adds light functional coverage to estimaterawfee - a subset of
the testing applied to estimatesmartfee, and argument validation
testing to both estimaterawfee and estimatesmartfee.
One valid estimatesmartfee signature test is commented out because it
fails currently.
Extracted from #12940
Top commit has no ACKs.
Tree-SHA512: 361a883457b28b2dc75081666e49d6dc6b5d76eed40d858abe2dd4f35ece152cf1f99c94480a91f42a896aa2a73cf55f57921316fe66970b2d7ba691a3b17e2d
## Issue being fixed or feature implemented
Overview page shows either wallet info or "Create wallet" button. Unlike
in bitcoin we can switch to other pages even when no wallets are enabled
(because we have Masternodes and Governance tabs) but then there is no
way to return back to Overview page.
## What was done?
Keep Overview tab always enabled. Make a no-wallet groupbox a member of
`WalletFrame` and add logic to switch to it when needed.
## How Has This Been Tested?
`./src/qt/dash-qt --regtest --nowallet`
## 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
**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
PS. kudos to @thephez for reporting :)
## Issue being fixed or feature implemented
In `protx register_hpmn`, `protx register_fund_hpmn`, `protx
register_prepare_hpmn` and `protx update_service_hpmn` the fields
`platformHTTPPort` and `platformP2PPort` were parsed as strings instead
of integers.
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
## What was done?
`update_registrar_legacy` was missing from the protx help output.
## 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
- [x] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
bfe1ba2f5b36056e0c41edf8206b93d3d83098df rel-builds: Specify core.abbrev for git-rev-parse (Carl Dong)
27e63e01cce368d67092de8f0c736927d6f6aa69 build: Accomodate makensis v2.x (Carl Dong)
1f2c39a30e0f82046c7aecddfda3eb99cb536816 guix: Remove logical cores requirement (Carl Dong)
a4f6ffa71e335d4b2a6bf525b7f416968f9cd9f7 lint: Also enable source statements for non-gitian (Carl Dong)
d256f91cb1b0d6ff5170106b99b0266cbe51f5a2 rel-builds: Directly deploy win installer to OUTDIR (Carl Dong)
fa791da02f9684e3fd554b687fb692ae6a23d65a nsis: Specify OutFile path only once (Carl Dong)
14701604d0904bc5bbf1c67de08f8ee6d3215523 guix: Expose GIT_COMMON_DIR in container as readonly (Carl Dong)
f5a6ac4f48b18f93050d77bcb23f9cf45ec34647 guix: Make source tarball using git-archive (Carl Dong)
395c1137f630dc495ffb2752a23bc1dfd470ee53 gitian: Limit sourced script to just assignments (Carl Dong)
Pull request description:
Based on: #18556
Related: https://github.com/bitcoin/bitcoin/pull/17595#discussion_r399728721
ACKs for top commit:
fanquake:
ACK bfe1ba2f5b36056e0c41edf8206b93d3d83098df - I agree with Carl, and am going to merge this. I'd like for Linux Guix builds to be working again, and we can rebase #18818.
Tree-SHA512: c87ada7e3de17ca0b692a91029b86573442ded5780fc081c214773f6b374a0cdbeaf6f6898c36669c2e247ee32aa7f82defb1180f8decac52c65f0c140f18674
f2b5b0a3b48f9241971c14238040048f8b630811 build: add linker optimization flags to guix (fanquake)
b8b050a8d642e38c81d1e451750c2c8db92fee5e build: add linker optimization flags to gitian descriptors (fanquake)
Pull request description:
This PR adds `-Wl,O2` to our gitian and guix LDFLAGS. This makes the linker perform certain optimisations (and is different from LTO).
Any -O argument will enable optimizations in GNU ld. We can use -O2 here, as this matches our compile flags. Note that this would also enable additional optimizations if using the lld or gold linkers, when compared to -O0.
A nice writeup + diagrams of some of these optimizations is available here: http://lwn.net/Articles/192624/.
#### master
```bash
# bitcoind
Histogram for `.gnu.hash' bucket list length (total of 3 buckets)
Length Number % of total Coverage
0 1 ( 33.3%) 0.0%
1 0 ( 0.0%) 0.0%
2 1 ( 33.3%) 40.0%
3 1 ( 33.3%) 100.0%
```
```bash
# bitcoin-qt
Histogram for `.gnu.hash' bucket list length (total of 3 buckets)
Length Number % of total Coverage
0 0 ( 0.0%) 0.0%
1 1 ( 33.3%) 10.0%
2 0 ( 0.0%) 10.0%
3 0 ( 0.0%) 10.0%
4 1 ( 33.3%) 50.0%
5 1 ( 33.3%) 100.0%
```
#### this PR:
```bash
# bitcoind
Histogram for `.gnu.hash' bucket list length (total of 8 buckets)
Length Number % of total Coverage
0 3 ( 37.5%) 0.0%
1 5 ( 62.5%) 100.0%
```
```bash
# bitcoin-qt
Histogram for `.gnu.hash' bucket list length (total of 19 buckets)
Length Number % of total Coverage
0 9 ( 47.4%) 0.0%
1 10 ( 52.6%) 100.0%
```
#### GNU ld -O
> If level is a numeric values greater than zero ld optimizes the output. This might take significantly longer and therefore probably should only be enabled for the final binary. At the moment this option only affects ELF shared library generation. Future releases of the linker may make more use of this option. Also currently there is no difference in the linker’s behaviour for different non-zero values of this option. Again this may change with future releases.
#### lld -O
> Optimize output file size
ACKs for top commit:
dongcarl:
ACK f2b5b0a3b48f9241971c14238040048f8b630811
laanwj:
ACK f2b5b0a3b48f9241971c14238040048f8b630811
Tree-SHA512: e53f3a4338317dbec65d3a93b57b5a6204aabdf9ac82d99447847a3c8627facc53c58c2cf947376f13edd979fc8129a80f18d9ebeccd191a576c83f1dad5c513
a35e3235891d35daa167116cc70340140e883f06 guix: Appease travis. (Carl Dong)
0b66d22da5f53640e22f05adf880782c613e6d0f guix: Use gcc-9 for mingw-w64 instead of 8 (Carl Dong)
ba0b99bdd613ba7f17c6247ece3001e1b44759a3 guix: Don't set MINGW_HAS_SECURE_API CFLAG in depends (Carl Dong)
93439a71eda49fb69f1e82966a23a946733aa6fa guix: Bump to upstream commit with mingw-w64 changes (Carl Dong)
35a96792dda9e78165b1598aeac7b2ab759e7be5 guix: Check mingw symbols, improve SSP fix docs (Carl Dong)
449d8fe25bbe25daacfc67aa89ca32b0a3254c5a guix: Expand on INT trap message (Carl Dong)
3f1f03c67a8e9edf487f08d272adb18b0a3942c8 guix: Spelling fixes (Carl Dong)
ff821dd2a1c600488d11e7d9a20e9179ecc9144b guix: Reinstate make-ssp-fixed-gcc (Carl Dong)
360a9e0ad50a36ec79a1a160dbed3966689fd41c guix: Bump time-machine for mingw-w64 patches (Carl Dong)
93e41b7e3b54c17fd1b4c61ee95fc0dc2827e954 guix: Use gcc-8 for mingw-w64 instead of 7 (Carl Dong)
ef4f7e4c45c60a69406134122f091c77c6ef740f guix: Set the well-known timezone env var (Carl Dong)
acf4b3b3b5accf60a19441a0298ef27001b78e72 guix: Make x86_64-w64-mingw32 builds reproducible (Carl Dong)
c4cce00eac691625b78b92f7dba0b7f57def19e5 guix: Remove dead links from README. (Carl Dong)
df953a4c9a6143f45864757b706c88b6fa70545a guix: Appease shellcheck. (Carl Dong)
91897c95e191d293eb27d8af15cbeafc5b8f3895 guix: Improve guix-build.sh documentation (Carl Dong)
570d769c6c59b9f6d1a2b95b2ed60432cb33b3ba guix: Build support for Windows (Carl Dong)
Pull request description:
~~Based on: https://github.com/bitcoin/bitcoin/pull/16519~~
Based on: #17933 (Time Machines are... shall we say... superior 😁)
This PR allows us to perform Guix builds for the `x86_64-w64-mingw32` target. We do this _without_ splitting up the build script like we do in Gitian by using this newfangled alien technology called `case` statements. (This is WIP and might be changed to `if` statements soon)
ACKs for top commit:
fanquake:
ACK a35e3235891d35daa167116cc70340140e883f06 2/3
Tree-SHA512: c471951c23eb2cda919a71285d8b8f2580cb20f09d5db17b53e13dbd8813e01b3e7a83ea848e4913fd0f2bc12c6c133c5f76b54e65c0d89fed4dfd2e0be19875
0ae42a16c766a7ecb8711bfad6f22b8581ea0258 guix: Remove now-unnecessary gcc make flag (Carl Dong)
Pull request description:
```
Previously, Guix would produce a gcc which did not know to use the SSP
function from glibc, and required a gcc make flag for it to do so, in my
attempt to fix it upstream I realized that this is no longer the case.
This can be verified by performing a Guix build and doing
readelf -s ... | grep __stack_chk
to check that symbols are coming from glibc, and doing
readelf -d ... | grep NEEDED | grep ssp
to see that libssp.so is not being depended on
```
ACKs for top commit:
fanquake:
ACK 0ae42a16c766a7ecb8711bfad6f22b8581ea0258 - ran a Guix build (hashes below) and checked all the linux binaries:
Tree-SHA512: 701b91e7c323b12a29af9539cb2656d10ce0a93af573a02e57f0b7fea05a6e1819798536eadb24d0a17e7f35b503f5e863fee5e7409db1b8a3973c4375e49d4e
fae9084ac5b10f94bdee54853d307838c4254e9c build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a2554c2661b8f2a759044d5ac85c9979d9ca depends: Remove reference to win32 (MarcoFalke)
Pull request description:
Closes#17504
Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.
i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.
ACKs for top commit:
practicalswift:
ACK fae9084ac5b10f94bdee54853d307838c4254e9c -- patch looks correct
dongcarl:
ACK fae9084ac5b10f94bdee54853d307838c4254e9c patch looks correct
laanwj:
Code review ACK fae9084ac5b10f94bdee54853d307838c4254e9c
hebasto:
ACK fae9084ac5b10f94bdee54853d307838c4254e9c, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
88c83636d5a56bd9551577139786bdd3e74852c2 guix: Update documentation for time-machine (Carl Dong)
e6050884fdabfa6e51e6afce2041d91e60a5adec guix: Pin Guix using `guix time-machine` (Carl Dong)
Pull request description:
An alternative to #16519, pinning our version of Guix and eliminating a `guix pull` and changing the default Guix profile of builders.
I think this method might be superior, as it:
- Eliminates the possibility of future changes to the `guix environment` command line interface breaking our builds
- Eliminates the need to set up a separate channel repo
It is a more general pinning solution than #16519.
-----
The reason why I didn't originally propose this is because `guix time-machine` is a recent addition to Guix, only available since `f675f8dec73d02e319e607559ed2316c299ae8c7`
ACKs for top commit:
fanquake:
ACK 88c83636d5a56bd9551577139786bdd3e74852c2
Tree-SHA512: 85e03b0987ffa86da73e02801e1cd8b7622698d70c4ba4e60561611be1e9717d661c2811a59b3e137b1b8eef2d0ba37c313867d035ebc89c3bd06a23a078064a
ac831339cbfa65b1f7576c53b5d9a94841db9868 doc: Fix some misspellings (randymcmillan)
Pull request description:
Here is a more thorough lint-spelling update.
This PR takes care of easy to fix spelling errors to clean up the linting stages.
There are misspellings coded into the functional tests.
That is a whole separate job within itself.
ACKs for top commit:
practicalswift:
ACK ac831339cbfa65b1f7576c53b5d9a94841db9868 -- diff looks correct
Tree-SHA512: d8fad83fed083715655f148263ddeffc6752c8007d568fcf3dc2c418ccd5db70089ce3ccfd3994fcbd78043171402eb9cca5bdd5125287e22c42ea305aaa6e9d
751549b52a9a4cd27389d807ae67f02bbb39cd7f contrib: guix: Additional clarifications re: substitutes (Carl Dong)
cd3e947f50db7cfe05c05b368c25742193729a62 contrib: guix: Various improvements. (Carl Dong)
8dff3e48a9e03299468ed3b342642f01f70da9db contrib: guix: Clarify SOURCE_DATE_EPOCH. (Carl Dong)
3e80ec3ea9691c7c89173de922a113e643fe976b contrib: Add deterministic Guix builds. (Carl Dong)
Pull request description:
~~**This post is kept updated as this project progresses. Use this [latest update link](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-497303718) to see what's new.**~~
Please read the `README.md`.
-----
### Guix Introduction
This PR enables building bitcoin in Guix containers. [Guix](https://www.gnu.org/software/guix/manual/en/html_node/Features.html) is a transactional package manager much like Nix, but unlike Nix, it has more of a focus on [bootstrappability](https://www.gnu.org/software/guix/manual/en/html_node/Bootstrapping.html) and [reproducibility](https://www.gnu.org/software/guix/blog/tags/reproducible-builds/) which are attractive for security-sensitive projects like bitcoin.
### Guix Build Walkthrough
Please read the `README.md`.
[Old instructions no. 4](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-497303718)
[Old instructions no. 3](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-493827011)
[Old instructions no. 2](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-471658439)
<details>
<summary>Old instructions no. 1</summary>
In this PR, we define a Guix [manifest](https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#profile_002dmanifest) in `contrib/guix/manifest.scm`, which declares what packages we want in our environment.
We can then invoke
```
guix environment --manifest=contrib/guix/manifest.scm --container --pure --no-grafts --no-substitutes
```
To have Guix:
1. Build an environment containing the packages we defined in our `contrib/guix/manifest.scm` manifest from the Guix bootstrap binaries (see [bootstrappability](https://www.gnu.org/software/guix/manual/en/html_node/Bootstrapping.html) for more details).
2. Start a container with that environment that has no network access, and no access to the host's filesystem except to the `pwd` that it was started in.
3. Drop you into a shell in that container.
> Note: if you don't want to wait hours for Guix to build the entire world from scratch, you can eliminate the `--no-substitutes` option to have Guix download from available binary sources. Note that this convenience doesn't necessarily compromise your security, as you can check that a package was built correctly after the fact using `guix build --check <packagename>`
Therefore, we can perform a build of bitcoin much like in Gitian by invoking the following:
```
make -C depends -j"$(nproc)" download && \
cat contrib/guix/build.sh | guix environment --manifest=contrib/guix/manifest.scm --container --pure --no-grafts --no-substitutes
```
We don't include `make -C depends -j"$(nproc)" download` inside `contrib/guix/build.sh` because `contrib/guix/build.sh` is run inside the container, which has no network access (which is a good thing).
</details>
### Rationale
I believe that this represents a substantial improvement for the "supply chain security" of bitcoin because:
1. We no longer have to rely on Ubuntu for our build environment for our releases ([oh the horror](72bd4ab867/contrib/gitian-descriptors/gitian-linux.yml (L10))), because Guix builds everything about the container, we can perform this on almost any Linux distro/system.
2. It is now much easier to determine what trusted binaries are in our supply chain, and even make a nice visualization! (see [bootstrappability](https://www.gnu.org/software/guix/manual/en/html_node/Bootstrapping.html)).
3. There is active effort among Guix folks to minimize the number of trusted binaries even further. OriansJ's [stage0](https://github.com/oriansj/stage0), and janneke's [Mes](https://www.gnu.org/software/mes/) all aim to achieve [reduced binary boostrap](http://joyofsource.com/reduced-binary-seed-bootstrap.html) for Guix. In fact, I believe if OriansJ gets his way, we will end up some day with only a single trusted binary: hex0 (a ~500 byte self-hosting hex assembler).
### Steps to Completion
- [x] Successfully build bitcoin inside the Guix environment
- [x] Make `check-symbols` pass
- [x] Do the above but without nasty hacks
- [x] Solve some of the more innocuous hacks
- [ ] Make it cross-compile (HELP WANTED HERE)
- [x] Linux
- [x] x86_64-linux-gnu
- [x] i686-linux-gnu
- [x] aarch64-linux-gnu
- [x] arm-linux-gnueabihf
- [x] riscv64-linux-gnu
- [ ] OS X
- [ ] x86_64-apple-darwin14
- [ ] Windows
- [ ] x86_64-w64-mingw32
- [ ] Maybe make importer for depends syntax
- [ ] Document build process for future releases
- [ ] Extra: Pin the revision of Guix that we build with with Guix [inferiors](https://www.gnu.org/software/guix/manual/en/html_node/Inferiors.html)
### Help Wanted
[Old content no. 3](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-483318210)
[Old content no. 2](https://github.com/bitcoin/bitcoin/pull/15277#issuecomment-471658439)
<details>
<summary>Old content no. 1</summary>
As of now, the command described above to perform a build of bitcoin a lot like Gitian works, but fails at the `check-symbols` stage. This is because a few dynamic libraries are linked in that shouldn't be.
Here's what `ldd src/bitcoind` looks like when built in a Guix container:
```
linux-vdso.so.1 (0x00007ffcc2d90000)
libdl.so.2 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libdl.so.2 (0x00007fb7eda09000)
librt.so.1 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/librt.so.1 (0x00007fb7ed9ff000)
libstdc++.so.6 => /gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/libstdc++.so.6 (0x00007fb7ed87c000)
libpthread.so.0 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libpthread.so.0 (0x00007fb7ed85b000)
libm.so.6 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libm.so.6 (0x00007fb7ed6da000)
libgcc_s.so.1 => /gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/libgcc_s.so.1 (0x00007fb7ed6bf000)
libc.so.6 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6 (0x00007fb7ed506000)
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fb7ee3a0000)
```
And here's what it looks in one of our releases:
```
linux-vdso.so.1 (0x00007ffff52cd000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f87726b4000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f87726aa000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f8772525000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f877250b000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8772347000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f8773392000)
```
~~I suspect it is because my script does not apply the gitian-input patches [described in the release process](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change) but there is no description as to how these patches are applied.~~ It might also be something else entirely.
Edit: It is something else. It appears that the gitian inputs are only used by [`gitian-win-signer.yml`](d6e700e40f/contrib/gitian-descriptors/gitian-win-signer.yml (L14))
</details>
### How to Help
1. Install Guix on your distro either [from source](https://www.gnu.org/software/guix/manual/en/html_node/Requirements.html) or perform a [binary installation](https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation)
2. Try out my branch and the command described above!
ACKs for top commit:
MarcoFalke:
Thanks for the replies. ACK 751549b52a9a4cd27389d807ae67f02bbb39cd7f
laanwj:
ACK 751549b52a9a4cd27389d807ae67f02bbb39cd7f
Tree-SHA512: 50e6ab58c6bda9a67125b6271daf7eff0ca57d0efa8941ed3cd951e5bf78b31552fc5e537b1e1bcf2d3cc918c63adf19d685aa117a0f851024dc67e697890a8d
## Issue being fixed or feature implemented
Avoid redundant calls to GetLLMQParams
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
Avoid lots of static_cast's from enums to underlying types. Communicate
intention better
## What was done?
implement c++23 inspired ToUnderlying, then see std::to_underlying and
https://en.cppreference.com/w/cpp/types/underlying_type; Then, we use
this instead of static_casts for enums -> underlying type
## How Has This Been Tested?
make check
## Breaking Changes
None
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
Since new BLS scheme introduction, a sporadic crash was appearing from
time to time during functional tests.
The crash was an uncaught exception (std::invalid_argument, what="Relic
library error") thrown from BLS operations.
Affected tests: feature_llmq_is_conflicts.py,
feature_llmq_is_migration.py
## Issue being fixed or feature implemented
This PR doesn't solve the actual problem, but it protects the node from
crashing by catching exception thrown from BLS.
All BLS aggregation operations weren't calling BLS impl code within a
try catch block.
Now, all aggregations operations are protected from the uncaught
exception.
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
`develop` can't sync on mainnet and testnet atm because platform quorums
are already active there but we skip non-hpms nodes when calculating
quorums.
## What was done?
Fixed the code to respect `IsV19Active`. Also dropped
`IsLLMQTypeHPMNOnly` cause it's not used anywhere else and it just makes
things more confusing imo.
## How Has This Been Tested?
Can successfully sync on mainnet/testnet
## Breaking Changes
n/a, fixes breaking changes introduced earlier :)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
This refactoring helps to make code more specific and clear.
There's using syntax feature from modern C++ such as 'enum class',
structure bindings in loops, declaration variables inside if/switch
statements, etc.
## What was done?
This PR is based on @PastaPastaPasta 's PR
https://github.com/dashpay/dash/pull/4472
There excluded changes related to using std::optional. Let's decide
firstly about `Result` class: https://github.com/dashpay/dash/pull/5109
## How Has This Been Tested?
Run unit/functional tests
## Breaking Changes
No breaking changes
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: Pasta <pasta@dashboost.org>
## Issue being fixed or feature implemented
Migration does too many things when it should really be just deser ->
ser and no extra logic. Implemented changes to take as short migration
path as possible.
## What was done?
Switched from processing diffs and updating mn lists to simply call
deser and ser operations.
Also skipping `AddMN` and filling internal map directly because:
1. we can trust our local db on migration and need no extra checks here;
2. we care about `mnMap` only cause it's the one that is serialized
later, we don't care about ids or unique properties here.
## How Has This Been Tested?
Run the node, migration succeeds.
As a side effect the migration process is ~20% faster on my mac now
(takes ~11 minutes on mainnet instead of ~14 minutes before).
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
While working on #5213 I noticed that `CDeterministicMNListDiff` deser
is one of the top cpu consuming operations. This can be improved.
## What was done?
Switched from `map` to `unordered_map`.
## How Has This Been Tested?
Run node, everything still works. Applying this patch on top of #5213
gives another ~20% improvement in migration time on my mac: from ~14
minutes originally to ~8 minutes with both patches applied.
## Breaking Changes
Shouldn't be any. In most cases we just `emplace` and loop over
`updatedMNs`. The only place we use `find` is
`CMNAuth::NotifyMasternodeListChanged` and slight potential performance
drop there is acceptable imo given the improvement in deser/migration
time.
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
We use `GetMnType` in some critical parts of code where we process data
from blocks and such. Having `assert` called there makes me nervous 😅
## What was done?
We should simply consider all unknown types invalid instead of crashing
here. Introduced new dummy mn type for which no real mn can ever satisfy
conditions.
## 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
**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
## What was done?
1. Increased protocol version of mininode to match v19 changes in
`MNLISTDIFF` P2P message
2. Added verification of MNs and HPMNs (dip4) in `feature_llmq_hpmn.py`
## 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
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
Currently, by default in devnet, the LLMQ set for Platform is
`LLMQ_100_67`.
Obviously this is too big for usual devnets, therefore the new
`LLMQ_DEVNET_PLATFORM` is created (size 12, threshold 67%).
`LLMQ_100_67` is still the default one: added possibility to overwrite
it by passing argument `-llmqplatform` (devnets only)
## 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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
## What was done?
As discussed with Platform team, threshold for `llmq_test_platform`
needed to be 67%. Therefore, the size went from 4 members to 3 (while
keeping threshold to 2)
## 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
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
## What was done?
- `masternode status` now returns the type as well
- `masternode count` now returns in addition total and total enabled MNs
per type.
## How Has This Been Tested?
Added functional tests
## 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
- [x] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
fixes an issue mentioned
[here](https://github.com/dashpay/dash/pull/5177#pullrequestreview-1293957617)
## What was done?
added missing implementation for `pubkeys`, added help text for
`addresses`, implemented some tests
## How Has This Been Tested?
`./src/test/test_dash -t wallet_tests/rpc_getaddressinfo`
## 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
- [ ] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
expressions like `nType == MnType::HighPerformance.index` look pretty
confusing in current implementation of 4k HPMN.
Changing `uint8_t` index to `enum class MnType : uint8_t` give pros:
- switch inside GetMnType() and any similar code will show a compiler
warning if any type is missing.
- instead "MnType::HighPerformance.index" you can write
MnType::HighPerformance
- you can remove confusing `.index` from MnType
But also Cons:
- instead `log("%d", nType)` you need to write `log("%d",
static_cast<int>(nType))`;
## What was done?
Introduced new enum class MnType and rewritten generating
Regular/HighPerformance objects with params (description, collateral
amount, etc).
Also were added attributes [[no_discard]] for related code.
## How Has This Been Tested?
Run unit/functional tests
## Breaking Changes
No breaking changes.
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
## Issue being fixed or feature implemented
Added a "Type" column on the masternode tab so it's easy to distinguish
between regular and HPMN
## What was done?
Added column with type
## How Has This Been Tested?
Built locally and tried on devnet with an HPMN registered
## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [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
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: Odysseas Gabrielides <odysseas.gabrielides@gmail.com>
020f0519ec66d9626255b938e1c6c3f7f9aa4017 refactor: CTxMemPool::IsUnbroadcastTx() requires CTxMemPool::cs lock (Hennadii Stepanov)
7c4bd0387a01a0c3e2938d530dba3c882e4d8f2b refactor: CTxMemPool::GetTotalTxSize() requires CTxMemPool::cs lock (Hennadii Stepanov)
fa5fcb032b6ed04c49ee465235288b8059fa805e refactor: CTxMemPool::ClearPrioritisation() requires CTxMemPool::cs lock (Hennadii Stepanov)
7140b31b90cbd84d75eedb3e395d0d55f83b5b95 refactor: CTxMemPool::ApplyDelta() requires CTxMemPool::cs lock (Hennadii Stepanov)
66e47e5e506043fbb9b4e487b44bf992985709c9 refactor: CTxMemPool::UpdateChild() requires CTxMemPool::cs lock (Hennadii Stepanov)
939807768acd508932f2efabee660d56324a73df refactor: CTxMemPool::UpdateParent() requires CTxMemPool::cs lock (Hennadii Stepanov)
Pull request description:
This is another step to transit `CTxMemPool::cs` from `RecursiveMutex` to `Mutex`.
Split out from #19306.
Only trivial thread safety annotations and lock assertions added. No new locks. No behavior change.
Refactoring `const uint256` to `const uint256&` was [requested](https://github.com/bitcoin/bitcoin/pull/19647#discussion_r468471022) by **promag**.
Please note that now, since #19668 has been merged, it is safe to apply `AssertLockHeld()` macros as they do not swallow compile time Thread Safety Analysis warnings.
ACKs for top commit:
promag:
Core review ACK 020f0519ec66d9626255b938e1c6c3f7f9aa4017.
jnewbery:
Code review ACK 020f0519ec66d9626255b938e1c6c3f7f9aa4017
vasild:
ACK 020f0519e
Tree-SHA512: a31e389142d5a19b25fef0aaf1072a337278564528b5cc9209df88ae548a31440e1b8dd9bae0169fd7aa59ea06e22fe5e0413955386512b83ef1f3e7d941e890
fafb381af8279b2d2ca768df0bf68d7eb036a2f9 Remove mempool global (MarcoFalke)
fa0359c5b30730744aa8a7cd9ffab79ded91041f Remove mempool global from p2p (MarcoFalke)
eeee1104d78eb59a582ee1709ff4ac2c33ee1190 Remove mempool global from init (MarcoFalke)
Pull request description:
This refactor unlocks some nice potential features, such as, but not limited to:
* Removing the fee estimates global (would avoid slightly fragile workarounds such as #18766)
* Making the mempool optional for a "blocksonly" operation mode
Even absent those features, the new code without the global should be easier to maintain, read and write tests for.
ACKs for top commit:
jnewbery:
utACK fafb381af8279b2d2ca768df0bf68d7eb036a2f9
hebasto:
ACK fafb381af8279b2d2ca768df0bf68d7eb036a2f9, I have reviewed the code and it looks OK, I agree it can be merged.
darosior:
ACK fafb381af8279b2d2ca768df0bf68d7eb036a2f9
Tree-SHA512: a2e696dc377e2e81eaf9c389e6d13dde4a48d81f3538df88f4da502d3012dd61078495140ab5a5854f360a06249fe0e1f6a094c4e006d8b5cc2552a946becf26
fa0572d0f3b083b4c8e2e883a66e2b198c6779f1 Pass mempool reference to chainstate constructor (MarcoFalke)
Pull request description:
Next step toward #19556
Instead of relying on the mempool global, each chainstate is given a reference to a mempool to keep up to date with the tip (block connections, disconnections, reorgs, ...)
ACKs for top commit:
promag:
Code review ACK fa0572d0f3b083b4c8e2e883a66e2b198c6779f1.
darosior:
ACK fa0572d0f3b083b4c8e2e883a66e2b198c6779f1
hebasto:
ACK fa0572d0f3b083b4c8e2e883a66e2b198c6779f1, reviewed and tested on Linux Mint 20 (x86_64).
Tree-SHA512: 12184d33ae5797438d03efd012a07ba3e4ffa0d817c7a0877743f3d7a7656fe279280c751554fc035ccd0058166153b6c6c308a98b2d6b13998922617ad95c4c
e57980b4738c10344baf136de3e050a3cb958ca5 [mempool] Remove NotifyEntryAdded and NotifyEntryRemoved callbacks (John Newbery)
2dd561f36124972d2364f941de9c3417c65f05b6 [validation] Remove pool member from ConnectTrace (John Newbery)
969b65f3f527631ede1a31c7855151e5c5d91f8f [validation] Remove NotifyEntryRemoved callback from ConnectTrace (John Newbery)
5613f9842b4000fed088b8cf7b99674c328d15e1 [validation] Remove conflictedTxs from PerBlockConnectTrace (John Newbery)
cdb893443cc16edf974f099b8485e04b3db1b1d7 [validation interface] Remove vtxConflicted from BlockConnected (John Newbery)
1168394d759b13af68acec6d5bfa04aaa24561f8 [wallet] Notify conflicted transactions in TransactionRemovedFromMempool (John Newbery)
Pull request description:
These boost signals were added in #9371, before we had a `TransactionRemovedFromMempool` method in the validation interface. The `NotifyEntryAdded` callback was used by validation to build a vector of conflicted transactions when connecting a block, which the wallet was notified of in the `BlockConnected` CValidationInterface callback.
Now that we have a `TransactionRemovedFromMempool` callback, we can fire that signal directly from the mempool for conflicted transactions.
Note that #9371 was implemented to ensure `-walletnotify` events were fired for these conflicted transaction. We inadvertently stopped sending these notifications in #16624 (Sep 2019 commit 7e89994). We should probably fix that, but in a different PR.
ACKs for top commit:
jonatack:
Re-ACK e57980b
ryanofsky:
Code review ACK e57980b4738c10344baf136de3e050a3cb958ca5, no code changes since previous review, but helpful new code comments have been added and the PR description is now more clear about where the old code came from
Tree-SHA512: 3bdbaf1ef2731e788462d4756e69c42a1efdcf168691ce1bbfdaa4b7b55ac3c5b1fd4ab7b90bcdec653703600501b4224d252cfc086aef28f9ce0da3b0563a69
