👍 hebasto approved a pull request: "guix: remove cURL from build env"
(https://github.com/bitcoin/bitcoin/pull/27779#pullrequestreview-1458997060)
ACK 641897a83dc9d40b618efbae67c3beb90a1f34f8

Guix build:
```
7e9b3758aadd87db9c89fec5c05ca7a5020aaebf185daee4f7570dd1eeb23355 guix-build-641897a83dc9/output/aarch64-linux-gnu/SHA256SUMS.part
494f06d1f21ad20aa8cc8f61c4dfeda053215f41bb2aa0bfd47343909edf4dad guix-build-641897a83dc9/output/aarch64-linux-gnu/bitcoin-641897a83dc9-aarch64-linux-gnu-debug.tar.gz
8a3912a0ff0cb41b87494291ca13bc9caa47ff08d57f37b6d99a9c8e3667390a guix-build-641897a83dc9/output/aarch64-linux-gnu/bitcoin-641897a83dc
...

📝 aguycalled opened a pull request: "BLSCT SubAddressPool"
(https://github.com/bitcoin/bitcoin/pull/27809)
This PR adds support for the use of a SubAddress pool and the generation of different receiving addresses.

`getnewaddress` RPC method pulls addresses from the pool and shows to the requester receiving addresses.

By default it generates addresses under account `0`.

✅ fanquake closed a pull request: "BLSCT SubAddressPool"
(https://github.com/bitcoin/bitcoin/pull/27809)

💬 Ayms commented on pull request "Ignore datacarrier limits for dataless OP_RETURN outputs":
(https://github.com/bitcoin/bitcoin/pull/27261#issuecomment-1574929624)
I must be brain damaged or something like this, still I don't get what it has to do with https://github.com/bitcoin/bitcoin/issues/27043 (and when it will happen)

📝 dergoegge opened a pull request: "fuzz: Partially revert #27780"
(https://github.com/bitcoin/bitcoin/pull/27810)
Partially revert #27780, because moving the duplicate coinbase check out of the `was_valid` branch leads to non-bug crashes in the fuzz target.

For context and further explanation see: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=59516

💬 sipa commented on pull request "util: generalize accounting of system-allocated memory in pool resource":
(https://github.com/bitcoin/bitcoin/pull/27748#discussion_r1215541260)
This is what I measure (GCC 12.2.0, glibc 2.37, x86_64 and i686):

* 64-bit:
** 1-24: 32
** 25-40: 48
** 41-56: 64
** 57-72: 80
** 73-88: 96
** Rule: max(32, (X+23) & ~15)

* 32-bit:
** 1-12: 16
** 13-28: 32
** 29-44: 48
** 45-60: 64
** 61-76: 80
** Rule: (X+19) & ~15

💬 brunoerg commented on pull request "fuzz: Fix mini_miner_selection running out of coin":
(https://github.com/bitcoin/bitcoin/pull/27806#discussion_r1215564954)
Wouldn't be an alternative to replace `LIMITED_WHILE(fuzzed_data_provider.ConsumeBool(), 100)` for `LIMITED_WHILE(!available_coins.empty(), 100)`?

📝 hebasto opened a pull request: "guix: Clean up manifest"
(https://github.com/bitcoin/bitcoin/pull/27811)
This PR cleans up the `contrib/guix/manifest.scm` in the following way:
- Unneeded for a successful build modules have be dropped.
- Some modules have been enhanced with `#:select` clauses, which improves maintainability (see the commit message for details).

Based on https://github.com/bitcoin/bitcoin/pull/27779.

💬 denavila commented on pull request "wallet: Deniability API (Unilateral Transaction Meta-Privacy)":
(https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-1575041987)
> Good point and most of the people who tried this with coins involved in any incident regret doing it. Privacy in bitcoin is not as simple as doing some transactions with your own addresses automatically. There are lot of things you need to take care of. One mistake and your privacy is breached, publicly available for the whole world.

What kind of incidents do you mean? Do you have some concrete examples?
I don't see how one's privacy would be any worse after sending transactions to oneself
...

📝 Brotcrunsher opened a pull request: "Style: Avoiding unnecessary std::string copy in ArgsManager::GetPathArg argument list"
(https://github.com/bitcoin/bitcoin/pull/27812)
Please note, this is my first contribution to Bitcoin Core. I am not sure where the line of "significant developer experience" is drawn, but this at least removes a warning from some static code checkers.

📝 hebasto opened a pull request: "guix: Update `python-lief` package to 0.13.1"
(https://github.com/bitcoin/bitcoin/pull/27813)
Drafted as control flow checks are broken (

👋 hebasto's pull request is ready for review: "guix: Update `python-lief` package to 0.13.1"
(https://github.com/bitcoin/bitcoin/pull/27813)

💬 stevenroose commented on pull request "Allow fee estimation to work with lower fees":
(https://github.com/bitcoin/bitcoin/pull/13990#issuecomment-1575189553)
Lately definitely looks like it is less relevant. Nothing says we can't go back to the situation from a year or two ago where txs with 1 sat/vB would easily confirm in a few hours.

💬 hebasto commented on pull request "guix: Update `python-lief` package to 0.13.1":
(https://github.com/bitcoin/bitcoin/pull/27813#issuecomment-1575199735)
Guix build:
```
f3006576f4882414f9bbe9e37dbf54567bf24cff5252e487260a79d7f411c0bd guix-build-e3792a660abf/output/aarch64-linux-gnu/SHA256SUMS.part
61e90a272ab6d534ade60c46da90809f5d03017d31fed4b24225780db8c4aa4d guix-build-e3792a660abf/output/aarch64-linux-gnu/bitcoin-e3792a660abf-aarch64-linux-gnu-debug.tar.gz
a6e23c73e89076f5cb8c712effd6dd5796fb1e9bfd720b9310b829128e7a94f1 guix-build-e3792a660abf/output/aarch64-linux-gnu/bitcoin-e3792a660abf-aarch64-linux-gnu.tar.gz
8531ad1072f660de83b6
...

💬 Brotcrunsher commented on pull request "Style: Avoiding unnecessary std::string copy in ArgsManager::GetPathArg argument list":
(https://github.com/bitcoin/bitcoin/pull/27812#issuecomment-1575205520)
Found more such occurrences. However, I will wait and see if such changes are welcome or denied.

💬 hebasto commented on pull request "Style: Avoiding unnecessary std::string copy in ArgsManager::GetPathArg argument list":
(https://github.com/bitcoin/bitcoin/pull/27812#issuecomment-1575208858)
`std::string arg` in these cases are very short strings. It's cheap to copy them.

📝 Brotcrunsher opened a pull request: "Blocking arguments -nohelp, -noh, and -no?"
(https://github.com/bitcoin/bitcoin/pull/27814)
The three arguments -nohelp, -noh, and -no? were previously silently accepted and interpreted as -help, -h, and -? respectively. As negating these arguments is meaningless, this is now blocked and properly communicated to the user, resulting in e.g.:

> Error parsing command line arguments: Negating of -help is meaningless and therefore forbidden

Not that anyone ever complained about this. I just noticed this oddity while looking through the code.

💬 satsie commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#issuecomment-1575261126)
Moving to draft as I work through some feedback

📝 satsie converted_to_draft a pull request: "rpc: add 'getnetmsgstats', new rpc to view network message statistics"
(https://github.com/bitcoin/bitcoin/pull/27534)
Introduce a new RPC, `getnetmsgstats` to retrieve network message statistics. This work addresses https://github.com/bitcoin/bitcoin/issues/26337. More information on the RPC design and implementation can be found in that issue.

**_Massive_** thank-you to amitiuttarwar, vasild, and ajtowns for their help on this :pray: Over the course of several months, they have patiently provided a tremendous amount of guidance and assistance in more ways than I can count!

-------

## getnetmsgstats R
...

📝 Brotcrunsher opened a pull request: "CLI: Only one Request Handler can be specified."
(https://github.com/bitcoin/bitcoin/pull/27815)
Previously it was possible to specify multiple, however only one was picked in this arbitrary and (probably) undocumented priority: getinfo > netinfo > generate > addrinfo.