💬 edilmedeiros commented on issue "Creating too many wallets exhausts file descriptor limit and leads to crash":
(https://github.com/bitcoin/bitcoin/issues/27732#issuecomment-2439607898)
I confirm this is still happening on v28.

🤔 glozow reviewed a pull request: "rpc: getorphantxs follow-up"
(https://github.com/bitcoin/bitcoin/pull/31043#pullrequestreview-2397270441)
utACK 0ea84bc362f395fd247623c22942eb5ca3d1b874

💬 jasonribble commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r1817901340)
maybe you can rename the "18" value as a BnB threshold

💬 davidgumberg commented on pull request "util: Remove RandAddSeedPerfmon":
(https://github.com/bitcoin/bitcoin/pull/31124#issuecomment-2439688459)
post-merge utACK https://github.com/bitcoin/bitcoin/pull/31124/commits/9bb92c0e7ffe2426b4afb80ddd4b4c96968316b5

💬 davidgumberg commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2439690252)
> Turned off hourly CI for now, since fix removing the offending function was merged into bitcoin:master.

Would it make sense to leave it running for a little longer to validate that the fix worked?

💬 sdaftuar commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2439723285)
Code review ACK e01bb3a06693efc77a173afdf25ed7ba631316a2

💬 hodlinator commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2439723709)
> Would it make sense to leave it running for a little longer to validate that the fix worked?

My reasoning was that there should be enough CI runs on master and all runs on PRs based on top of the merged fix. If it re-occurs hopefully one of us will reopen #30390. But I don't have a well-developed sense for how much strain is reasonable to put on the CI resources.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817922747)
Reorgs are split: additions happen via the changesets (since we just use ATMP), while removals happen in their own special funky way.

I can update the comment.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817923233)
Additions never happen outside a changeset. RBF-related removals always go through a changeset as well.

Removals that happen because a block is found, or due to a reorg, or due to mempool expiry or mempool limiting do not go through the changeset.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817924314)
Not sure I follow -- if somehow the PolicyScriptChecks() passed for something that failed ConsensusChecks(), then this logic would trigger and we would then remove the transactions from the mempool. It's slightly different than the old behavior of never allowing it to enter in the first place, but given that we're holding the mempool locks the whole time it is not really directly observable?

💬 theStack commented on pull request "cmake: Set top-level target output locations":
(https://github.com/bitcoin/bitcoin/pull/31161#issuecomment-2439735659)
Concept ACK

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817930330)
Fixed, thanks.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817930359)
Fixed, thanks.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817930369)
Fixed, thanks.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1817930536)
Fixed, thanks.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#issuecomment-2439740158)
Rebased (to pick up the test introduced in #31152) and addressed latest feedback.

💬 l0rinc commented on pull request "optimization: pack util::Xor into 64/32 bit chunks instead of doing it byte-by-byte":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1817939448)
Ended up modifying a lot more in the latest push, so this line was formatted again

💬 l0rinc commented on pull request "optimization: pack util::Xor into 64/32 bit chunks instead of doing it byte-by-byte":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1817939675)
I've replaced all vectors to 64 bit ints, the new peproducer is: [godbolt.org/z/sc5xPTcW6](https://godbolt.org/z/sc5xPTcW6), which shows:
* _Clang_ (x86-64) - uses SSE (`movdqu`/`pshufd`/`pxor`) for SIMD operations, processing **32** bytes / iteration
* _GCC_ (x86-64) - uses simple 64-bit operations (`xor` with `QWORD PTR`), processes **16** bytes / iteration
* _RISC-V_ (32-bit) - uses basic 32-bit register operations (`lbu`, `xor`, `srli`, `sb`), processes **8** bytes / iteration

(please
...

📝 theStack opened a pull request: "scripted-diff: get rid of remaining "command" terminology in protocol.{h,cpp}"
(https://github.com/bitcoin/bitcoin/pull/31163)
The confusing "command" terminology for the 12-byte field in the (v1) p2p message header was replaced with the more proper term "message type" in other modules already years ago, see eg #18533, #18937, #24078, #24141. This PR does the same for the protocol.{h,cpp} module to complete the replacements. Note that "GetCommand" is a method name also used in the `ArgsManager` (there it makes much more sense), so the scripted-diff lists for this replacement the files explicitly, rather than using `$(gi
...

💬 l0rinc commented on pull request "optimization: pack util::Xor into 64/32 bit chunks instead of doing it byte-by-byte":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1817939890)
I've change the usages to avoid std::vector keys, this way GCC and Clang both agree that the new results are faster (even though clang manages to compile to 32 byte SIMD, while GCC only to 16 bytes per iteration, see https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1817939675)