💬 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.

⚠️ sgtroy88 opened an issue: "A few ideas about these: - could include full path `http://localhost:{port}/` - could list relevant ports per network (i.e. main=8332, regtest=18443 etc) - not sure if this applies here but I'm used to seeing API endpoints with variables expressed like `/wallet/:walletname`, at least for REST APIs. I dunno if there is otherwise a convention for that"
(https://github.com/bitcoin/bitcoin/issues/27816)
A few ideas about these:
- could include full path `http://localhost:{port}/`
- could list relevant ports per network (i.e. main=8332, regtest=18443 etc)
- not sure if this applies here but I'm used to seeing API endpoints with variables expressed like `/wallet/:walletname`, at least for REST APIs. I dunno if there is otherwise a convention for that

_Originally posted by @pinheadmz in https://github.com/bitcoin/bitcoin/pull/27225#discussion_r1129599313_

💬 sgtroy88 commented on issue "A few ideas about these: - could include full path `http://localhost:{port}/` - could list relevant ports per network (i.e. main=8332, regtest=18443 etc) - not sure if this applies here but I'm used to seeing API endpoints with variables expressed like `/wallet/:walletname`, at least for REST APIs. I dunno if there is otherwise a convention for that":
(https://github.com/bitcoin/bitcoin/issues/27816#issuecomment-1575363242)
bc1qjnpe7swnvwwkpfygrx5mtlp3vjjwg6kht8j7d5

💬 sgtroy88 commented on issue "A few ideas about these: - could include full path `http://localhost:{port}/` - could list relevant ports per network (i.e. main=8332, regtest=18443 etc) - not sure if this applies here but I'm used to seeing API endpoints with variables expressed like `/wallet/:walletname`, at least for REST APIs. I dunno if there is otherwise a convention for that":
(https://github.com/bitcoin/bitcoin/issues/27816#issuecomment-1575363261)
https://github.com/bitcoin/bitcoin/pull/27225#discussion_r1129599313_

💬 sgtroy88 commented on pull request "test: added coverage to mining_basic.py":
(https://github.com/bitcoin/bitcoin/pull/27603#issuecomment-1575363457)
> Contributorbc1qjnpe7swnvwwkpfygrx5mtlp3vjjwg6kht8j7d5

💬 sgtroy88 commented on pull request "test: added coverage to mining_basic.py":
(https://github.com/bitcoin/bitcoin/pull/27603#issuecomment-1575363743)

✅ achow101 closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27816)

:lock: achow101 locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27816)

💬 hebasto commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1575514309)
> > Guix does not produce unsigned
>
> Fixed.

Now, it needs to be reproducible:

- build `#1`:
```
8f0fbd31364e2bc589be140372c56a71d8db0ccb06118923a8a6f461c65728ab guix-build-414e840c297f/output/arm64-apple-darwin/SHA256SUMS.part
8aa7c8fed1f8cc7f2d4735b87c4f57c6383191d71b10553729604863beda7e01 guix-build-414e840c297f/output/arm64-apple-darwin/bitcoin-414e840c297f-arm64-apple-darwin-unsigned.tar.gz
ea3f6623b130cf8da7d877e8828d607ca1a72654811da8fd3a840388e27cfe19 guix-build-414e840c
...

📝 hebasto opened a pull request: "Provide `-fcf-protection=none` in `test-security-check.py` explicitly"
(https://github.com/bitcoin/bitcoin/pull/27819)
The `contrib/devtools/test-security-check.py` script is not robust enough to work not only in the well-predicted Guix environment but also in the wild.

For example, on Ubuntu 22.04, GCC has `-fcf-protection=full` by default. See:
```
gcc -E -dM - < /dev/null | grep CET
#define __CET__ 3
```

This PR explicitly provides `-fcf-protection=none` in cases where it is expected.

💬 fanquake commented on pull request "Provide `-fcf-protection=none` in `test-security-check.py` explicitly":
(https://github.com/bitcoin/bitcoin/pull/27819#issuecomment-1575549761)
> is not robust enough to work not only in the well-predicted Guix environment but also in the wild.

It's not meant to be, and this isn't a design goal.

Concept NACK.

✅ hebasto closed a pull request: "Provide `-fcf-protection=none` in `test-security-check.py` explicitly"
(https://github.com/bitcoin/bitcoin/pull/27819)

💬 hebasto commented on pull request "Provide `-fcf-protection=none` in `test-security-check.py` explicitly":
(https://github.com/bitcoin/bitcoin/pull/27819#issuecomment-1575555230)
> It's not meant to be, and this isn't a design goal.

I agree that `security-check.py` is supposed to be run in the Guix environment.

But I don't see the point of the same limits for `test-security-check.py`. Mind elaborating this "design goal"? Maybe document it?

Btw, for some other flags the same approach is used.