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

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