💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191790800)
@satsie is the concern of having a dummy value like `NET_MAX` that it could fall out of sync if enum values start being explicitly assigned?

💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191806474)
adding it to the `NetMsgType` namespace makes sense to me- the current name essentially manually namespaces it.

RE `allNetMessageTypes` array - either way seems OK to me. from a quick glance at callers, I don't think you'd have to add much special case logic if you added it in the array, so that could be nice

💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191804470)
+1 I think having this code in a separate compilation unit + forward declaration of the class would be sufficient for `net.h`, then `net.cpp` could include the full file

💬 ajtowns commented on pull request "p2p: Stop relaying non-mempool txs":
(https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1544947585)
> > we could trim mapRelay before their scheduled expiry time has actually been reached.
>
> Sounds like this would either degrade compact block relay when the mempool is full due to trimming `mapRelay`, or turn one DoS (OOM) into another DoS (lost fee income) due to trimming valid mempool txs? And if you use separate and dedicated size limits for `mapRelay` and the mempool, it might be easier to keep them separate data structures?

The memory usage of `mapRelay` depends on whether the tran
...

⚠️ ETCorps opened an issue: "[> ETH Price: $1,800.33 (-1.80%)"
(https://github.com/bitcoin/bitcoin/issues/27633)
[> ETH Price: $1,800.33 (-1.80%)
>
>
>
> Transaction Details
>
> SALES! Get 15% off (one-time) for any new API Pro subscription. Code:ESFP15Q223
> Overview
> Internal Txns
> Logs (9)
> State
> Comments
> Transaction Hash:
> 0x273894b35d8c30d32e1ffa22ee6aa320cc9f55f2adbba0583594ed47c031f6f6
> Status:
> Success
> Block:
> 17046833
> 193887 Block Confirmations
> Timestamp:
> 27 days 7 hrs ago (Apr-14-2023 05:21:11 PM +UTC)|Confirmed within 30 secs
> Transaction Action:
> Supply
> 391,662,390,
...

✅ achow101 closed an issue: "[> ETH Price: $1,800.33 (-1.80%)"
(https://github.com/bitcoin/bitcoin/issues/27633)

:lock: achow101 locked an issue: "[> ETH Price: $1,800.33 (-1.80%)"
(https://github.com/bitcoin/bitcoin/issues/27633)

💬 jamesob commented on pull request "Raise on invalid -debug and -loglevel config options":
(https://github.com/bitcoin/bitcoin/pull/27632#issuecomment-1544967639)
Concept ACK; trying to `-debug=` a nonexistent category bit me earlier today.

💬 jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1544970920)
Rebased.

💬 ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1545188707)
> I presume this is still an issue?

I haven't seen any notable issues since the BRC-20 spam died down a few days ago, one node with 412 incoming connections is currently sitting at ~16% average CPU usage.

> I'm also seeing the same issue.. The load average suddenly increased from 0.25 to 1+.

You probably need to restart the node to clear it up after it's started spinning, a few days ago I had one node still spinning even after dropping to <80 connections due to timeouts/disconnects.

⚠️ sipa opened an issue: "BIP324 tracking issue"
(https://github.com/bitcoin/bitcoin/issues/27634)
This issue will be updated to reflect the current state of [BIP324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) integration.

PRs ready for review: #27479 (depends on ellswift support in libsecp256k1, though)

Overall plan:
* [ ] ElligatorSwift integration in Bitcoin Core: #27479
* [ ] ElligatorSwift support in libsecp256k1: bitcoin-core/secp256k1#1129
* [ ] Cipher suite implementation (formerly #25631)
* [ ] P2P v2 transport layer (formerly #23561 and #23233)
* [
...

💬 ajtowns commented on pull request "[23.2] Backports for rc1":
(https://github.com/bitcoin/bitcoin/pull/27624#issuecomment-1545280463)
utACK a26ff204f0f0355749a1b61136437623b325f8fb

👍 vasild approved a pull request: "Raise on invalid -debug and -loglevel config options"
(https://github.com/bitcoin/bitcoin/pull/27632#pullrequestreview-1423928513)
ACK b9935a4ad512cc0d310d1bd363f71f430b787dbb

💬 vasild commented on pull request "Raise on invalid -debug and -loglevel config options":
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1192007516)
nit: document those as the return value may not be so obvious to everybody: "if a non-empty optional is returned then an error occurred and it contains the error message".

💬 sipa commented on pull request "Introduce field element and group element classes to test_framework/key.py":
(https://github.com/bitcoin/bitcoin/pull/26222#discussion_r1192016465)
Nice catch, fixed.

💬 sipa commented on pull request "Introduce field element and group element classes to test_framework/key.py":
(https://github.com/bitcoin/bitcoin/pull/26222#issuecomment-1545314256)
@theStack I've included your commit to add the precomputed G table. The speedup is significant enough that it's worth it, I think.

You've indeed discovered one of the techniques that are used for speeding up EC multiplications with precomputed tabled. Libsecp256k1 today uses a more advanced version of that idea, where all multiples of the form `i*16^j*G` for all i=0..15, and j=0..63 are precomputed, leaving us with ~63 point additions. An even more advanced approach is discussed in https://gi
...

⚠️ MarcoFalke opened an issue: "--with-sanitizers=float-divide-by-zero crash with -debug=bench in Chainstate::ConnectTip"
(https://github.com/bitcoin/bitcoin/issues/27635)
Not sure if this UB causes issues with any compiler. clang is fine, see:

* `-fsanitize=float-divide-by-zero`: Floating point division by zero. This is undefined per the C and C++ standards, but is defined by Clang (and by ISO/IEC/IEEE 60559 / IEEE 754) as producing either an infinity or NaN value, so is not included in `-fsanitize=undefined`.

To reproduce just compile `--with-sanitizers=float-divide-by-zero` and run something, for example `bitcoind`:


```
UBSAN_OPTIONS="suppressions=$
...

📝 TheCharlatan opened a pull request: "kernel: Remove interface_ui, util/system from kernel library"
(https://github.com/bitcoin/bitcoin/pull/27636)
This pull request is part of the `libbitcoinkernel` project https://github.com/bitcoin/bitcoin/issues/27587 https://github.com/bitcoin/bitcoin/projects/18 and more specifically its "Step 2: Decouple most non-consensus code from libbitcoinkernel".

---

It removes the kernel library's dependency on `util/system` and `interface_ui`. `util/system` contains networking and shell-related code that should not be part of the kernel library. The following pull requests prepared `util/system` for this
...

💬 MarcoFalke commented on pull request "ci: Remove CI_EXEC bloat":
(https://github.com/bitcoin/bitcoin/pull/27616#discussion_r1192054525)
Moving the `exit 0` may also fix a bug where the CI Pod for ` ARM64 Android APK [jammy] ` is left alive even if the test passed.

💬 Sjors commented on pull request "[23.2] Backports for rc1":
(https://github.com/bitcoin/bitcoin/pull/27624#issuecomment-1545359195)
I didn't check the #27608 backport (nor the original). I did check #27608, the other commits in this PR and the release notes, which look good to me.