🚀 fanquake merged a pull request: "chainparams: Handle Testnet4 in GetNetworkForMagic"
(https://github.com/bitcoin/bitcoin/pull/30625)

💬 fanquake commented on pull request "ci: Silent Homebrew's reinstall warnings":
(https://github.com/bitcoin/bitcoin/pull/30591#discussion_r1713500252)
Are these Qt workarounds still needed? Would be good if we could drop them, rather than adding more code to suppress warnings coming from workarounds that may no-longer be needed.

🤔 vasild reviewed a pull request: "log: expand BCLog::LogFlags (categories) to 64 bits"
(https://github.com/bitcoin/bitcoin/pull/26619#pullrequestreview-2232592770)
ACK 90c3d904bcbf294a6fcef8bc9ecb9445fd41c4bd

This probably needs a rebase. It is a trivial change.

10 new categories were added in the last 7 years. That is 1-2 per year. 32 extra should suffice for a few decades.

🚀 fanquake merged a pull request: "ci: Silent Homebrew's reinstall warnings"
(https://github.com/bitcoin/bitcoin/pull/30591)

👍 fanquake approved a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30603#pullrequestreview-2232604323)
ACK 4c2cc63d84dc1c8bae1b620f34188b7c20b70019 - please don't @ mention anyone in your pull request descriptions, otherwise they are likely to just get spammed with notifications.

🚀 fanquake merged a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30603)

📝 maflcko opened a pull request: "ci: Use clang-19 from apt.llvm.org"
(https://github.com/bitcoin/bitcoin/pull/30634)
A new clang version generally comes with bugfixes, new sanitizer features, as well as new features.

Upgrade the sanitizer tasks to use the new version.

A follow-up can explore if the tidy task, the msan tasks, or the valgrind tasks can also use a newer compiler version.

📝 fanquake locked a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30602)
This reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9.

<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
s
...

📝 fanquake locked a pull request: "get miniupnpc from ssl, this reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9"
(https://github.com/bitcoin/bitcoin/pull/30564)
the tuxfamily mirror is back up, revert back to an SSL source

🚀 fanquake merged a pull request: "doc: Add note about distro's `g++-mingw-w64-x86-64-posix` version"
(https://github.com/bitcoin/bitcoin/pull/30580)

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#issuecomment-2283641349)
Rebased and restored signalling `g_best_block_cv` on shutdown.

I created `interfaces/types.h`, moved `BlockKey` there and renamed it to `BlockRef`. I then renamed `getTipHash()` to `getTip()` instead of adding `getTipHeight()`. `waitTipChanged` also returns a `BlockKey`.

Addressed inline comments, except that I still need to look into the tests.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527845)
`getTip()` and `waitTipChanged()` now both return `BlockRef`.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527921)
Done. I also simplified the `waitfornewblock` (etc) RPC call to just call getTip() and then pass that into `waitTipChanged`. That gets rid of `struct CUpdatedBlock`.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527986)
Done

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528130)
I don't fully understand the original test either. Will look into it later.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528797)
I made a note to either add that argument in this PR or make a followup.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528958)
I moved it to `StopRPC()`.

💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713529075)
Done

💬 maprezentalok commented on issue ""heapleakdetection" entry in registry for bitcoin-qt.exe":
(https://github.com/bitcoin/bitcoin/issues/30629#issuecomment-2283688931)
Actually the hex LastDetectionTime translates to:

LDAP: 133626153101189582
Epoch/Unix time: 1718141710
GMT: 2024. June 11., Tuesday 21:35:10

so it cannot be v27.1 as it wasn't released yet, i used v27.0 at that time.

💬 agroce commented on issue "fuzz: `script`: Assertion `!extract_destination_ret' failed.":
(https://github.com/bitcoin/bitcoin/issues/30615#issuecomment-2283704534)
> I think we have a few harnesses that exit early if the input size is smaller or larger than expected, e.g.:

Not sure the equivalent in AFL++, but in libFuzzer (and Eclipser) for some targets really limiting the size of input gives the mutator a much better chance at finding lots of things. This is a good example of very different time-to-find depending on max_len. It might be a good idea to either add a (rare) config for targets with some appropriate "very short but long enough to be inte
...