💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3617582525)
`2d398050ee...810661dc07`: address suggestions (minor changes) and add release notes

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2593260778)
Added

💬 fanquake commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2593287377)
You can remove any `// for ` comments like this (#32562).

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3617672373)
`810661dc07...f391296b17`: do https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2593287377

💬 fanquake commented on issue "Split socket handling out of CConnman":
(https://github.com/bitcoin/bitcoin/issues/30694#issuecomment-3617709020)
Can you update the issue description to remove mentions of SV2 (given it doesn't need or uses this), and probably the libevent removal, given that seems to be taking a different approach now? I guess this could also be closed, given all relevant discussion is happening in the PR (#30988).

💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3617721711)
The flames look impressive, my dfferential flames for all 900k blocks should also finish in a few days.

### Parallelism vs speedup on different platforms

<img width="1268" height="910" alt="image" src="https://github.com/user-attachments/assets/b9a7538d-0e28-46bf-b1cc-6861cc459bd8" />

<details>
<summary>reindex-chainstate | 700000 blocks | dbcache 450 | M4-Max.local | arm64 | Apple M4 Max | 16 cores | 64.0GiB RAM | SSD | macOS 26.1 25B78 | Apple clang version 17.0.0 (clang-1700.4.4.1)<
...

🤔 stickies-v reviewed a pull request: "Add util::Expected (std::expected)"
(https://github.com/bitcoin/bitcoin/pull/34006#pullrequestreview-3545590480)
Approach ACK fa76a6620012fb738639d8fd7ce17b185bfd376c

💬 stickies-v commented on pull request "Add util::Expected (std::expected)":
(https://github.com/bitcoin/bitcoin/pull/34006#discussion_r2593365020)
This should probably be `[[nodiscard]]`? Could perhaps more generally enforce that with `bugprone-unused-return-value` for `std::expected`?

💬 stickies-v commented on pull request "Add util::Expected (std::expected)":
(https://github.com/bitcoin/bitcoin/pull/34006#discussion_r2593341384)
`std::unexpected` exposes [`std::unexpected::error()`](https://en.cppreference.com/w/cpp/utility/expected/unexpected.html#error) instead of `.err`. Since this is a public member, it might get used and thus make drop-in replacements a bit more involved?

💬 fanquake commented on pull request "depends: Propagate native C compiler to `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3617807200)
Guix Build (x86_64):
```bash
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu.tar.gz
fe143b6
...

💬 fanquake commented on pull request "depends: Propagate native C compiler to `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3617808101)
ACK 710031ebef838d2f0a1effa19170bef7b130bbeb

🚀 fanquake merged a pull request: "depends: Propagate native C compiler to `sqlite` package"
(https://github.com/bitcoin/bitcoin/pull/33995)

🤔 marcofleon reviewed a pull request: "fuzz: Add a test case for `ParseByteUnits()`"
(https://github.com/bitcoin/bitcoin/pull/34017#pullrequestreview-3545708127)
crACK 57b888ce0ebdeb34d866fd1511052fd740cc5ab8

Ran it for a bit as a sanity check, seems fine.

💬 willcl-ark commented on pull request "doc: document capnproto and libmultiprocess deps in 29.x":
(https://github.com/bitcoin/bitcoin/pull/33623#issuecomment-3617838716)
Thanks @ryanofsky, I took your clarifying changes in 2cf352fd8e6a77003e38d954b6c879b20d4b960a

💬 ajtowns commented on issue "RFC: randomize over netgroups in outbound peer selection":
(https://github.com/bitcoin/bitcoin/issues/34019#issuecomment-3617990387)
I seem to have 7204 ipv4 nodes in my tried table with a timestamp more recent than 90 days ago, split across 3509 /16s. There are 6 /16s with between 100 and 200 tried entries, and another 23 /16s with more than 20 tried entries. At the other end of the scale, there are 2578 /16s with only one node in my tried table, 561 with two nodes, 172 with three, 58 with four, 28 with 5 and 26 with 6.

The network is able to accept 115 inbound connections per node by default (max connections = 125, minus 1
...

💬 ajtowns commented on pull request "scripted-diff: Use LogInfo over LogPrintf":
(https://github.com/bitcoin/bitcoin/pull/29641#issuecomment-3618027049)
ACK fa4395dffd432b999002dfd24eb6f8d7384fbcbe

📝 Sjors opened a pull request: "mining: add getTransactions(ByWitnessID) IPC methods"
(https://github.com/bitcoin/bitcoin/pull/34020)
For Stratum v2 custom job declaration to be bandwidth efficient, the pool can request[^0] only the transactions that it doesn't know about.

The spec doesn't specify how this is achieved, but one method is to call the `getrawtransaction` RPC on each transaction id listed in [DeclareMiningJob](https://stratumprotocol.org/specification/06-Job-Declaration-Protocol?query=DeclareMiningJob#644-declareminingjob-client-server) (or a subset if the pool software maintains a cache). Using RPC is ineffici
...

💬 Sjors commented on issue "rpc: getrawtransaction lookup by witness txid":
(https://github.com/bitcoin/bitcoin/issues/34013#issuecomment-3618231614)
See #34020 for the IPC approach.

🤔 arejula27 reviewed a pull request: "Add util::Expected (std::expected)"
(https://github.com/bitcoin/bitcoin/pull/34006#pullrequestreview-3546080852)
conceptACK [fa76a6620012fb738639d8fd7ce17b185bfd376c]

This PR is valuable because it creates a smooth path toward adopting the new C++23 standard. Instead of requiring a full refactor to `std::expected` all at once, it allows the codebase to transition gradually, simply by replacing `utils::expected` with `std::expected` later on.

I also like the idea of introducing this error handling paradigm into the repository. `expected` is a clean way to handle errors and aligns with the modern progr
...

💬 arejula27 commented on pull request "Add util::Expected (std::expected)":
(https://github.com/bitcoin/bitcoin/pull/34006#discussion_r2593725731)
I think the current wording is a bit vague. It might be rewritten along the lines of:
```
//! It is intended for high-level functions that need to report error strings **directly**
//! to end users. Any lower-level functions that don't need this error-reporting...

```
However, Result in our codebase isn’t limited to reporting errors to end users. As @ryanofsky noted in PR #25665, there are broader use cases. One strong example is:
>Result may also be a better choice than std::expected wh
...