💬 TheCharlatan commented on pull request "fuzz: More accurate coverage reports":
(https://github.com/bitcoin/bitcoin/pull/30156#issuecomment-2126752510)
Concept ACK

💬 fanquake commented on pull request "guix: use GCC 13 to builds releases":
(https://github.com/bitcoin/bitcoin/pull/29881#issuecomment-2126768337)
Looks like Windows still has false positives with GCC 13.2.0 (https://github.com/bitcoin/bitcoin/pull/29881/checks?check_run_id=25320716500):
```bash
torcontrol.cpp: In static member function ‘static void TorControlConnection::readcb(bufferevent*, void*)’:
torcontrol.cpp:94:28: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
94 | self->message.code = ToIntegral<int>(s.substr(0, 3)).value_or(0);
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
...

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611430621)
OK, you're right, this could happen: https://learn.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipforward_row2

> NextHop
>
> Type: [SOCKADDR_INET](https://learn.microsoft.com/en-us/windows/desktop/api/ws2ipdef/ns-ws2ipdef-sockaddr_inet)
>
> For a remote route, the IP address of the next system or gateway en route. If the route is to a local loopback address or an IP address on the local link, the next hop is unspecified (all zeros). For a local loopback route, this membe
...

💬 stickies-v commented on pull request "Encapsulate warnings in generalized node::Warnings and remove globals":
(https://github.com/bitcoin/bitcoin/pull/30058#discussion_r1611438018)
I have considered that approach, but see a couple of difficulties with it:
- We have kernel warnings ("unknown-new-rules-activated", "large-work-invalid-chain") and node warnings ("clock-out-of-sync", "pre-release-test-build", "fatal-internal-error"). I would rather not define the node warnings in the kernel namespace. We could have have `kernel::Warning` and `node::Warning` enums (and potentially more in the future), and have a `std::variant<kernel::Warning, node::Warning> GetAllWarnings()` to
...

🤔 glozow reviewed a pull request: "contrib: Renew Windows code signing certificate"
(https://github.com/bitcoin/bitcoin/pull/30149#pullrequestreview-2073561075)
tested ACK 9f4ff1e96595

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611456690)
Seems we could factor out `AddressFamilyFromNetwork` at least, this is repeated in literally every implementation 😄

💬 maflcko commented on pull request "fuzz: More accurate coverage reports":
(https://github.com/bitcoin/bitcoin/pull/30156#discussion_r1611462530)
Why not call this at the end of `initialize` inside the function body?

💬 maflcko commented on pull request "rpc: avoid copying into UniValue":
(https://github.com/bitcoin/bitcoin/pull/30115#issuecomment-2126828731)
> @ryanofsky If you theory is correct, then having a way to invoke `shrink_to_fit` on `UniValue`'s internal vector might be useful.

Not sure if this is ideal. UniValue is a recursive structure, so calling it on the top level vector only shouldn't cause any difference? Similarly, if shirking is done recursively, the runtime overhead will be equal to that of a copy, so might as well just do a copy instead? Finally, whenever a `UniValue` would be ready to shrink, it is usually one step away from
...

🤔 glozow reviewed a pull request: "net: add ASMap info in `getrawaddrman` RPC"
(https://github.com/bitcoin/bitcoin/pull/30062#pullrequestreview-2073621757)
ACK 1e54d61c4698debf3329d1960e06078ccbf8063c

💬 glozow commented on pull request "net: add ASMap info in `getrawaddrman` RPC":
(https://github.com/bitcoin/bitcoin/pull/30062#discussion_r1611476223)
nit: this could have been a set?

🚀 glozow merged a pull request: "net: add ASMap info in `getrawaddrman` RPC"
(https://github.com/bitcoin/bitcoin/pull/30062)

💬 BenWestgate commented on pull request "doc: Update mentions of generating bitcoin.conf":
(https://github.com/bitcoin/bitcoin/pull/30154#issuecomment-2126846372)
Concept ACK

💬 dergoegge commented on pull request "fuzz: More accurate coverage reports":
(https://github.com/bitcoin/bitcoin/pull/30156#discussion_r1611489609)
No reason, done!

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611498845)
Oh, I didn't know you could do both. Happy to change if people want, but generally prefer to follow convention of the existing annotations.

💬 stickies-v commented on pull request "Encapsulate warnings in generalized node::Warnings and remove globals":
(https://github.com/bitcoin/bitcoin/pull/30058#discussion_r1611500389)
I gave the `kernel::Warning` and `node::Warning` enums approach a go because it would be nice to have the possible warnings enumerated, and it ended up being less overhead than I expected. I'm leaning towards updating this PR with that approach. What do you think?

https://github.com/stickies-v/bitcoin/commit/e4ea7aba9f1426dc510dbdbff19788919bf9d3fb - PoC but compiles and tests pass, needs cleanup and doc updates etc

👍 BenWestgate approved a pull request: "Drop -dbcache limit"
(https://github.com/bitcoin/bitcoin/pull/28358#pullrequestreview-1601764043)
crACK

💬 BenWestgate commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#discussion_r1309545616)
I would prefer it quietly round down to the maximum. Especially since it rounds up to the minimum.

I know a few scripts people use that set dbcache to a percentage of available memory that this part of the PR would break for 64GB RAM.

What problem is failing to start meant to solve?

💬 epiccurious commented on pull request "doc: Update mentions of generating bitcoin.conf":
(https://github.com/bitcoin/bitcoin/pull/30154#discussion_r1611518035)
Good point. My intention here is to reduce ambiguity by being more explicit to the user.

One solution would be to add a check to ensure this section mentioned actually exists in the markdown, but it's probably not worth the added code complexity for little benefit.

Do you prefer to revert this change back?

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611522537)
OK, i went for `QueryDefaultGatewayImpl` for now, with an outer function. Naming it different things on different platforms means having to repeat the `#ifdef` forest, which isn't really worth the slight increase in clarity imo.

💬 epiccurious commented on pull request "doc: Update mentions of generating bitcoin.conf":
(https://github.com/bitcoin/bitcoin/pull/30154#issuecomment-2126901520)
> IIUIC, this change affects only people who is getting core from source

Correct as I understand it. Only impacts people using the source, not the binary distributions.