5741d5da28 chore: update seeds (Kittywhiskers Van Gogh)
2d732fc66e chore: drop defunct onion seeds, add new existing onion hosts as seeds (pasta)
Pull request description:
## Issue being fixed or feature implemented
Update onion seeds for upcoming version
## What was done?
Update onion seeds to reflect latest status
## How Has This Been Tested?
As of today, all of these are able to be connected to on port 9999; I've not actually connected to all of them and verified they're on latest core or something like that; but their addresses my core knows about, and are able to be trivially connected to
## 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)_
ACKs for top commit:
kwvg:
utACK 5741d5da28
UdjinM6:
utACK 5741d5da28
Tree-SHA512: 541bcc510b2ebf6de08ac91f2b7e5b1c910536dca9bab0b38930d6e5cfa1cd05e8c014ba4c74c14c43ed211cda3275fffb5baaf1489bbd1221567130d804b0ec
31243ca313 chore: update nMinimumChainWork, defaultAssumeValid, checkpointData, chainTxData for mainnet and testnet (pasta)
Pull request description:
## Issue being fixed or feature implemented
Bump chainparams in prep for v22
## What was done?
## How Has This Been Tested?
## Breaking Changes
## 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)_
ACKs for top commit:
UdjinM6:
utACK 31243ca313
Tree-SHA512: 6a01bbbaefb69437e053340b968e0ce68e2bd9e5e5fd2900864d88ffc21c5cd3f9c2a50d8f5b19f16515cd4c62a4a8fc2d981dd6d0456e86ef96f40e350e786a
87c31ad67a Update doc/release-process.md (UdjinM6)
55d74630b4 docs: mention building for some HOSTs only in `release-process.md` (UdjinM6)
Pull request description:
## Issue being fixed or feature implemented
https://github.com/dashpay/guix.sigs/pull/73#6390 follow-up
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [ ] 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)_
Top commit has no ACKs.
Tree-SHA512: b4a2cadf5899a8aea6612b4ff9c0e9f9c530a9e2344eb090967fbcf9a2ab219aff02f11f86434e4082f84c401d578cf2d033b6838c94705f532beca4ab604986
dafa7363a3 fix: respect SENDDSQUEUE message, move DSQ relay into net processing / peerman (pasta)
Pull request description:
## Issue being fixed or feature implemented
in #6148, I broke the functionality where a peer must opt in / opt out of DSQUEUE messages. This was mostly ok, and not immediately detected, as with this bug, simply everyone would receive DSQ messages over inventory (or classically, old proto versions were not affected by this bug). But this still would result in quite a bit of wasted bandwidth for peers which may not care about DSQ at all.
## What was done?
This commit should restore the prior functionality, where a node should send the SENDDSQUEUE message if they wish to receive DSQs. Once they've sent that, depending on their protocol version, they will either have the messages pushed to them as available, or on modern protocols, they will thereafter receive DSQs over the inventory system.
NOTE: I also refactor the code in this commit, moving some network proccessing into.... wait for it... net_processing.cpp! This allowed us to remove some dependencies in coinjoin.h. DSQ messages are now relayed to peers by calling peer_manager.RelayDSQ
## How Has This Been Tested?
I have not yet mixed on testnet with this; we should include it in rc.2 and test
## Breaking Changes
Slightly breaking for v22.0.x (so rc.1), as they in theory could be relying on this new logic of always receiving the DSQ inv. But I don't think anyone besides core is using this new protocol.
## 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
ACKs for top commit:
UdjinM6:
light ACK dafa7363a3
kwvg:
utACK dafa7363a3
Tree-SHA512: 18f9b0dfe05cde19db451653db9bb9a00352efd1bc37adffd83f74958010475f2782b1111b1c0d2dd967e7a851c3c4795fa55033b4bd0cc810aa293e754ce314
5078baea2b fix(test): wait for chainlock before mining a block we expect to include said chainlock (pasta)
f39c1e6f4c fix: guard m_can_tx_relay behind m_tx_relay_mutex; make it private; add additional annotations (pasta)
Pull request description:
## Issue being fixed or feature implemented
See each commit; fixes two bugs, both discovered while running feature_llmq_chainlocks.py with tsan / debug.
one a datarace in net_processing.cpp and the other in the test I was using to ensure this fix was correct, feature_llmq_chainlocks
## What was done?
### net_processing.cpp
You can see the datarace here: https://gist.github.com/PastaPastaPasta/c966a9f805758b34524085e3d52ea7f8
We simply guard it with an existing mutex that is always locked in close proximity.
### feature_llmq_chainlocks.py
Most of the time, while generating the cycle quorum, there is sufficient time to generate a chainlock; however, this is racey, and I've observed locally where the block gets generated before a chainlock is present and as such `test_coinbase_best_cl` fails. We should instead wait for the chainlock first, and then mine the block. This was we can ensure the mined block will include that chainlock.
This was observed locally maybe 1/10 times or so
## How Has This Been Tested?
ran feature_llmq_chainlocks.py ~40 times locally with tsan / debug
## Breaking Changes
None
## 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
- [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)_
ACKs for top commit:
kwvg:
utACK 5078baea2b
knst:
utACK 5078baea2b
UdjinM6:
utACK 5078baea2b
Tree-SHA512: b346fc60809df72d0161f625073dce7062bd2641d35e4f80160fac9afeec63707de552e2856940ac2604875908ae3b98a225d352de36bfbfc6ee3fbe1e1538ff
3f2e064b18 refactor: set `const auto& cbTx` to avoid using optional throughout method (pasta)
0c0d91e491 fix: functional test feature_llmq_chainlocks.py should activate MN_RR instead v20 (Konstantin Akimov)
af93e877f2 refactor: removed pre-MN_RR logic of validation of CL (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
The fork MN_RR is active awhile on testnet and mainnet and no more need legacy check
## What was done?
Removes legacy version of checks for CL and related functional tests
## How Has This Been Tested?
Run unit / functional test - DONE
Reindex testnet - DONE
Reindex mainnet - DONE
## Breaking Changes
Removed pre-mn_rr version of checks for CL.
It's no more relevant on mainnet and testnet.
It affects behavior on new devnets and regtest for pre-mn_rr activation blocks.
## 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
ACKs for top commit:
UdjinM6:
utACK 3f2e064b18
Tree-SHA512: 8b4b3a20a54602f4df9d98e17c79004214493b15c0bce9c08c68d667a5cba86b817947f008d646c48ef9f2f86676c02085c7d0ed36e83548ef5425b64faffb89
9604d87af1 ci: cache depends/built like gitlab (pasta)
Pull request description:
## Issue being fixed or feature implemented
Depends build didn't seem to be caching properly
## What was done?
changed depends/${{ matrix.host }} to depends/built as gitlab does
## How Has This Been Tested?
Depends "build" now takes only ~1 minute instead of ~15 minutes in CI: https://github.com/PastaPastaPasta/dash/actions/runs/11899038167
## Breaking Changes
None
## Checklist:
- [ ] 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)_
ACKs for top commit:
UdjinM6:
utACK 9604d87af1
kwvg:
utACK 9604d87af1
Tree-SHA512: 63d2321f41b284be6cc2f0b2d53294cf220b1623af464d411225c0e43ec14268e1c3a701e23973e5c641925b6ea28dcb92062d8cefb9e6baed6ac5bb619ce1a1
2f18c1af30 ci: deduplicate depends building (pasta)
Pull request description:
## Issue being fixed or feature implemented
Currently we build the same host / options multiple times. Don't do this!
## What was done?
Now building depends only twice
## How Has This Been Tested?
Local CI appears to be working
## 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)_
ACKs for top commit:
kwvg:
utACK 2f18c1af30
UdjinM6:
utACK 2f18c1af30
Tree-SHA512: 67460508a2e9458152f7c8bb5f4a1a786aedcfded0e5c54fb03d85010ba8bb87362b66a0c322b51aeba75752e36418fc235d8dc4197ef10695e234ccc5a00a39
c5d5b14205 ci: add powerpc64 to GH Guix job matrix (UdjinM6)
Pull request description:
## Issue being fixed or feature implemented
I guess we should make sure that binaries for every possible platform can be built via Guix with no issues even if we do not want to provide "official" binaries for it.
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [ ] 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)_
Top commit has no ACKs.
Tree-SHA512: 6464b68a47e680bb379c82842599200d6917adb8f1493fa75ac80ddc7a6fea92a9190215cfa3f32b0bd88e2dd0425d4eb13846ea2d7e19e144afff9c1171ff13
c5d482e0d2 chore: suppress `git config` output (UdjinM6)
8ce9bfea59 chore: tweak error message (UdjinM6)
f4d879a0b3 guix: more sanity checks for `WORKSPACE_PATH` (UdjinM6)
07f056a377 guix: Let `XCODE_SOURCE` be specified via env (UdjinM6)
74489dc82d chore: Log when preparing macOS SDK or adding `safe.directory` option (UdjinM6)
3ac5739e38 guix: "Invert" `guix-start`/`guix-check` cmd-line argument behaviour, defaults to `pwd` (UdjinM6)
187a4f1a0c guix: Avoid adding duplicate `safe.directory` option (UdjinM6)
87c978605e guix: `guix-start` should respect `SDK_PATH` (UdjinM6)
ee5f62b0db guix: build only supported targets using Guix container (Kittywhiskers Van Gogh)
Pull request description:
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/pull/6382#discussion_r1833266383https://github.com/dashpay/dash/pull/6388#discussion_r1835779789
alternative to #6388
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [ ] 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)_
ACKs for top commit:
kwvg:
ACK c5d482e0d2
Tree-SHA512: c0271f243f5912f55276fcb371a135f443f23cc1f29480f303ea77deeadb6fd7d3d97e07e6a1fa323a2b2bad1d65aa6298da33978832eb68a0a6303db3e0063c
d7cb92aa7a merge bitcoin#28783: remove `-bind_at_load` usage (Kittywhiskers Van Gogh)
019c9dd7f4 partial bitcoin#25612: default to using GCC tool wrappers for LTO (with GCC) (Kittywhiskers Van Gogh)
9e0b93568b partial bitcoin#24866: No longer need to hack the `PATH` variable in `config.site` (Kittywhiskers Van Gogh)
5dbc83bef1 merge bitcoin#28630: update `LD64_VERSION` to 711 (Kittywhiskers Van Gogh)
b265352c7a merge bitcoin#28422: cctools 986, ld64 711 & libtapi 1300.0.6.5 (Kittywhiskers Van Gogh)
fe94154851 merge bitcoin#28337: use Clang 15 for macOS cross-compilation (Kittywhiskers Van Gogh)
ba281413b0 ci: add missing `xorriso` `PACKAGES` entry in macOS environment (Kittywhiskers Van Gogh)
62b0213c45 merge bitcoin#27999: add macOS test for fixup_chains usage (Kittywhiskers Van Gogh)
be175091e6 merge bitcoin#27676: Bump minimum required runtime version and prepare for building with upstream LLVM (Kittywhiskers Van Gogh)
9f5d4b3719 merge bitcoin#27798: modernize clang flags for Darwin (Kittywhiskers Van Gogh)
54c538d697 merge bitcoin#26578: install binutils, not binutils-gold in depends (Kittywhiskers Van Gogh)
d0aae2bd3d merge bitcoin#26059: revert "Build depends/qt with our platform definition" (Kittywhiskers Van Gogh)
9d1cd6255d merge bitcoin#25917: libnatpmp 07004b97cf691774efebe70404cf22201e4d330d (Kittywhiskers Van Gogh)
fff0f6b628 merge bitcoin#25838: Use `mkspecs/bitcoin-linux-g++` for all Linux hosts (Kittywhiskers Van Gogh)
8d51bcc171 merge bitcoin#22380: add and use C_STANDARD and CXX_STANDARD in depends (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Dependent on https://github.com/dashpay/dash/pull/6383
* Dependency for https://github.com/dashpay/dash/pull/6385
* [bitcoin#24866](https://github.com/bitcoin/bitcoin/pull/24866) is partial because f3af4f7 alters the way `dsymutil`'s location is reported, which is relevant due to the build target `osx_debug` ([source](3aa51d6515/src/Makefile.am (L1025-L1026))) using `dsymutil` to generate flat dSYM bundles to ensure that stacktraces work as expected (introduced in [dash#3006](1807c47a69 (diff-4cb884d03ebb901069e4ee5de5d02538c40dd9b39919c615d8eaa9d364bbbd77R668-R669)))
As-is, with the changes, aberrant behaviour is noticeable when running `configure` (see below), where `depends` defines `DSYMUTIL` as being included in the target directory of the `native_clang` package... despite Guix builds using `FORCE_USE_SYSTEM_CLANG` ([source](3aa51d6515/contrib/guix/libexec/build.sh (L206))), meaning, the `native_clang` is never staged in `depends` because the build environment natively has it.
Attempting to override it in `build.sh` yielded no results.
<details>
<summary>Run:</summary>
```
[...]
checking whether dsymutil needs -flat... ./configure: line 36201: /dash/depends/x86_64-apple-darwin/native/bin/x86_64-apple-darwin-dsymutil: No such file or directory
no
checking that generated files are newer than configure... done
[...]
```
</details>
Which eventually results in the build failing
<details>
<summary>Failure:</summary>
```
make: Entering directory '/distsrc-base/distsrc-22.0.0-beta.1-79-gb284e4c7cd48-x86_64-apple-darwin/src'
for i in dashd dash-cli dash-tx dash-wallet test/test_dash qt/dash-qt ; do mkdir -p $i.dSYM/Contents/Resources/DWARF && /dash/depends/x86_64-apple-darwin/native/bin/x86_64-apple-darwin-dsymutil -o $i.dSYM/Contents/Resources/DWARF/$(basename $i) $i &> /dev/null ; done
make: *** [Makefile:22468: osx_debug] Error 127
make: Leaving directory '/distsrc-base/distsrc-22.0.0-beta.1-79-gb284e4c7cd48-x86_64-apple-darwin/src'
```
</details>
To avoid breakage, the commit overriding `DSYMUTIL` and subsequent changes building on it (portions of [bitcoin#25612](https://github.com/bitcoin/bitcoin/pull/25612)) have been skipped.
## Breaking Changes
* The minimum runtime version needed to run Dash Qt is now macOS 11 (Big Sur)
## Checklist
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)**
- [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)_
ACKs for top commit:
UdjinM6:
utACK d7cb92aa7a
Tree-SHA512: 28c9ea13adc80a00b501afca286bd0b97e14a272bb50f578df7ab1af6ee8139f563bc5d670f0bfe3632bfab769c8228a76b5bcc51cfb727a54e31ac0f9af7a97
a014cf3703 refactor: trim and document assumptions for `Get`*`MN`* and friends (Kittywhiskers Van Gogh)
8c9f57dac4 refactor: trim and document assumptions for `GetQuorum` and friends (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
This pull request aims to document assumptions when handling `CDeterministicMNCPtr` and `CQuorumCPtr` entities, which can be `nullptr`. In some instances, mishandling or missing validation logic can result in an assertion failure or a null pointer dereference (in both circumstances, the client will crash).
While in other cases, assumptions are made based on prior code that affirms that the returned value will be valid. For the former, bail-out logic has been introduced and for the latter, assertions and code comments have been added.
## 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 **(note: N/A)**
- [x] I have made corresponding changes to the documentation **(note: N/A)**
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
knst:
utACK a014cf3703
UdjinM6:
utACK a014cf3703
Tree-SHA512: e21824d61d81c4ca4b5b4a545a833932946eb0f279d15c586bb5eae96aefcc88d1e3b3fdfa7a01d161f1650351a7cac4bc917b2d1109d77ea2eedd8408d8f37d
Some portions of the codebase make implicit assumptions that `GetQuorum`
will not return a `nullptr` by not performing checking for it or make
explicit assumptions by `assert`ing not-`nullptr`.
Let's document explicit assumptions, document implicit assumptions and
soften some hard assumptions where softening is possible.
e9387eef69 refactor: remove unused includes and forward declarations from headers (Konstantin Akimov)
f2a186f3f3 refactor: remove definition IsQuorumDKGEnabled from header (Konstantin Akimov)
8a7941bd0d refactor: merge helper GetCoinbaseTx which is used only once into GetNonNullCoinbaseChainlock (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
Split from https://github.com/dashpay/dash/pull/6375 and added some extra
## What was done?
Tidy up headers of evo/ and llmq/:
- removed unused includes and added missing
- removed unused forward declarations and added missing
- removed helper GetCoinbaseTx, moved helper IsQuorumDKGEnabled from header to implementation
## How Has This Been Tested?
Run unit and functional tests
Compilation time _in theory_ should be improved, in really it shaved just 2-5 seconds from 5 minutes by my benchmark.
## 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
- [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)_
ACKs for top commit:
UdjinM6:
utACK e9387eef69
PastaPastaPasta:
utACK e9387eef69
Tree-SHA512: 7b4795fe0bcea23b9f368a962b888d610cac94b42dd6419cfe06977c1a28bbe27a7a2ae2e4cd730ec0ca4f8b333f656a601ebb90bc271f4117dec7a424a08b45
c32fac079f refactor: more `CGovernanceVote` cleanups (UdjinM6)
efc8c99139 refactor: Introduce `get_chain_conf_names` (UdjinM6)
519966efff refactor: Refactor `CCbTx` python class to match c++ declaration (UdjinM6)
38a0b5ac04 refactor: Move `HasChainLock()` calls out of loops (UdjinM6)
6370c7a9e5 refactor: Tidy up `CGovernanceVote` a bit (UdjinM6)
ae675d5314 refactor: Drop redundant `SplitBy` (UdjinM6)
88c3a13674 refactor: Use `switch..case` instead of `if` in `AvailableCoins` (UdjinM6)
38b304c7b0 refactor: Make bls worker aggregator batch size const (rename it accordingly) (UdjinM6)
0cf7d4a65e refactor: Turn `ReadResult` into enum class (UdjinM6)
d9aab0fa60 refactor: Rename `masternode_state_t` and turn it into enum class (UdjinM6)
Pull request description:
## Issue being fixed or feature implemented
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [ ] 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)_
ACKs for top commit:
knst:
utACK c32fac079f
PastaPastaPasta:
utACK c32fac079f
Tree-SHA512: 7a33d2d535f73c858cd01a442fb28793b1ea185a2eb50d6bce86b44be1012b7427649e3496647b4a0a7d7816dbbb50f138fa701d203c2aa1e7a515c9c9a0e931
91b7ef8607 merge bitcoin#30438: build Linux GCC with --enable-cet (Kittywhiskers Van Gogh)
cfc6cba4ea partial bitcoin#30511: GCC 12 consolidation (Kittywhiskers Van Gogh)
06f54318b3 merge bitcoin#30231: bump time-machine to f0bb724211872cd6158fce6162e0b8c73efed126 (Kittywhiskers Van Gogh)
5b292eec92 merge bitcoin#29846: replace GCC unaligned VMOV patch with binutils patch (Kittywhiskers Van Gogh)
4d1f7dccd7 merge bitcoin#29828: remove `gcc-toolchain static` from Windows build (Kittywhiskers Van Gogh)
f321d3de0c merge bitcoin#29673: use GCC 11 in macOS build env (Kittywhiskers Van Gogh)
d570e2d21f merge bitcoin#29695: build GCC with --enable-standard-branch-protection (Kittywhiskers Van Gogh)
c965943a57 merge bitcoin#29651: bump time-machine to dc4842797bfdc5f9f3f5f725bf189c2b68bd6b5a (Kittywhiskers Van Gogh)
59a125a5ad merge bitcoin#27897: use GCC 12.3.0 to build releases (Kittywhiskers Van Gogh)
a701b06435 merge bitcoin#29078: Bump guix time-machine to unlock riscv64 metal (Kittywhiskers Van Gogh)
d4b10a3813 merge bitcoin#28786: switch to 6.1 kernel headers over 5.15 (Kittywhiskers Van Gogh)
c3718700ab merge bitcoin#28580: update time-machine (Kittywhiskers Van Gogh)
d36c9b6466 merge bitcoin#28759: update signapple to latest master (Kittywhiskers Van Gogh)
38c71d88b4 merge bitcoin#28370: remove GCC 10 workaround from NSIS (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Dependent on https://github.com/dashpay/dash/pull/6382
* Dependency for https://github.com/dashpay/dash/pull/6384
## Breaking Changes
None expected
## Checklist
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)**
- [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)**
- [x] I have made corresponding changes to the documentation **(note: N/A)**
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK 91b7ef8607
Tree-SHA512: 0cfb436a430cf4b624a48a9928ecac9cd5c50e88e51ed04e7d1d0100968af8be1183364f035ac75153781a5e1616aa2f6fadabf0a1c03ec4b66dedea544b77ad
