💬 ryanofsky commented on pull request "Multiprocess bitcoin":
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-1544783273)
Thanks @Sjors. I've tried a lot of things and have not been able to reproduce the crash exactly, but the log you posted was helpful, and I could reproduce similar error output by adding an extra call from bitcoin-node to bitcoin-wallet that sleeps in bitcoin-wallet, and then manual killing `bitcoin-wallet` process. When I do that I see similar `kj::Exception` errors on the bitcoin-node main thread and bitcoin-node b-capnp-loop thread like in your log. In your log the exact errors are `kj/async
...

📝 jonatack opened a pull request: "Raise on invalid -debug and -loglevel config options"
(https://github.com/bitcoin/bitcoin/pull/27632)
and rename BCLog::BLOCKSTORE to BLOCKSTORAGE so the enum is the same as its value like the other BCLog enums.

Per discussion in bitcoin-core-dev IRC today from https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-11#921458.

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

🤔 amitiuttarwar reviewed a pull request: "rpc: add 'getnetmsgstats', new rpc to view network message statistics"
(https://github.com/bitcoin/bitcoin/pull/27534#pullrequestreview-1423599288)
approach ACK. did a high-level review and left a few small comments

💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191793368)
this function should handle if `index > NUM_NET_MESSAGE_TYPES`

💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191798171)
nit: I'm kinda confused by this spacing. could it be a bit more legible to have them just line up instead of cascade?

💬 amitiuttarwar commented on pull request "rpc: add 'getnetmsgstats', new rpc to view network message statistics":
(https://github.com/bitcoin/bitcoin/pull/27534#discussion_r1191801732)
cc @dergoegge

💬 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".