⚠️ 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

💬 MarcoFalke commented on issue "Error: no RPC connection" when trying to run Bitcoin Core functional tests":
(https://github.com/bitcoin/bitcoin/issues/28000#issuecomment-1613069039)
Can you try with:


```diff
diff --git a/test/functional/test_framework/test_node.py b/test/functional/test_framework/test_node.py
index 5111d88e15..1e605e00b8 100755
--- a/test/functional/test_framework/test_node.py
+++ b/test/functional/test_framework/test_node.py
@@ -232,6 +232,8 @@ class TestNode():
poll_per_s = 4
for _ in range(poll_per_s * self.rpc_timeout):
if self.process.poll() is not None:
+ self.stderr.seek(0)
+
...

🚀 fanquake merged a pull request: "ci: filter all subtrees from tidy output"
(https://github.com/bitcoin/bitcoin/pull/27996)

💬 willcl-ark commented on pull request "net: run disconnect in I2P thread":
(https://github.com/bitcoin/bitcoin/pull/27912#issuecomment-1613098947)
Yes I agree and like this approach better.

I had created a `ThreadI2PSocketHandler()` thread which essentially had the same loop as `ThreadSocketHandler()`. The repetition of `DisconnectNodes()` and `NotifyNumConnectionsChanged()` in two threads seemed annoying (and needed a few new locks) and I was considering whether a _new_ seperate thread should just handle disconnecting nodes marked for disconnection and notifications, but I think doing it as part of `CreateNodeFromAcceptedSocket()` (in
...

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-1613145594)
`4557cc336f...353d323356`: take some suggestions

Invalidates ACK from @jonatack

⚠️ re2005 opened an issue: "Unable to send funds"
(https://github.com/bitcoin/bitcoin/issues/28001)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Using Bitcoin Core `v25.0.0` have it sync (pruned)

My wallet shows valid balance but I'm not able to send funds

### Expected behaviour

Be able to send funds when the wallet display you have balance



### Steps to reproduce

- Try to send funds to a valid rec
...