## Issue being fixed or feature implemented
Bump develop version to v20.1.0; v21 features should not yet be merged
into develop; when the time is come to begin merging v21 features into
develop, we can then bump version again.

## What was done?
Bump version

## 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)_

chore: Merge master v20.0.0 back into develop

## Issue being fixed or feature implemented
Docs was slightly incorrect after moving to guix

## What was done?
fixed docs

## How Has This Been Tested?
Did notarization :)

## Breaking Changes


## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

## Issue being fixed or feature implemented
`creditpool` and `ehf` categories are missing in `logging`/`debug` RPCs
😞

## What was done?


## How Has This Been Tested?
run `debug` and `logging` RPCs and make sure these categories are listed
now

## 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)_

…y#5705)

## Issue being fixed or feature implemented
Make it possible to pass additional configure params into Guix. This
could be used to setup various sets of nightly/debug builds which could
then be deployed automagically to catch potential issues early.

## What was done?


## How Has This Been Tested?
`CONFIGFLAGS="--enable-debug" HOSTS="x86_64-linux-gnu"
./contrib/guix/guix-build`

## 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)_

## What was done?
Fixes some inaccuracies for release notes for v20.0.0, for v19.2.0.


## 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

…done yet (dashpay#5711)

## Issue being fixed or feature implemented
`ConnectBlock` can fail after `ProcessSpecialTxsInBlock`, we shouldn't
be notifying too early. Same for `DisconnectBlock` but that's less of an
issue imo.

## What was done?
Move notifications to the end of `ConnectBlock`/`DisconnectBlock`. There
is no `connman` in `CChainState` and I don't want to pass it in updates
struct so I changed `NotifyMasternodeListChanged` and used `connman`
from `CDSNotificationInterface` instead.

## How Has This Been Tested?
run unit test, run testnet qt wallet

## 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
Add debug symbols for Darwin

## What was done?
Added Darwin debug symbols and combine them as output

## How Has This Been Tested?
guix build

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <[email protected]>

## Issue being fixed or feature implemented
make it possible to run `./contrib/guix/guix-build` without specifying
`CONFIGFLAGS`

## What was done?

## How Has This Been Tested?
run `./contrib/guix/guix-build` w/ and w/out 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)_

…e time (dashpay#5693)

## Issue being fixed or feature implemented
Some headers include other heavy headers, such as `logging.h`,
`tinyformat.h`, `iostream`. These headers are heavy and increase
compilation time on scale of whole project drastically because can be
used in many other headers.

## What was done?
Moved many heavy includes from headers to cpp files to optimize
compilation time.
In some places  added forward declarations if it is reasonable.

As side effect removed 2 circular dependencies:
```
"llmq/debug -> llmq/dkgsessionhandler -> llmq/debug"
"llmq/debug -> llmq/dkgsessionhandler -> llmq/dkgsession -> llmq/debug"
```


## How Has This Been Tested?
Run build 2 times before refactoring and after refactoring: `make clean
&& sleep 10s; time make -j18`

Before refactoring:
```
real    5m37,826s
user    77m12,075s
sys     6m20,547s

real    5m32,626s
user    76m51,143s
sys     6m24,511s
```

After refactoring:
```
real    5m18,509s
user    73m32,133s
sys     6m21,590s

real    5m14,466s
user    73m20,942s
sys     6m17,868s
```

~5% of improvement for compilation time. That's not huge, but that's
worth to get merged

There're several more refactorings TODO but better to do them later by
backports:
 - bitcoin#27636
 - bitcoin#26286
 - bitcoin#27238
 - and maybe this one: bitcoin#28200


## 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

TODO itself is removed in bitcoin#10618 (DNM)
But actually fixed in [merged] Merge bitcoin#18021: Convert undo.h to new serialization framework

fa50d8b doc: Remove TODO comment in tx_verify (MarcoFalke)

Pull request description:

  The comment has no clear motivation, so it seems better to remove it and fix it when there is a reason.

  An alternative (if a fix isn't possible when there is a clear motivation) would be to create an issue thread for easier discussion.

ACKs for top commit:
  fanquake:
    ACK fa50d8b

Tree-SHA512: e9c25bab46a73b7c2db288c62ed9838a5e794b3b72db494173f4502da60b58dec4383064964c0842932cd30e4251fc01ad0c28681e2ef6cb442482eea2bad595

…eanup'

fix: TODO related fixes for post-v20 release

81c09ee Unroll the ChaCha20 inner loop for performance (Pieter Wuille)

Pull request description:

  Unrolling the inner ChaCha20 loop gives a ~15% speedup for me in the CHACHA20_* benchmarks. It's a simple change, this performance helps with RNG generation, and will matter more for BIP324.

ACKs for top commit:
  martinus:
    tested ACK  81c09ee with clang++ 13.0.1, test `CHACHA20_1MB`:
  MarcoFalke:
    ACK 81c09ee 🍟

Tree-SHA512: 108bd0ba573bb08de92d611e7be7c09a2c2700f9655f44129b87f9b71f7e101dfc6bd345783e7b4b9b40f0b003913cf59187f422da8cdb5b20887f7855b2611a

fa77183 fuzz: Avoid OOM in system fuzz target (MarcoFalke)

Pull request description:

  If the inputs size is unlimited, the target may consume unlimited memory, because the argsmanager stores the argument names. Limiting the size should fix this issue.

  Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36906

ACKs for top commit:
  practicalswift:
    cr ACK fa77183

Tree-SHA512: 6edfcf324ee9d94e511038ee01340f02db50bcb233af3f1a1717c3602164c88528d9d987e971ec32f1a4593b868019bea0102c53c9b02bfefec3dfde959483cf

…re's and D. J. Bernstein's implementation of ChaCha20

4d0ac72 [fuzz] Add fuzzing harness to compare both implementations of ChaCha20 (stratospher)
65ef932 [fuzz] Add D. J. Bernstein's implementation of ChaCha20 (stratospher)

Pull request description:

  This PR compares Bitcoin Core's implementation of ChaCha20 with D. J. Bernstein's in order to find implementation discrepancies if any.

ACKs for top commit:
  laanwj:
    Code review ACK 4d0ac72

Tree-SHA512: f826144b4db61b9cbdd7efaaca8fa9cbb899953065bc8a26820a566303b2ab6a17431e7c114635789f0a63fbe3b65cb0bf2ab85baf882803a5ee172af4881544

8f79831 Refactor the chacha20 differential fuzz test (stratospher)

Pull request description:

  This PR addresses [comments from bitcoin#22704](https://github.com/bitcoin/bitcoin/pull/22704/files#discussion_r771510963)  to make the following changes in `src/test/fuzz/crypto_diff_fuzz_chacha20.cpp`:

  - replace `memcmp()` with ==
  - add a missing assert statement to compare the encrypted bytes

Top commit has no ACKs.

Tree-SHA512: 02338460fb3a89e732558bf00f3aebf8f04daba194e03ae0e3339bb2ff6ba35d06841452585b739047a29f8ec64f36b1b4ce2dfa39a08f6ad44a6a937e7b3acb

…arious improvements

511aa4f Add unit test for ChaCha20's new caching (Pieter Wuille)
fb243d2 Improve test vectors for ChaCha20 (Pieter Wuille)
93aee8b Inline ChaCha20 32-byte specific constants (Pieter Wuille)
62ec713 Only support 32-byte keys in ChaCha20{,Aligned} (Pieter Wuille)
f21994a Use ChaCha20Aligned in MuHash3072 code (Pieter Wuille)
5d16f75 Use ChaCha20 caching in FastRandomContext (Pieter Wuille)
38eaece Add fuzz test for testing that ChaCha20 works as a stream (Pieter Wuille)
5f05b27 Add xoroshiro128++ PRNG (Martin Leitner-Ankerl)
12ff724 Make unrestricted ChaCha20 cipher not waste keystream bytes (Pieter Wuille)
6babf40 Rename ChaCha20::Seek -> Seek64 to clarify multiple of 64 (Pieter Wuille)
e37bcaa Split ChaCha20 into aligned/unaligned variants (Pieter Wuille)

Pull request description:

  This is an alternative to bitcoin#25354 (by my benchmarking, somewhat faster), subsumes bitcoin#25712, and adds additional test vectors.

  It separates the multiple-of-64-bytes-only "core" logic (which becomes simpler) from a layer around which performs caching/slicing to support arbitrary byte amounts. Both have their uses (in particular, the MuHash3072 code can benefit from multiple-of-64-bytes assumptions), plus the separation results in more readable code. Also, since FastRandomContext effectively had its own (more naive) caching on top of ChaCha20, that can be dropped in favor of ChaCha20's new built-in caching.

  I thought about rebasing bitcoin#25712 on top of this, but the changes before are fairly extensive, so redid it instead.

ACKs for top commit:
  ajtowns:
    ut reACK 511aa4f
  dhruv:
    tACK crACK 511aa4f

Tree-SHA512: 3aa80971322a93e780c75a8d35bd39da3a9ea570fbae4491eaf0c45242f5f670a24a592c50ad870d5fd09b9f88ec06e274e8aa3cefd9561d623c63f7198cf2c7

backport: Merge bitcoin#24946, bitcoin#22649, bitcoin#22704, bitcoin#23806, bitcoin#26153

## Issue being fixed or feature implemented
Should fix crashes like
```
: Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
Assertion failure:
  assertion: globalInstance == nullptr
  file: mnhftx.cpp, line: 43
  function: CMNHFManager
   0#: (0x105ADA27C) stacktraces.cpp:629  - __assert_rtn
   1#: (0x104945794) mnhftx.cpp:43        - CMNHFManager::CMNHFManager(CEvoDB&)
   2#: (0x10499DA90) compressed_pair.h:40 - std::__1::__unique_if<CMNHFManager>::__unique_single std::__1::make_unique[abi:v15006]<CMNHFManager, CEvoDB&>(CEvoDB&)
   3#: (0x10499753C) init.cpp:1915        - AppInitMain(std::__1::variant<std::__1::nullopt_t, std::__1::reference_wrapper<NodeContext>, std::__1::reference_wrapper<WalletContext>, std::__1::reference_wrapper<CTxMemPool>, std::__1::reference_wrapper<ChainstateManager>, std::__1::reference_wrapper<CBlockPolicyEstimator>, std::__1::reference_wrapper<LLMQContext>> const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*)
```

## 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
Non-deterministic IS locks aren't used anymore since v18 dip24.
We should drop that support to make code simpler.

## What was done?
Dropped non-deterministic IS code, `evo_instantsend_tests` and
`feature_llmq_is_migration.py` (don't need it anymore), adjusted func
tests.

## How Has This Been Tested?
all tests, synced Testnet

## 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
- [ ] 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 <[email protected]>
Co-authored-by: Konstantin Akimov <[email protected]>

… always dashpay/dash (dashpay#5716)

## Issue being fixed or feature implemented
In order to provide nightly builds over at dash-dev-branches we need to
be able to run this automation with other REPOs

## What was done?
Make it repo specific.

## How Has This Been Tested?
Hasn't yet

## 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
- [ ] 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 compilation errors like
```
masternode/meta.cpp:43:9: error: call to member function 'pushKV' is ambiguous
    ret.pushKV("lastOutboundAttemptElapsed", now - lastOutboundAttempt);
    ^~
masternode/meta.cpp:45:9: error: call to member function 'pushKV' is ambiguous
    ret.pushKV("lastOutboundSuccessElapsed", now - lastOutboundSuccess);
    ^~
```
on FreeBSD + clang-15

kudos to @MrDefacto for finding the issue and testing the fix


## What was done?
Specify `now` variable type explicitly instead of relying on `auto`


## How Has This Been Tested?
MrDefacto confirmed it compiles with no issues on FreeBSD now

## 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)_

…Schnorr

notes:
- excludes changes done to `SignSchnorr`

taken from changes made to `configure.ac` in 0664f5f (bitcoin#19953)

excludes
- 314195c

excludes:
- d960d4f
- 404c530

…m secp256k1 changes

…on 0.2.0

notes:
- excludes changes made to `SignSchnorr`, `XOnlyPubKey`, kernel context and absent {fuzz,bench} tests

… v0.3.0

excludes:
- 719a749
- 621c178

backport: merge bitcoin#27479, bitcoin#27230, bitcoin#25251, partial bitcoin#22934, bitcoin#23383, bitcoin#24792, bitcoin#26691, bitcoin#27445 (secp256k1 update)

chore: Merge master 20.0.1 back into develop

…dashpay#5724)

## Issue being fixed or feature implemented
Should hopefully fix
https://github.com/dashpay/dash-dev-branches/actions/runs/6939402277/job/18876687119

dashpay#5716 follow-up

## What was done?
`$GITHUB_REPOSITORY` is not available inside docker, pass it inside

## 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)_

…lity

08bd338 build: optimise arm64 darwin qt build using -O1 (fanquake)

Pull request description:

  Building the macOS M1 bitcoin-qt binary at a optimisation level higher than `-O1` causes reproducibility issues when building on different architectures.

  Proposing somewhat of a hammer.

  This would fix 1 of the 2 remaining HOSTS in bitcoin#21194.

  Guix Build (x86_64):
  ```bash
  1b58b5109b32dca2509499c93347148e6bab5dca835081f8cbd3123bed72cce1  guix-build-08bd3382777b/output/arm64-apple-darwin/SHA256SUMS.part
  0e0d063d3832fad7c5116dabb2ac33c919f40bda04759aad4523c6247295bc9e  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin-unsigned.dmg
  1feb301245f2c664edcfd9ac528fe1543fc7b183b3b42637db77d57658bc2b5e  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin-unsigned.tar.gz
  641eb100d0a281203f9d6e36e45dc0ffc772c680d6aec462434f106b4c44e295  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin.tar.gz
  9d89920626e35939aa6cf506fc85861179f3c0e18d4ef1954750cf81336a851a  guix-build-08bd3382777b/output/dist-archive/bitcoin-08bd3382777b.tar.gz
  e7697d30084270d0b5843b3baf0d752e240c2f708f728bc2f6896f153276ca6b  guix-build-08bd3382777b/output/x86_64-apple-darwin/SHA256SUMS.part
  dd77acee082dbfd3cdad2c564bbd3bdace8df9bf32f92cf4a2debd5a996ace49  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin-unsigned.dmg
  85e63fccb7af12468a04a678034c42dcd775d243b2d194a52e1086a6ffbdbe84  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin-unsigned.tar.gz
  ff2629957608898d76a42025985e3ec4bf5dc8572794e32b4182ba6f8babb828  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin.tar.gz
  ```

  Guix Build (arm64):
  ```bash
  1b58b5109b32dca2509499c93347148e6bab5dca835081f8cbd3123bed72cce1  guix-build-08bd3382777b/output/arm64-apple-darwin/SHA256SUMS.part
  0e0d063d3832fad7c5116dabb2ac33c919f40bda04759aad4523c6247295bc9e  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin-unsigned.dmg
  1feb301245f2c664edcfd9ac528fe1543fc7b183b3b42637db77d57658bc2b5e  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin-unsigned.tar.gz
  641eb100d0a281203f9d6e36e45dc0ffc772c680d6aec462434f106b4c44e295  guix-build-08bd3382777b/output/arm64-apple-darwin/bitcoin-08bd3382777b-arm64-apple-darwin.tar.gz
  9d89920626e35939aa6cf506fc85861179f3c0e18d4ef1954750cf81336a851a  guix-build-08bd3382777b/output/dist-archive/bitcoin-08bd3382777b.tar.gz
  e7697d30084270d0b5843b3baf0d752e240c2f708f728bc2f6896f153276ca6b  guix-build-08bd3382777b/output/x86_64-apple-darwin/SHA256SUMS.part
  dd77acee082dbfd3cdad2c564bbd3bdace8df9bf32f92cf4a2debd5a996ace49  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin-unsigned.dmg
  85e63fccb7af12468a04a678034c42dcd775d243b2d194a52e1086a6ffbdbe84  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin-unsigned.tar.gz
  ff2629957608898d76a42025985e3ec4bf5dc8572794e32b4182ba6f8babb828  guix-build-08bd3382777b/output/x86_64-apple-darwin/bitcoin-08bd3382777b-x86_64-apple-darwin.tar.gz
  ```

ACKs for top commit:
  hebasto:
    ACK 08bd338
  jarolrod:
    ACK 08bd338

Tree-SHA512: 48da4acb1799c3153cdaf674f287c81c3da230a3476183616b74f318baa595af45b313136eb228ba13c63e0b8206a78064734f9fd0488e1e839c9e4e1d92ba25

0a5723b macdeploy: cleanup .temp.dmg if present (fanquake)
ecffe86 macdeploy: remove qt4 related code (fanquake)
639f064 macdeploy: select the plugins we need, rather than excluding those we don't (fanquake)
3d26b6b macdeploy: fix framework printing when passing -verbose (fanquake)
dca6c90 macdeploy: remove unused plistlib import (fanquake)

Pull request description:

  This includes [one followup](bitcoin#20422 (comment)) and [one bug fix](bitcoin@3d26b6b) from bitcoin#20422, as well as some simplifications to the `macdeployqtplus` code.

ACKs for top commit:
  hebasto:
    ACK 0a5723b, tested on macOS Big Sur 11.4 (20F71, x86_64) + Homebrew's Qt 5.15.2.

Tree-SHA512: cfad9505eacd32fe3a9d06eb13b2de0b6d2cad7b17778e90b503501cbf922e53d4e7f7f74952d1aed58410bdae9b0bb3248098583ef5b85689cb27d4dc06c029

…ith system frameworks

1513727 build, qt: (Re-)sign package (Hennadii Stepanov)
c26a0a5 build, qt: Align frameworks with macOS codesign tool requirements (Hennadii Stepanov)

Pull request description:

  Fixes bitcoin#22403

  This PR follows Apple [docs](https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-universal-apps-release-notes):
  >  - New in macOS 11 on Macs with Apple silicon, and starting in macOS Big Sur 11 beta 6, the operating system enforces that any executable must be signed before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature is sufficient...
  >  - ... If you use a custom workflow involving tools that modify a binary after linking (e.g. `strip` or `install_name_tool`) you might need to manually call `codesign` as an additional build phase to properly ad-hoc sign your binary. These new signatures are not bound to the specific machine that was used to build the executable, they can be verified on any other system and will be sufficient to comply with the new default code signing requirement on Macs with Apple silicon...

  When building with system Qt frameworks (i.e., without depends), a new string has been added to the `make deploy` log on M1-based macOS:
  ```
  % make deploy
  ...
  + Generating .DS_Store +
  dist/Bitcoin-Qt.app: replacing existing signature
  + Preparing .dmg disk image +
  ...
  ```

  This PR does not change build system behavior:
  - when building with depends
  - on Intel-based macOS

ACKs for top commit:
  jarolrod:
    ACK 1513727
  fanquake:
    ACK 1513727 - although didn't test on M1 hardware. Given the forced signing is scoped to only occur when running the deploy script on macOS, this doesn't interfere with our release signing.

Tree-SHA512: 3aa778fdd6ddb54f029f632f2fe52c2ae3bb197ba564cb776493aa5c3a655bd51d10ccbe6c007372d717e9b01fc4193dd5c29ea0bc7e069dcae7e991ae259f0c

3d41521 build: perform /Applications symlink generation in macdeployqtplus (fanquake)
dac6936 build: perform all .tiff copying in macdeployqtplus (fanquake)

Pull request description:

  Rather than maintaining 2 different versions of the same code (`.tiff` copying and symlink generation), consolidate to just the Python code, and use it on macOS and Linux. Previously Linux would  perform the 2 actions in the makefile, and then would still be running the `macdeployqtplus` script, so it makes sense to further consolidate deployment operations into the script.

  Guix Build (on x86_64):
  ```bash
  23343f04c426c7ff078afae4e600a7028970d4d86eed8b7834696d9e4d684151  guix-build-3d415215699e/output/arm64-apple-darwin/SHA256SUMS.part
  c28b2a2e4888bf84369aa25804e2576347d5ab09416354ec8b95c76a9d38ff96  guix-build-3d415215699e/output/arm64-apple-darwin/bitcoin-3d415215699e-arm64-apple-darwin-unsigned.dmg
  9a57077b2bd722a7d85d26b66cbce5abdb791985fe9d9d37e884c79ba8751e24  guix-build-3d415215699e/output/arm64-apple-darwin/bitcoin-3d415215699e-arm64-apple-darwin-unsigned.tar.gz
  d2b06dc5b86541798ace41dab569849f7403e7ff9ec329bda671ec84e6fad549  guix-build-3d415215699e/output/arm64-apple-darwin/bitcoin-3d415215699e-arm64-apple-darwin.tar.gz
  608e7d51a44ab9c5b28eb3703a0f4fe98b4adff22c77a5502786b84bd96cc188  guix-build-3d415215699e/output/dist-archive/bitcoin-3d415215699e.tar.gz
  3e483705b1f9f1fb8f6afedc8ad0214a6cb00e77f766c0b03c42d56f410d4362  guix-build-3d415215699e/output/x86_64-apple-darwin/SHA256SUMS.part
  9370e3e3b7d47b5a44e64554cf3b6d7e0671b072c08cd251eacc7ec72ce2b53f  guix-build-3d415215699e/output/x86_64-apple-darwin/bitcoin-3d415215699e-x86_64-apple-darwin-unsigned.dmg
  ad0f68682d78c311497669fc3d627138be37510215d259b5f0b686d93e7d83b7  guix-build-3d415215699e/output/x86_64-apple-darwin/bitcoin-3d415215699e-x86_64-apple-darwin-unsigned.tar.gz
  e09dce4ff692ef66d1f4818083c1880bcf3a79c53112561d9e929bb6e5ffc011  guix-build-3d415215699e/output/x86_64-apple-darwin/bitcoin-3d415215699e-x86_64-apple-darwin.tar.gz
  ```

ACKs for top commit:
  laanwj:
    Re-ACK 3d41521

Tree-SHA512: 80dd66a6e94c5b3e8823ccb57dcb08a8851a1e70a154b62385443f8d2d5ed5af900a0ac5003143959863586f1c7b90002fe6bff3ca5e37697253e051f69d7629

dba1231 test: previous releases: add v23.0 (Sjors Provoost)

Pull request description:

  Follows the same pattern as d8b705f (v22.0) and 8a57a06 (v0.21.0).

  Starting from v23.0 there is a separate macOS release for x86_64 and aarch64.

ACKs for top commit:
  prusnak:
    Approach ACK dba1231

Tree-SHA512: 249aeddd5e80e163578581e5c8e9b6579f3694abc3d1fb68dddb7b42d75021ad85266688ec4a365a6631d82a65a19873aff7ba61c0ea59d21f8adbe4b772dc16

…'t run unsigned arm64 binaries; self-sign when needed

dc12f2e test: improve error msg on previous release tarball extraction failure (kdmukai)
7121fd8 test: self-sign previous release binaries for arm64 macOS (kdmukai)

Pull request description:

  ## The Problem
  If you run `test/get_previous_releases.py -b` on an M1 or M2 mac, you'll get an unsigned v23.0 binary in the arm64 tarball. macOS [sets stricter requirements on ARM binaries](https://news.ycombinator.com/item?id=26996578) so the unsigned arm64 binary is apparently completely unusable without being signed/notarized(?).

  This means that any test that depends on a previous release (e.g. `wallet_backwards_compatibility.py`) will fail because the v23.0 node cannot launch:

  ```
  TestFramework (ERROR): Assertion failed
  Traceback (most recent call last):
    File "/Users/kdmukai/dev/bitcoin-core/test/functional/test_framework/test_framework.py", line 563, in start_nodes
      node.wait_for_rpc_connection()
    File "/Users/kdmukai/dev/bitcoin-core/test/functional/test_framework/test_node.py", line 231, in wait_for_rpc_connection
      raise FailedToStartError(self._node_msg(
  test_framework.test_node.FailedToStartError: [node 2] bitcoind exited with status -9 during initialization
  ```

  This can also be confirmed by downloading bitcoin-23.0-arm64-apple-darwin.tar.gz (https://bitcoincore.org/bin/bitcoin-core-23.0/) and trying to run any of the binaries manually on an M1 or M2 mac.

  ## Solution in this PR
  (UPDATED) Per @ hebasto, we can self-sign the arm64 binaries. This PR checks each binary in the previous release's "bin/" and verifies if the arm64 binary is signed. If not, attempt to self-sign and confirm success.

  (note: an earlier version of this PR downloaded the x86_64 binary as a workaround but this approach has been discarded)

  ## Longer term solution
  If possible, produce signed arm64 binaries in a future v23.x tarball?

  Note that this same problem affects the new v24.0.1 arm64 tarball so perhaps a signed v24.x.x tarball would also be ideal?

  That being said, this PR will check all current and future arm64 binaries and self-sign as needed, so perhaps we need not worry about pre-signing the tarball binaries. And I did test a version of `get_previous_releases.py` that includes the new v24.0.1 binaries and it successfully self-signed both v23.0 and v24.0.1, as expected.

  ## Further info:
  Somewhat related to: bitcoin#15774 (comment)

  And @ fanquake noted on IRC that you can confirm which binaries are or are not signed via:
  ```
  $ codesign -v -d bitcoin-qt
  bitcoin-qt: code object is not signed at all
  ```

ACKs for top commit:
  hebasto:
    ACK dc12f2e

Tree-SHA512: 644895f8e97f5ffb3c4754c1db2c48abd77fa100c2058e3c896af04806596fc2b9c807a3f3a2add5be53301ad40ca2b8171585bd254e691f6eb38714d938396b

979271a macdeploy: remove unused detached-sig-apply (fanquake)

Pull request description:

  Signature application is now done with signapple.

  https://github.com/bitcoin/bitcoin/blob/8435d7f11a89bb3f93306646f62cc2179693e072/contrib/guix/libexec/codesign.sh#L84-L85

ACKs for top commit:
  laanwj:
    ACK 979271a
  gruve-p:
    ACK bitcoin@979271a
  achow101:
    ACK 979271a
  hebasto:
    ACK 979271a, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: ab51a609d00cead4f33bcfc5b5ff1008ee02363ab1f4c4bf9544631069c237bfa92eac4dfa231bff8a1d702bda6cc92b4151361f74f58e77b595e0cb82a8391a

…6_64-apple-darwin platform

backport: bitcoin#24603, bitcoin#26694, bitcoin#24669, bitcoin#22546, bitcoin#22199, bitcoin#25817 (mac build)

…shpay#5725)

## Issue being fixed or feature implemented
- The name `CB_V19_VERSION` is confusing because CbTx v2 was introduced
in v14, not v19
https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.md#dip0004---coinbase-payload-v2
- There are magic numbers instead of constants in some places
- `CheckCbTx` should check whatever the upper limit is, not
`CB_V20_VERSION` specifically

## What was done?
Turn CbTx versions into enum using self-describing names

## 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)_

…ninterface

7777f2a miner: Avoid stack-use-after-return in validationinterface (MarcoFalke)
fa5ceb2 test: Remove UninterruptibleSleep from test and replace it by SyncWithValidationInterfaceQueue (MarcoFalke)
fa770ce validationinterface: Rework documentation, Rename pwalletIn to callbacks (MarcoFalke)
fab6d06 test: Add unregister_validation_interface_race test (MarcoFalke)

Pull request description:

  When a validationinterface has itself unregistered in one thread, but is about to get executed in another thread [1], there is a race:

  * The validationinterface destructing itself
  * The validationinterface getting dereferenced for execution

  [1] https://github.com/bitcoin/bitcoin/blob/64139803f1225dab26197a20314109d37fa87d5f/src/validationinterface.cpp#L82-L83

  This happens in the miner. More generally it happens everywhere where at least one thread is generating notifications and another one is unregistering a validationinterface.

  This issue has been fixed in commit ab31b9d, but the fix has not been applied to the miner.

  Example where this happened in practice: https://travis-ci.org/github/bitcoin/bitcoin/jobs/675322230#L4414

ACKs for top commit:
  promag:
    Code review ACK 7777f2a.
  laanwj:
    Code review ACK 7777f2a

Tree-SHA512: 8087119243c71ba18a823a63515f3730d127162625d8729024278b447af29e2ff206f4840ee3d90bf84f93a2c5ab73b76c7e7044c83aa93b5b51047a166ec3d3

…nts in validationinterface_tests

faca9a3 test: Avoid intermittent issues due to async events in validationinterface_tests (MarcoFalke)

Pull request description:

  Currently the tests have many issues:

  * They setup the genesis block, even though it is not needed
  * They queue an async `UpdatedBlockTip` even, which causes intermittent issues: bitcoin#28146 (comment)

  Fix all issues by trimming down the setup to just `ChainTestingSetup`.

ACKs for top commit:
  Crypt-iQ:
    tACK faca9a3

Tree-SHA512: 4449040330f89bbaf5ce5b2052417c160b451c373987fdf1069596c07834ed81f0aea1506d53c7d2cd21062b27332d30679285dae194b272fd0cb9ce5ded32cf

backport: bitcoin#18742, bitcoin#28150

dashpay#5732)

## Issue being fixed or feature implemented
dashpay#4788 (comment)

noticed while working on dashpay#5731

## What was done?

## How Has This Been Tested?
run a node, check logs - there is a meaningful time span between `start`
and `done` now and not just zeros all the time.

## 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

## 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
- [ ] 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: PastaPastaPasta <[email protected]>

…ay#5710)

## Issue being fixed or feature implemented
Our [Release Process document](doc/release-process.md) is not exactly
matched with our [template
issue](dashpay#5694) that created by
copy-paste from previous release.

For the next release just copy test from this document to new issue

## What was done?
[Release Process document](doc/release-process.md) is updated to match
with our real release process.
This document has also detailed instructions for many steps (in compare
to the issue that we use now which is more checklist) to make releasing
process easier for all participant.

## How Has This Been Tested?
Tested on air by 2 last released: v19, v20:
dashpay#5694

## 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
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: thephez <[email protected]>
Co-authored-by: UdjinM6 <[email protected]>

## Issue being fixed or feature implemented
Avoid a crash on -reindex-chainstate.

## What was done?
`ResetBlockFailureFlags` is crashing when `m_chain.Tip()` is null. Call
`ResetBlockFailureFlags` inside `if (!is_coinsview_empty(chainstate))
{...}` block - we know `m_chain.Tip()` is not null there.

## How Has This Been Tested?
Try running a node with `-reindex-chainstate` cmd-line param w/ and
w/out 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)_

e48826a tests: remove ComputeBlockVersion shortcut from versionbits tests (Anthony Towns)
c5f3672 [refactor] Move ComputeBlockVersion into VersionBitsCache (Anthony Towns)
4a69b4d [move-only] Move ComputeBlockVersion from validation to versionbits (Anthony Towns)
0cfd6c6 [refactor] versionbits: make VersionBitsCache a full class (Anthony Towns)
8ee3e0b [refactor] rpc/blockchain.cpp: SoftForkPushBack (Anthony Towns)
92f48f3 deploymentinfo: Add DeploymentName() (Anthony Towns)
ea68b3a [move-only] Rename versionbitsinfo to deploymentinfo (Anthony Towns)
c64b2c6 scripted-diff: rename versionbitscache (Anthony Towns)
de55304 [refactor] Add versionbits deployments to deploymentstatus.h (Anthony Towns)
2b0d291 [refactor] Add deploymentstatus.h (Anthony Towns)
eccd736 versionbits: Use dedicated lock instead of cs_main (Anthony Towns)
36a4ba0 versionbits: correct doxygen comments (Anthony Towns)

Pull request description:

  Introduces helper functions to make it easy to bury future deployments, along the lines of the suggestion from [11398](bitcoin#11398 (comment)) "I would prefer it if a buried deployment wouldn't require all code paths that check the BIP9 status to require changing".

  This provides three functions: `DeploymentEnabled()` which tests if a deployment can ever be active, `DeploymentActiveAt()` which checks if a deployment should be enforced in the given block, and `DeploymentActiveAfter()` which checks if a deployment should be enforced in the block following the given block, and overloads all three to work both with buried deployments and versionbits deployments.

  This adds a dedicated lock for the versionbits cache, which is acquired internally by the versionbits functions, rather than relying on `cs_main`. It also moves moves versionbitscache into deploymentstatus to avoid a circular dependency with validation.

ACKs for top commit:
  jnewbery:
    ACK e48826a
  gruve-p:
    ACK bitcoin@e48826a
  MarcoFalke:
    re-ACK e48826a 🥈

Tree-SHA512: c846ba64436d36f8180046ad551d8b0d9e20509b9bc185aa2639055fc28803dd8ec2d6771ab337e80da0b40009ad959590d5772f84a0bf6199b65190d4155bed

backport: bitcoin#19438 Introduce deploymentstatus (versionbits improvements)

## Issue being fixed or feature implemented
Hopefully fixes issues like
>The job running on runner ubuntu-core-x64_i-05ed4263b8e049c7a has
exceeded the maximum execution time of 360 minutes

https://github.com/dashpay/dash/actions/runs/6932017275


https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes

## What was done?
Bump timeouts for the job itself and for the corresponding step. Also,
implemented caching for `.cache` and `depends` folders.

## How Has This Been Tested?
dashpay#5729


https://github.com/dashpay/dash/actions/runs/6996271543/job/19031968814?pr=5729

## 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)_

…5736)

Prior required changes: bitcoin#19438 from
dashpay#5740

## Issue being fixed or feature implemented
Assertion failure:
```
  assertion: ok
  file: evo/mnhftx.cpp, line: 287
  function: AbstractEHFManager::Signals CMNHFManager::GetFromCache(const CBlockIndex*)
No debug information available for stacktrace. You should add debug information and then run: dash-qt -printcrashinfo=bvcgc43iinzgc43ijfxgm3ybaadwiyltnawxc5e3ifzxgzlsoruw63ramzqws3dvojstucraebqxg43foj2gs33ohiqg62ykeaqgm2lmmu5cazlwn4xw23timz2hqltdobycyidmnfxgkoragi4docraebthk3tdoruw63r2ebawe43uojqwg5cfjbde2ylomftwk4r2hjjwsz3omfwhgicdjvheqrsnmfxgcz3foi5dur3fordhe33ninqwg2dffbrw63ttoqqegqtmn5rwwslomrsxqkrjbyrelhyaaaaaaaedgkiaaaaaaaadsm4qaaaaaaaa7gpyqaaaaaaaa2njraaaaaaaadkl3caaaaaaaabhxznqaaaaaaadqa2eaaaaaaaax33twaaaaaaabwaihqaaaaaaac7yooqbaaaaaahba45qcaaaaaacwkz2aeaaaaaaeitgeaiaaaaaaaa=
dash-qt: evo/mnhftx.cpp:287: AbstractEHFManager::Signals CMNHFManager::GetFromCache(const CBlockIndex*): Assertion `ok' failed.
```

This can happen in case if Dash Core has been update from v19 (or
earlier v20.alphaX) to v20.0.0 after v20 activation without re-indexing

## What was done?
`CMNHFManager` is visiting missing blocks recursively until reach first
v20 block or first block actually saved in evoDb.


Without changes from bitcoin#19438 there's an other issue:
```
2023-11-27T11:12:10Z POTENTIAL DEADLOCK DETECTED
Previous lock order was:
 (2) 'cs_main' in llmq/instantsend.cpp:459 (in thread 'isman')
 (1) 'cs_llmq_vbc' in llmq/utils.cpp:711 (in thread 'isman')
Current lock order is:
 'cs_dip3list' in qt/masternodelist.cpp:135 (TRY) (in thread 'main')
 (1) 'cs_llmq_vbc' in llmq/utils.cpp:719 (in thread 'main')
 (2) 'cs_main' in node/blockstorage.cpp:77 (in thread 'main')
Assertion failed: detected inconsistent lock order for 'cs_main' in node/blockstorage.cpp:77 (in thread 'main'), details in debug log.
2023-11-27T11:12:10Z Posix Signal: Aborted
```

## How Has This Been Tested?
Run unit/functional test; run dash-qt on my local backup of problematic
storage (succeed without error); reindex testnet.

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

Adds missing changes from p2p_invalid_tx.py but one assert is still disabled

fa4c29b test: Add various low-level p2p tests (MarcoFalke)

Pull request description:

ACKs for top commit:
  jonatack:
    ACK fa4c29b

Tree-SHA512: 842821b97359d4747c763398f7013415858c18a300cd882887bc812d039b5cbb67b9aa6f68434575dbc3c52f7eb8c43d1b293a59555a7242c0ca615cf44dc0aa

… header is split across two buffers

80d4423 Test buffered valid message (Troy Giorshev)

Pull request description:

  This PR is a tweak of bitcoin#19302.  This sends a valid message.

  Additionally, this test includes logging in the same vein as bitcoin#19272.

ACKs for top commit:
  MarcoFalke:
    tested ACK 80d4423 (added an assert(false) to observe deterministic coverage) 🌦
  gzhao408:
    ACK bitcoin@80d4423 👊

Tree-SHA512: 3b1aa5ec480a1661917354788923d64595e2886448c9697ec0606a81293e8b4a4642b2b3cc9afb2206ce6f74e5c6d687308c5ad19cb73c5b354d3071ad8496f8

…e (naming)

…lock in an INV

7467366 [net processing] Only send a getheaders for one block in an INV (John Newbery)

Pull request description:

  Headers-first is the primary method of announcement on the network. If a node fell back sending blocks by inv, it's probably for a re-org. The final block hash provided should be the highest, so send a getheaders and then fetch the blocks we need to catch up.

  Sending many GETHEADERS messages to the peer would cause them to send a large number of potentially large HEADERS messages with redundant data, which is a waste of bandwidth.

ACKs for top commit:
  sipa:
    utACK 7467366
  mzumsande:
    utACK 7467366 as per ajtowns' reasoning.
  naumenkogs:
    utACK 7467366
  ajtowns:
    ACK 7467366
  jonatack:
    ACK 7467366

Tree-SHA512: 59e243b80d3f0873709dfacb2e4ffba34689aad7de31ec7f69a64e0e3a0756235a0150e4082ff5de823949ba4411ee1aed2344b4749b62e0eb1ea906e41f5ea9

…g include

83da576 net: use CMessageHeader::HEADER_SIZE, add missing include (Jon Atack)

Pull request description:

  as suggested 16 months ago by Gleb Naumenko in bitcoin#15197 (comment).

  `static constexpr CMessageHeader::HEADER_SIZE` is already used in this file, `src/net.cpp`, in 2 instances. This commit replaces the remaining 2 integer values in the file with it and adds the explicit include header.

  Co-authored by: Gleb Naumenko <[email protected]>

ACKs for top commit:
  naumenkogs:
    utACK 83da576
  practicalswift:
    ACK 83da576 -- patch looks correct
  theStack:
    ACK 83da576 -- verified that its just magic number elimination refactoring and additionally checked that all tests pass 👍

Tree-SHA512: 5b915483bca4ea162c259865a1b615d73b88a1b1db3f82db05f770d10b8a42494d948f5b21badbcce2d9efa5915b8cbb6af83073867c23d2f152c0d35ac37b96

2896c41 Do not answer GETDATA for to-be-announced tx (Pieter Wuille)
f2f32a3 Push down use of cs_main into FindTxForGetData (Pieter Wuille)
c6131bf Abstract logic to determine whether to answer tx GETDATA (Pieter Wuille)

Pull request description:

  This PR intends to improve transaction-origin privacy.

  In general, we should try to not leak information about what transactions we have (recently) learned about before deciding to announce them to our peers. There is a controlled transaction dissemination process that reveals our transactions to peers that has various safeguards for privacy (it's rate-limited, delayed & batched, deterministically sorted, ...), and ideally there is no way to test which transactions we have before that controlled process reveals them. The handling of the `mempool` BIP35 message has protections in this regard as well, as it would be an obvious way to bypass these protections (handled asynchronously after a delay, also deterministically sorted).

  However, currently, if we receive a GETDATA for a transaction that we have not yet announced to the requester, we will still respond to it if it was announced to *some* other peer already (because it needs to be in `mapRelay`, which only happens on the first announcement). This is a slight privacy leak.

  Thankfully, this seems easy to solve: `setInventontoryTxToSend` keeps track of the txids we have yet to announce to a peer - which almost(*) exactly corresponds to the transactions we know of that we haven't revealed to that peer. By checking whether a txid is in that set before responding to a GETDATA, we can filter these out.

  (*) Locally resubmitted or rebroadcasted transactions may end up in setInventoryTxToSend while the peer already knows we have them, which could result in us incorrectly claiming we don't have such transactions if coincidentally requested right after we schedule reannouncing them, but before they're actually INVed. This is made even harder by the fact that filterInventoryKnown will generally keep known reannouncements out of setInventoryTxToSend unless it overflows (which needs 50000 INVs in either direction before it happens).

  The condition for responding now becomes:

  ```
    (not in setInventoryTxToSend) AND
    (
      (in relay map) OR
      (
        (in mempool) AND
        (old enough that it could have expired from relay map) AND
        (older than our last getmempool response)
      )
    )
  ```

ACKs for top commit:
  naumenkogs:
    utACK 2896c41
  ajtowns:
    ACK 2896c41
  amitiuttarwar:
    code review ACK 2896c41
  jonatack:
    ACK 2896c41 per `git diff 2b3f101 2896c41` only change since previous review is moving the recency check up to be verified first in `FindTxForGetData`, as it was originally in 353a391 (good catch), before looking up the transaction in the relay pool.
  jnewbery:
    code review ACK 2896c41

Tree-SHA512: e7d5bc006e626f60a2c108a9334f3bbb67205ace04a7450a1e4d4db1d85922a7589e0524500b7b4953762cf70554c4a08eec62c7b38b486cbca3d86321600868

…tions from configure

d51f0fa doc: add release notes for 26896 (fanquake)
2b24879 build: remove --enable-upnp-default from configure (fanquake)
02f5a5e build: remove --enable-natpmp-default from configure (fanquake)
25a0e8b Remove configure-time setting of DEFAULT_UPNP (fanquake)
06562e5 Remove configure-time setting of DEFAULT_NATPMP (fanquake)

Pull request description:

  This PR removes the `--enable-upnp-default` and `--enable-natpmp-default` options from configure.

  It's odd to me that we maintain configure-time options for setting the default port-forwarding runtime state (but no other similar options), and I'm not sure what use-case it satisfies, that can't be achieved by multiple other means. I also doubt that we'll ever restart using these in release builds, or turning on any of this by default.

  I think the only scenario these options would be used is when you want to compile your own binaries (we don't use them in Guix), with port-forwarding on by default, but otherwise can't or don't want to use a `.conf` file, can't or don't want to pass command line options at runtime, and also don't want to modify the source code?

ACKs for top commit:
  hebasto:
    ACK d51f0fa, rebased and comments have been addressed since my recent [review](bitcoin#26896 (review)).
  TheCharlatan:
    ACK d51f0fa

Tree-SHA512: 481decd8bddd8b03b7319591e3acf189f7b6b96c9a9a8c5bc1a3f8ec00d0b8f9b52d2f5c28a298a2ec947cfe9611cfd184e393ccb2e4e21bfce86ca7d4de60d3

fabe44e bench: Start nodes with -nodebuglogfile (MarcoFalke)

Pull request description:

  For benchmarking we don't want to depend on the speed of the disk or the amount of debug logging

ACKs for top commit:
  fanquake:
    ACK fabe44e - This makes some of these benchmarks significantly faster to run. MempoolEviction total runtime is down from ~46s to 11s on my machine:

Tree-SHA512: d99700901650325896b9115d20b84a27042152f46266f595bf7ea1414528c0b346f4e707a12ee8b8ba99c35cf155e645e67971c1b2a679c4e609c400ff8b08ae

…num opcode serialize

2748e87 script: prevent UB when computing abs value for num opcode serialize (pierrenn)

Pull request description:

  This was reported by practicalswift here bitcoin#18046

  It seems that the original author of the line used a reference to glibc `abs`: https://github.com/lattera/glibc/blob/master/stdlib/abs.c

  However depending on some implementation details this can be undefined behavior for unusual values.

  A detailed explanation of the UB is provided here : https://stackoverflow.com/questions/17313579/is-there-a-safe-way-to-get-the-unsigned-absolute-value-of-a-signed-integer-with (by [Billy O'Neal](https://twitter.com/malwareminigun))

  Simple relevant godbolt example :  https://godbolt.org/z/yRwtCG

  Thanks!

ACKs for top commit:
  sipa:
    ACK 2748e87
  MarcoFalke:
    ACK 2748e87, only checked that the bitcoind binary does not change with clang -O2 🎓
  practicalswift:
    ACK 2748e87

Tree-SHA512: 539a34c636c2674c66cb6e707d9d0dfdce63f59b5525610ed88da10c9a8d59d81466b111ad63b850660cef3750d732fc7755530c81a2d61f396be0707cd86dec

…owngrade after upgrade

489ebfd tests: feature_backwards_compatibility.py test downgrade after upgrade (Andrew Chow)

Pull request description:

  After upgrading the node, try to go back to the original version to make sure that using a newer node version does not prevent the wallet file from being downgraded again.

ACKs for top commit:
  MarcoFalke:
    ACK 489ebfd

Tree-SHA512: 86231de6514b3657912fd9d6621212166fd2b29b591fc97120092c548babcf1d6f50b5bd103b28cecde395a26809134f01c1a198725596c3626420de3fd1f017

backport: bitcoin#18413, bitcoin#18610, bitcoin#18759, bitcoin#18855, bitcoin#18861, bitcoin#18931, bitcoin#18962, bitcoin#19304, bitcoin#26896, partial bitcoin#18628

…tAddr const

fae108c Fix incorrect whitespace in addrman (MarcoFalke)
fa32024 Add missing GUARDED_BY to CAddrMan::insecure_rand (MarcoFalke)
fab755b fuzz: Actually use const addrman (MarcoFalke)
fae0c79 refactor: Mark CAddrMan::GetAddr const (MarcoFalke)
fa02934 refactor: Mark CAddrMan::Select const (MarcoFalke)

Pull request description:

  To clarify that a call to this only changes the random state and nothing else.

ACKs for top commit:
  jnewbery:
    Code review ACK fae108c
  theStack:
    re-ACK fae108c 🍦

Tree-SHA512: 3ffb211d4715cc3daeb3bfcdb3fcc6b108ca96df5fa565510436fac0e8da86c93b30c9c4aad0563e27d84f615fcd729481072009a4e2360c8b3d40787ab6506a

…nt32_t instead of signed int

fa621ed refactor: Pass script verify flags as uint32_t (MarcoFalke)

Pull request description:

  The flags are cast to unsigned in the interpreter anyway, so avoid the confusion (and fuzz crashes) by just passing them as unsigned from the beginning.

  Also, the flags are often inverted bit-wise with the `~` operator, which also works on signed integers, but might cause confusion as the sign bit is flipped.

  Fixes bitcoin#22233

ACKs for top commit:
  theStack:
    Concept and code review ACK fa621ed
  kristapsk:
    ACK fa621ed
  jonatack:
    ACK fa621ed

Tree-SHA512: ea0720f32f823fa7f075309978672aa39773c6019d12b6c1c9d611fc1983a76115b7fe2a28d50814673bb6415c311ccc05b99d6e871575fb6900faf75ed17769

…t from Good()

f036dfb [addrman] Remove unused test_before_evict argument from Good() (John Newbery)

Pull request description:

  This has never been used in the public interface method since it was
  introduced in bitcoin#9037.

ACKs for top commit:
  lsilva01:
    Tested ACK bitcoin@f036dfb on Ubuntu 20.04.
  theStack:
    Code-review ACK f036dfb

Tree-SHA512: 98145d9596b4ae1f354cfa561be1a54c6b8057c920e0ac3d4c1d42c9326b2dad2d44320f4171bb701d97088b216760cca8017b84c8b5dcd2b1dc8f158f28066d

20edf4b rpc: Return block time in getblockchaininfo (João Barbosa)

Pull request description:

  Return tip time in `getblockchaininfo`, for some use cases this can save a call to `getblock`.

ACKs for top commit:
  naumenkogs:
    ACK 20edf4b
  theStack:
    re-ACK 20edf4b
  0xB10C:
    ACK 20edf4b
  kristapsk:
    ACK 20edf4b
  Zero-1729:
    re-ACK 20edf4b

Tree-SHA512: 29a920cfff1ef53e0af601c3f93f8f9171f3be47fc84b0fa293cb865b824976e8c1510b17b27d17daf0b8e658dd77d9dc388373395f0919fc4a23cd5019642d5

…y in block chain'

2ebf2fe test: check for RPC error 'Transaction already in block chain' (-27) (Sebastian Falbesoner)

Pull request description:

  This PR adds missing test coverage for the RPC error "Transaction already in block chain" (error code `RPC_VERIFY_ALREADY_IN_CHAIN` = `RPC_TRANSACTION_ALREADY_IN_CHAIN` = -27), which is thrown in the function `BroadcastTransaction` (src/node/transaction.cpp).

ACKs for top commit:
  kristapsk:
    ACK 2ebf2fe (ran linter, looked at changes and ran modified test and checked code in `src/node/transaction.cpp`)
  darosior:
    ACK 2ebf2fe

Tree-SHA512: 8bfbd3ff3da0cb3b8745f69b8ca2377f85fa99f0270750840b60e6ae43b5645c5c59b236993e8b2ad0444ec4171484e4f1ee23fa7e81b79d4222bcb623666fa5

…ransaction

78f4c8b prefer to use txindex if available for GetTransaction (Jameson Lopp)

Pull request description:

  Fixes bitcoin#22382

  Motivation: prevent excessive disk reads if txindex is enabled.

  Worth noting that this could be argued to be less of a bug and more of an issue of undefined behavior. If a user calls GetTransaction with the wrong block hash, what should happen?

ACKs for top commit:
  jonatack:
    ACK 78f4c8b
  theStack:
    Code review ACK 78f4c8b
  LarryRuane:
    tACK 78f4c8b
  luke-jr:
    utACK 78f4c8b
  jnewbery:
    utACK 78f4c8b
  rajarshimaitra:
    Code review ACK bitcoin@78f4c8b
  lsilva01:
    Code Review ACK and Tested ACK bitcoin@78f4c8b on Ubuntu 20.04

Tree-SHA512: af7db5b98cb2ae4897b28476b2fa243bf7e6f850750d9347062fe8013c5720986d1a3c808f80098e5289bd84b085de03c81a44e584dc28982f721c223651bfe0

…dationcache_tests

c3e111a Reduced number of validations in `tx_validationcache_tests` to keep the run time reasonable. (lucash-dev)

Pull request description:

  Following a suggestion in the comments, changed `ValidateCheckInputsForAllFlags` from testing all possible flag combinations to testing a random subset. Also created a new enum constant for the highest flag, so that this test doesn’t keep testing an incomplete subset in case a new flag is added.

  Timing for `checkinputs_test`:
  ```
  Before:   6.8s
  After:    3.7s
  ----------------
  Saved:    3.1s (45%)
  ```

  This PR was split from bitcoin#13050. Also see bitcoin#10026.

ACKs for top commit:
  leonardojobim:
    tACK bitcoin@c3e111a.
  kallewoof:
    ACK c3e111a
  theStack:
    re-ACK c3e111a

Tree-SHA512: bef49645bdd4f61ec73cc77a9f028b95d9856db9446d2e7fc9a48867a6f0e94c2c9f150cb771a30fe852db0efb0a1bd15d38b00d712651793ccb59ff6157a7b4

…n.cpp

f685a13 doc: GetTransaction()/getrawtransaction follow-ups to bitcoin#22383 (John Newbery)
abc57e1 refactor: move `GetTransaction(...)` to node/transaction.cpp (Sebastian Falbesoner)

Pull request description:

  ~This PR is based on bitcoin#22383, which should be reviewed first~ (merged by now).

  In [yesterday's PR review club session to PR 22383](https://bitcoincore.reviews/22383), the idea of moving the function `GetTransaction(...)` from src/validation.cpp to src/node/transaction.cpp came up. With this, the circular dependency "index/txindex -> validation -> index/txindex" is removed (see change in `lint-circular-dependencies.sh`). Thanks to jnewbery for suggesting and to sipa for providing historical background.

  Relevant IRC log:
  ```
  17:52 <jnewbery> Was anyone surprised that GetTransaction() is in validation.cpp? It seems to me that node/transaction.cpp would be a more appropriate place for it.
  17:53 <raj_> jnewbery, +1
  17:53 <stickies-v> agreed!
  17:54 <glozow> jnewbery ya
  17:54 <jnewbery> seems weird that validation would call into txindex. I wonder if we remove this function, then validation would no longer need to #include txindex
  17:54 <sipa> GetTransaction predates node/transaction.cpp, and even the generic index framework itself :)
  17:55 <sipa> (before 0.8, validation itself used the txindex)
  17:55 <jnewbery> (and GetTransaction() seems like a natural sibling to BroadcastTransaction(), which is already in node/transaction.cpp)
  17:55 <jnewbery> sipa: right, this is not meant as a criticism of course. Just wondering if we can organize things a bit more rationally now that we have better separation between things.
  17:55 <sipa> jnewbery: sure, just providing background
  17:56 <sipa> seems very reasonable to move it elsewhere now
  ```

  The commit should be trivial to review with `--color-moved`.

ACKs for top commit:
  jnewbery:
    Code review ACK f685a13
  rajarshimaitra:
    tACK bitcoin@f685a13
  mjdietzx:
    crACK f685a13
  LarryRuane:
    Code review, test ACK f685a13

Tree-SHA512: 0e844a6ecb1be04c638b55bc4478c2949549a4fcae01c984eee078de74d176fb19d508fc09360a62ad130677bfa7daf703b67870800e55942838d7313246248c

198ceb8 script, doc: guix touchups (jonatack)
d7b7f61 Updated Readme, Corrected the codesign typo (h)

Pull request description:

ACKs for top commit:
  jamesob:
    ACK bitcoin@198ceb8
  jonatack:
    ACK 198ceb8

Tree-SHA512: 408360cebb51cff330fdd5d5d8ae91a168cdc99fb1377913fd9119e6eba536e58f87ff5c5b479e21a21fa3403323b137c338005bbd67e6fd24314929cdff9325

fbeb8c4 test: add type annotations to util.get_rpc_proxy (fanquake)

Pull request description:

  Split out from bitcoin#22092 while we address the functional test failure.

ACKs for top commit:
  instagibbs:
    ACK bitcoin@fbeb8c4

Tree-SHA512: 031ef8703202ae5271787719fc3fea8693574b2eb937ccf852875de95798d7fa3c39a8db7c91993d0c946b45d9b4d6de570bd1102e0344348784723bd84803a8

backport: Merge bitcoin#(partial) 21940,(partial) 22232,22505,22407,22510,22383,13533,22528,22538,22139

d596dba test: assert logging categories are sorted in rpc and help (Jon Atack)
17bbff3 log, refactor: use guard clause in LogCategoriesList() (Jon Atack)
7c57297 log: sort LogCategoriesList and LogCategoriesString alphabetically (Jon Atack)
f720cfa test: verify number of categories returned by logging RPC (Jon Atack)

Pull request description:

  Sorting the logging categories seems more user-friendly with the number of categories we now have, allowing CLI users to more quickly find a particular category.

  before
  ```
  $ bitcoin-cli help logging
  ...
  The valid logging categories are: net, tor, mempool, http, bench, zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation, i2p, ipc

  $ bitcoind -h | grep -A8 "debug=<category>"
    -debug=<category>
         ...
         output all debugging information. <category> can be: net, tor,
         mempool, http, bench, zmq, walletdb, rpc, estimatefee, addrman,
         selectcoins, reindex, cmpctblock, rand, prune, proxy, mempoolrej,
         libevent, coindb, qt, leveldb, validation, i2p, ipc.

  $ bitcoin-cli logging [] '["addrman"]'
  {
    "net": false,
    "tor": true,
    "mempool": false,
    "http": false,
    "bench": false,
    "zmq": false,
    "walletdb": false,
    "rpc": false,
    "estimatefee": false,
    "addrman": false,
    "selectcoins": false,
    "reindex": false,
    "cmpctblock": false,
    "rand": false,
    "prune": false,
    "proxy": true,
    "mempoolrej": false,
    "libevent": false,
    "coindb": false,
    "qt": false,
    "leveldb": false,
    "validation": false,
    "i2p": true,
    "ipc": false
  }
  ```

  after

  ```
  $ bitcoin-cli help logging
  ...
  The valid logging categories are: addrman, bench, cmpctblock, coindb, estimatefee, http, i2p, ipc, leveldb, libevent, mempool, mempoolrej, net, proxy, prune, qt, rand, reindex, rpc, selectcoins, tor, validation, walletdb, zmq

  $ bitcoind -h | grep -A8 "debug=<category>"
    -debug=<category>
         ...
         output all debugging information. <category> can be: addrman,
         bench, cmpctblock, coindb, estimatefee, http, i2p, ipc, leveldb,
         libevent, mempool, mempoolrej, net, proxy, prune, qt, rand,
         reindex, rpc, selectcoins, tor, validation, walletdb, zmq.

  $ bitcoin-cli logging [] '["addrman"]'
  {
    "addrman": false,
    "bench": false,
    "cmpctblock": false,
    "coindb": false,
    "estimatefee": false,
    "http": false,
    "i2p": false,
    "ipc": false,
    "leveldb": false,
    "libevent": false,
    "mempool": false,
    "mempoolrej": false,
    "net": false,
    "proxy": false,
    "prune": false,
    "qt": false,
    "rand": false,
    "reindex": false,
    "rpc": false,
    "selectcoins": false,
    "tor": false,
    "validation": false,
    "walletdb": false,
    "zmq": false
  }
  ```

ACKs for top commit:
  theStack:
    re-ACK d596dba

Tree-SHA512: d546257f562b0a288d1b19a028f1a510aaf21bd21da058e7c84653d305ea8662ecb4647ebefd2b97411f845fe5b0b841d40d3fe6814eefcb8ce82df341dfce22