💬 maflcko commented on issue "intermittent timeout in wallet_signer.py : 'createwallet' RPC took longer than 1200.000000 seconds":
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3058393000)
Maybe this is https://github.com/bitcoin/bitcoin/issues/32524, but with N=1 and no way to reproduce, this seems difficult to debug.

💬 johnnyasantoss commented on issue "bitcoin core crashes when too many rpc calls are made":
(https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-3058443028)

> what version were you running?

We upgraded since then, but if I recall correctly it was version `26` (upgraded because of p2pv2)

💬 murchandamus commented on pull request "FUZZ: Test that BnB finds best solution":
(https://github.com/bitcoin/bitcoin/pull/32894#issuecomment-3058605059)
Thanks @maflcko, I fixed the sentence.

📝 hebasto opened a pull request: "depends: Force `CMAKE_EXPORT_NO_PACKAGE_REGISTRY=TRUE`"
(https://github.com/bitcoin/bitcoin/pull/32943)
When using CMake policies 3.14 and below, the `export(PACKAGE)` command by default populates the user package registry, which is stored outside the build tree. Setting the `CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable disables this side effect.

In CMake 3.15 and later, this behavior is disabled by default, and the variable has no effect.

This PR forces `CMAKE_EXPORT_NO_PACKAGE_REGISTRY=TRUE` globally, rather than managing it for each dependency package individually rather. It may be reverted
...

🤔 instagibbs reviewed a pull request: "p2p: improve TxOrphanage denial of service bounds"
(https://github.com/bitcoin/bitcoin/pull/31829#pullrequestreview-3006927847)
reviewed through 76e65b8d2982764c9f47be925c26bef23ad0ab97

💬 instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2198516588)
fits in a block, just not very typical? How was this value chosen?

💬 instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2198479997)
Maybe leave a comment that discrepencies between the simulation and real Limiting will be revealed below in full comparison

💬 instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2198505837)
```Suggestion
// Constructs a transaction using a subset of inputs[start_input : start_input + num_inputs] up to the weight_limit.
```

💬 instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2198465090)
ones not present?

💬 instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2198517643)
```Suggestion
// Transactions with 9 inputs maximize the computation / LatencyScore ratio.
```

💬 achow101 commented on pull request "Resolve guix non-determinism with emplace_back instead of push_back":
(https://github.com/bitcoin/bitcoin/pull/32930#issuecomment-3058896316)
x86_64 guix build of f43571010e38

```
$ find guix-build-f43571010e38/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
bb9e6435df82cfe01c78e046ef39cea62a3b0ad0deafa66e1d2a15257bc21eeb guix-build-f43571010e38/output/dist-archive/bitcoin-f43571010e38.tar.gz
7d3bc9459a51abcb2d9d36b69fc135cbb4940c092a9f8df63032c6e9f659a958 guix-build-f43571010e38/output/x86_64-w64-mingw32/SHA256SUMS.part
34af63c893a315745364d1f4dd36bbc1521eef0cad42ea964ba1d0dc5cbcf738 guix-build-f4357101
...

💬 l0rinc commented on pull request "Resolve guix non-determinism with emplace_back instead of push_back":
(https://github.com/bitcoin/bitcoin/pull/32930#discussion_r2198649602)
do we need to create a temp copy or would this also work?
```suggestion
vecSend.emplace_back(DecodeDestination(rcp.address.toStdString()), rcp.amount, rcp.fSubtractFeeFromAmount);
```

💬 achow101 commented on pull request "Resolve guix non-determinism with emplace_back instead of push_back":
(https://github.com/bitcoin/bitcoin/pull/32930#discussion_r2198651313)
https://github.com/bitcoin/bitcoin/pull/32930#issuecomment-3056019241 and https://github.com/bitcoin/bitcoin/pull/32930#discussion_r2196837764

💬 l0rinc commented on pull request "Resolve guix non-determinism with emplace_back instead of push_back":
(https://github.com/bitcoin/bitcoin/pull/32930#discussion_r2198651842)
Ah, it was already the case before, my bad

💬 l0rinc commented on pull request "Resolve guix non-determinism with emplace_back instead of push_back":
(https://github.com/bitcoin/bitcoin/pull/32930#issuecomment-3058951465)
code review ACK f43571010e3853e83a21aa4774b1c8da47b5d961

🤔 instagibbs reviewed a pull request: "cluster mempool: add TxGraph work controls"
(https://github.com/bitcoin/bitcoin/pull/32263#pullrequestreview-3007132369)
review through 18e40b6cd5a11e23b7a0654bdd12f08e610ce980

no big concerns on first pass

💬 instagibbs commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2198611036)
```Suggestion
/** The number of linearization improvements steps needed per cluster to be considered acceptable. */
```

💬 instagibbs commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2198624434)
```Suggestion
Assume(iters >= iters_done);
auto [cost, optimal] = queue[pos].get()->Relinearize(*this, iters - iters_done);
```

💬 instagibbs commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2198587961)
would this also be trivially true for `<=2`?

💬 instagibbs commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2198654706)
would it be possible to assert that this must return true if the value is high enough since we have a limited txgraph size?