📝 darosior opened a pull request: "Miniscript: always treat unsatisfiables scripts as insane"
(https://github.com/bitcoin/bitcoin/pull/27997)
Due to how properties are tracked, some unsatisfiable scripts may pass the `IsSane()` checks. This is an issue as we would treat some unspendable scripts as safe. Fix this by explicitly checking a satisfaction exists when checking for sanity.

This bug was exposed due to a check added in #22838 (https://github.com/bitcoin/bitcoin/pull/22838#discussion_r1226859880) that triggered a fuzz crash (https://github.com/bitcoin/bitcoin/pull/22838#issuecomment-1612510057).

💬 hebasto commented on pull request "ci: filter all subtrees from tidy output":
(https://github.com/bitcoin/bitcoin/pull/27996#discussion_r1246449744)
```suggestion
"src/crc32c",
"src/crypto/ctaes",
```

💬 MarcoFalke commented on issue "index: ThreadSanitizer: data race on vptr ":
(https://github.com/bitcoin/bitcoin/issues/27355#issuecomment-1612846638)
Looks like https://github.com/bitcoin/bitcoin/pull/27988 is a test-only fix for the initial issue reported here, and it increases consistency for now. I think it should be good to go, trivial to remove or rework in the future with a `std::future`-based approach.

💬 prusnak commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1612862819)
`zip foo.zip dist` should read `zip foo.zip dist/*` to drop the top-level `dist` folder

💬 MarcoFalke commented on issue "Discussion: Upgrading to C++20":
(https://github.com/bitcoin/bitcoin/issues/23363#issuecomment-1612868795)
Looks like gcc can be bumped from the now minimum required 9.1 to 10, to get roughly all of C++20. Given that all recent LTS releases of all supported operating systems ship with such a compiler, maybe this can be considered? Maybe not for 26.x, but 27.x should be fine?

⚠️ MarcoFalke reopened an issue: "Discussion: Upgrading to C++20"
(https://github.com/bitcoin/bitcoin/issues/23363)
(Previous discussion (C++17): https://github.com/bitcoin/bitcoin/issues/16684)

With package managers shipping newer versions of compilers and older releases of operating systems going EOL, it occurs that at some point in the future it will be almost uncontroversial to switch to C++20.

See the new features here: https://en.cppreference.com/w/cpp/compiler_support#cpp20

I think noteworthy are:

* <strike>Lambdas in unevaluated contexts: It will be possible to use `Assert(...)` (a lambda
...

💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1612912372)
> As I understand it, there are (at least) these two issues to be addressed:

Yes, essentially "the package contains valid transactions, but we should only accept a subset of it due to fees." The first one can happen normally if we just came out of IBD or our peer has a lower minfeerate than we do - this PR was initially to address that. It was also to address "the package contains some invalid transactions, and we should take the subset that is valid" but I now think of that as a distinct con
...

💬 djkazic commented on pull request "Add feerate histogram to getmempoolinfo":
(https://github.com/bitcoin/bitcoin/pull/21422#issuecomment-1612915024)
Hey, developer of matrix here.

I think a neural net fee estimator is going to be pretty performant compared to mempool space. My logger already takes into account things like CPFP and calculates the total package fee rate, and with approx 50MB of training data it's capable of estimating fees such that if the necessary rate goes down, it reacts more quickly that estimatesmartfee.

Like the built-in fee estimator, I do not use the current contents of the mempool. Rather, the training data pa
...

⚠️ stickies-v opened an issue: "rpc: doc: RPCHelpMan missing request parameters for getblocktemplate"
(https://github.com/bitcoin/bitcoin/issues/27998)
### Motivation

The `getblocktemplate` help currently shows these available request parameters (as part of the `template_request` object):

<details>
<summary> $ ./bitcoin-cli help getblocktemplate</summary>

```
$ ./bitcoin-cli help getblocktemplate

...
getblocktemplate ( "template_request" )

If the request parameters include a 'mode' key, that is used to explicitly select between the default 'template' request or a 'proposal'.
It returns data needed to construct a block to work o
...

💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1246479807)
> So my https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1226067022 for that would be to have net_processing do retries:

This seems like a good option to consider for computational complexity, but I think could be even slower if we are blocked by UTXO fetching - they are cached when fetched in `PreChecks`, uncached at the end of `ProcessNewPackage`, and then reloaded again when we retry. So just thinking about UTXO fetching, it seems better to do retries while we have them loaded and
...

📝 fanquake opened a pull request: "contrib: add macOS test for fixup_chains usage"
(https://github.com/bitcoin/bitcoin/pull/27999)
Followup to #27676, adding the check for chain fixups.

Somewhat annoyingly, we have to patch support for `-no_fixup_chains` into ld64. As it doesn't seem to have been added [until a later version](https://github.com/apple-oss-distributions/ld64/blob/59a99ab60399c5e6c49e6945a9e1049c42b71135/src/ld/Options.cpp#L4172).

💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1246480765)
After whiteboarding this idea + chunking, ended up with https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1612912372

💬 stratospher commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1244700187)
53c1b7a: nit: since starting with block_counter = 1 is a detail of RFC8439's AEAD and not RFC8439's ChaCha20, would it be better to just mention the general form?
```suggestion
* In this mode, only 2^38 - 64*block_counter bytes can be encrypted.
```

💬 stratospher commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1246254085)
2c0c749: this test vector is repeated in this [line](https://github.com/bitcoin/bitcoin/blob/626d3464695ed513e555371b870a5899872d723b/src/test/crypto_tests.cpp#L486).

👍 dergoegge approved a pull request: "test: Fuzz on macOS"
(https://github.com/bitcoin/bitcoin/pull/27932#pullrequestreview-1505139891)
utACK fae7c50d201726f605938c3511dd9119efeea5ec

⚠️ naftalimurgor opened an issue: "Error: no RPC connection" when trying to run Bitcoin Core functional tests"
(https://github.com/bitcoin/bitcoin/issues/28000)
### Motivation

I'm getting a strange error running tests under `/src/test/functional/` with the following error:

```sh
Temporary test directory at /tmp/test_runner_₿_🏃_20220504_123152
Running Unit Tests for Test Framework Modules
..........
----------------------------------------------------------------------
Ran 10 tests in 0.614s

OK
Traceback (most recent call last):
File "/usr/src/bitcoin/test/functional/create_cache.py", line 27, in <module>
CreateCache().main()
Fil
...

💬 fanquake commented on pull request "contrib: add macOS test for fixup_chains usage":
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613016499)
cc @theuni

💬 dergoegge commented on pull request "ci: build Valgrind (3.21) from source":
(https://github.com/bitcoin/bitcoin/pull/27992#issuecomment-1613018513)
Concept ACK

Speeding up the valgrind jobs seems like a nice win! (assuming our self compiled valgrind isn't skipping more expensive checks).

🚀 fanquake merged a pull request: "test: Fuzz on macOS"
(https://github.com/bitcoin/bitcoin/pull/27932)

👍 hebasto approved a pull request: "ci: filter all subtrees from tidy output"
(https://github.com/bitcoin/bitcoin/pull/27996#pullrequestreview-1505169342)
re-ACK 62633b50461cb67dfb37d6485e604152e727559c