💬 l0rinc commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#discussion_r1803077774)
Thanks, done

💬 l0rinc commented on pull request "optimization: precalculate SipHash constant XOR with k0 and k1 in SaltedOutpointHasher":
(https://github.com/bitcoin/bitcoin/pull/30442#issuecomment-2416812237)
@laanwj This is the optimization that relies on https://github.com/bitcoin/bitcoin/pull/30349, would really appreciate you input on it.

🚀 achow101 merged a pull request: "optimization: reserve memory allocation for transaction inputs/outputs"
(https://github.com/bitcoin/bitcoin/pull/30093)

📝 fanquake opened a pull request: "doc: drop macOS LLVM install instructions"
(https://github.com/bitcoin/bitcoin/pull/31099)
Followup from #31048.

💬 fanquake commented on pull request "build: Bump minimum supported macOS to 13.0":
(https://github.com/bitcoin/bitcoin/pull/31048#discussion_r1803097299)
Removed in #31099.

👍 hebasto approved a pull request: "doc: drop macOS LLVM install instructions"
(https://github.com/bitcoin/bitcoin/pull/31099#pullrequestreview-2372473961)
ACK 79aa8280b2edd6a153afa876ae4a5e9ead39dc88.

Thank you for following up.

💬 TheBlueMatt commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2416863058)
I'm really quite confused by this. Creating a "temple IPC" interface is not substantially different than creating any other protocol for providing templates. What is the advantage for Bitcoin core to provide something proprietary over a standard that matches what consumers of that interface would want?

💬 maflcko commented on pull request "doc: drop macOS LLVM install instructions":
(https://github.com/bitcoin/bitcoin/pull/31099#issuecomment-2416879897)
lgtm ACK 79aa8280b2edd6a153afa876ae4a5e9ead39dc88

📝 fanquake opened a pull request: "doc: remove dependency install instructions from win docs"
(https://github.com/bitcoin/bitcoin/pull/31100)
This duplicates what is in depends, and is outdated.

Closes #31090.

🚀 fanquake merged a pull request: "test: Print CompletedProcess object on error"
(https://github.com/bitcoin/bitcoin/pull/31067)

🚀 fanquake merged a pull request: "doc: drop macOS LLVM install instructions"
(https://github.com/bitcoin/bitcoin/pull/31099)

💬 maflcko commented on pull request "build: Bump minimum supported macOS to 13.0":
(https://github.com/bitcoin/bitcoin/pull/31048#discussion_r1803165670)
Do you plan to open a follow-up to apply the similar change to Windows?

📝 fanquake opened a pull request: "[27.x] Prep for 27.2"
(https://github.com/bitcoin/bitcoin/pull/31101)

✅ fanquake closed a pull request: "build: Mark `x86_64-linux-gnu` release binaries as CET-enabled"
(https://github.com/bitcoin/bitcoin/pull/30685)

💬 fanquake commented on pull request "build: Mark `x86_64-linux-gnu` release binaries as CET-enabled":
(https://github.com/bitcoin/bitcoin/pull/30685#issuecomment-2416950030)
> Perhaps it could be labelled "Up for grabs"?

I'll cherry-pick / followup with this.

💬 maflcko commented on pull request "doc: remove dependency install instructions from win docs":
(https://github.com/bitcoin/bitcoin/pull/31100#issuecomment-2416960377)
lgtm ACK 184f12c1542f6c53eb2bd9dfb08dfdd490e38846

💬 TheBlueMatt commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2417007347)
My understanding of the conversation previously was (a) a desire to avoid a ton of TCP logic (which will largely be addressed by upcoming work to remove libevent's HTTP server and presumably then unify the Connman logic across any TCP listeners), (b) a desire to use this as a way to get more multiprocess in Core (cool, but this is unrelated to whether Sv2 is supported in Core). Neither of those precludes or leads to the conclusion that "there's currently little support for directly supporting St
...

💬 maflcko commented on issue "TSAN/MSAN fails with vm.mmap_rnd_bits=32 even with llvm 18.1.3":
(https://github.com/bitcoin/bitcoin/issues/30674#issuecomment-2417038152)
https://github.com/llvm/llvm-project/commit/7d039effc4930be9240446a4241d268a39960e0b only added two bits 28->30, so a failure with 32 is still expected, unless I am missing something.

💬 maflcko commented on pull request "test: Fix RANDOM_CTX_SEED use with parallel tests":
(https://github.com/bitcoin/bitcoin/pull/30737#issuecomment-2417064538)
Cross-ref to https://github.com/bitcoin/bitcoin/pull/30748#issuecomment-2333560129, depending on how this evolves.

📝 andrewtoth opened a pull request: "Don't wipe coins cache when full and instead evict LRU clean entries "
(https://github.com/bitcoin/bitcoin/pull/31102)
Depends on #28939.

This only wipes the coins cache if memory usage is greater than total allowed cache size. Instead, it does a non-wiping sync to disk and keeps all unspent coins in the cache. These are tracked in a linked list of clean entries, and when spent are removed from the clean linked list and appended to the dirty linked list. This results in the head of the clean linked list containing the oldest clean entry.

When the cache grows to above the large size threshold, clean entries
...