💬 TheCharlatan commented on pull request "refactor: Use ChainType enum exhaustively":
(https://github.com/bitcoin/bitcoin/pull/27611#issuecomment-1541546516)
Updated d0767a9e0af367cbcc4ff7fce3758ece7d62861f -> ef39bdf0f709db1b3bfa07adddce7cccbd774109 ([followUp27491_0](https://github.com/TheCharlatan/bitcoin/tree/followUp27491_0) -> [followUp27491_1](https://github.com/TheCharlatan/bitcoin/tree/followUp27491_1), [compare](https://github.com/TheCharlatan/bitcoin/compare/followUp27491_0..followUp27491_1))
* Addressed @MarcoFalke's [comment](https://github.com/bitcoin/bitcoin/pull/27611#issuecomment-1541456801), removing exception docstring.
* Added s
...

👍 MarcoFalke approved a pull request: "refactor: Use ChainType enum exhaustively"
(https://github.com/bitcoin/bitcoin/pull/27611#pullrequestreview-1420053321)
lgtm, found another nit, feel free to ignore

💬 MarcoFalke commented on pull request "refactor: Use ChainType enum exhaustively":
(https://github.com/bitcoin/bitcoin/pull/27611#discussion_r1189539373)
The return type is wrong, too. So maybe remove this line as well, as it is redundant with the line above it. Also, in the line above, can remove the return type, as it is redundant with the C++ code?

💬 MarcoFalke commented on pull request "refactor: Use ChainType enum exhaustively":
(https://github.com/bitcoin/bitcoin/pull/27611#discussion_r1189540735)
Same

💬 MarcoFalke commented on pull request "refactor: Use ChainType enum exhaustively":
(https://github.com/bitcoin/bitcoin/pull/27611#discussion_r1189543228)
I think the scripted diff can be dropped, given that it fails? Maybe include this diff in the previous commit?

📝 hebasto converted_to_draft a pull request: "Enable HW-accelerated implementations of SHA256 for MSVC builds"
(https://github.com/bitcoin/bitcoin/pull/24773)
This PR enables AVX2, SSE4.1 and x86 SHA-NI implementations of SHA256 instead of the "standard" one.

**NOTE about testing**. During runtime the SHA-NI implementation is available only if a CPU has the `sha_ni` flag set.

💬 MarcoFalke commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1189586654)
I wonder if we can make those two getters return `Result`s, instead of throwing exceptions.

I tried that in the past because there was an unguarded call in the gui, which would then cause a segfault, but that seems now fixed. Still, low-prio and long-term this may be a thing to keep in mind.

💬 TheCharlatan commented on pull request "refactor: Use ChainType enum exhaustively":
(https://github.com/bitcoin/bitcoin/pull/27611#issuecomment-1541627066)
Updated ef39bdf0f709db1b3bfa07adddce7cccbd774109 -> e23088707be2c3bf247f4b777290c8e401db48cb ([followUp27491_1](https://github.com/TheCharlatan/bitcoin/tree/followUp27491_1) -> [followUp27491_2](https://github.com/TheCharlatan/bitcoin/tree/followUp27491_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/followUp27491_1..followUp27491_2))
* Addressed @MarcoFalke's [comment](https://github.com/bitcoin/bitcoin/pull/27611#discussion_r1189539373), but kept the first line of the docstring
...

💬 Sjors commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1541635412)
@ayeowch running that particular script against a modest Intel i5-8400 with 6 cores, either from another computer on the LAN or from the machine itself, I don't see any noticeable CPU difference (compared to all the other stuff its running). Even when downloading 10GB of headers in a few minutes, which is probably a faster download rate than you experienced given the total (though you tally disconnected peers too I suppose).

💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1189596088)
I only meant the comparison to `MinimumChainWork()`.

💬 fanquake commented on pull request "rpc: append rpcauth.py hash in config and show pass":
(https://github.com/bitcoin/bitcoin/pull/27588#issuecomment-1541643064)
@st3b1t note that you've left the commit messages from the squashed commits in e1046eca9d637dfd29599d156a57a8a3a7440b23.

🚀 fanquake merged a pull request: "p2p: Avoid prematurely clearing download state for other peers"
(https://github.com/bitcoin/bitcoin/pull/27608)

👍 MarcoFalke approved a pull request: "refactor: Use ChainType enum exhaustively"
(https://github.com/bitcoin/bitcoin/pull/27611#pullrequestreview-1420153649)
lgtm

🚀 fanquake merged a pull request: "add ryanofsky to trusted-keys"
(https://github.com/bitcoin/bitcoin/pull/27604)

📝 fanquake opened a pull request: "[25.x] Backports for rc2"
(https://github.com/bitcoin/bitcoin/pull/27613)
Collecting backports for rc2. Currently:
* https://github.com/bitcoin/bitcoin/pull/27608

💬 MarcoFalke commented on pull request "doc: clarify processing of mempool-msgs when NODE_BLOOM":
(https://github.com/bitcoin/bitcoin/pull/27559#discussion_r1189635504)
I think it makes sense to also document this in `src/protocol.h`, which generally refers to the p2p version and the BIP number. I read BIP 35, 37, and 111, but I couldn't find a mention that the message type is guarded by NODE_BLOOM. So maybe this can also be mentioned in `src/protocol.h`?

📝 fanquake opened a pull request: "[24.x] Backports for rc3"
(https://github.com/bitcoin/bitcoin/pull/27614)
Collecting backports for rc3. Currently:
* https://github.com/bitcoin/bitcoin/pull/27608

💬 willcl-ark commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1541828229)
FWIW I am also seeing some sustained high CPU usage on a listening (non debug mode) 24.0.1 node from the `b-msghand` thread:


I am used to seeing this thread at ~1% on this machine:



I also have a number of these "hungry" peers:

```fish
bitcoin in ~ took 53s ➜ bitcoin-cli getpeer
...

💬 stickies-v commented on pull request "refactor: Replace global find_value function with UniValue::find_value method":
(https://github.com/bitcoin/bitcoin/pull/27605#discussion_r1189677819)
I think it would be best to add the commit message as code documentation to make it easier to track when this can be reverted?

I'm also not sure this commit fits the scope of the PR but I can see how it's related, and it's a separate commit anyway so probably fine.

💬 ferzan98 commented on issue "Drop support for g++-8?":
(https://github.com/bitcoin/bitcoin/issues/27537#issuecomment-1541862923)
ack means short for acknowledgment