💬 hebasto commented on pull request "build: Find Boost in config mode":
(https://github.com/bitcoin/bitcoin/pull/32667#issuecomment-3008949412)
> Needs a rebase for #32814.

Thanks! Rebased.

💬 hebasto commented on pull request "build: Find Boost in config mode":
(https://github.com/bitcoin/bitcoin/pull/32667#issuecomment-3008959403)
Added `EXACT` keyword to `find_package(boost_included_unit_test_framework ...)` command when using vcpkg (on Windows).

💬 maflcko commented on pull request "correct variable name in p2p_monitor.py":
(https://github.com/bitcoin/bitcoin/pull/32816#issuecomment-3008967559)
lgtm ACK 6bb38bf37fd81a9ce2b66a3f078375dce9274754

💬 instagibbs commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2169392812)
TIL. We could use this one in the other standardness check, right?

💬 fjahr commented on issue "`dumptxoutset` rollback feature does not take forks into account":
(https://github.com/bitcoin/bitcoin/issues/32817#issuecomment-3008973146)
Sigh, yeah, that's probably right. When taken to an extreme (aka Testnet4) that's a really annoying problem as I have experienced in #31117. Since I have to deal with this anyway so I will address this soon.

💬 maflcko commented on issue "`dumptxoutset` rollback feature does not take forks into account":
(https://github.com/bitcoin/bitcoin/issues/32817#issuecomment-3008985262)
Isn't this addressed by the `throw` here?

https://github.com/bitcoin/bitcoin/blob/67ea4b9994e668dcea5e5d0f62f886d92e3737dc/src/rpc/blockchain.cpp#L3111


I think there is still a race when calling `submitblock`, but this doesn't seem related to forks per se.

💬 achow101 commented on pull request "Add read-only mode to sqlite db and use in `bitcoin-wallet`":
(https://github.com/bitcoin/bitcoin/pull/32818#issuecomment-3008989919)
How does this compare with #32685?

💬 sipa commented on issue "`dumptxoutset` rollback feature does not take forks into account":
(https://github.com/bitcoin/bitcoin/issues/32817#issuecomment-3008997075)
@maflcko Right! So indeed, it won't (ignoring race conditions) dump the wrong thing - but if you have a fork at a certain height, you'll just be unable to dump at that height.

💬 instagibbs commented on pull request "node: cap `-maxmempool` and `-dbcache` values for 32-bit":
(https://github.com/bitcoin/bitcoin/pull/32530#issuecomment-3009000500)
utACK 9f8e7b0b3b787b873045a4a8194e77d0b0a2b3b6

💬 maflcko commented on pull request "test: enabling wallet migration functional test on windows":
(https://github.com/bitcoin/bitcoin/pull/32219#issuecomment-3009004461)
only small style changes

re-ACK 941b8f54c0d35d3243bb6083f3b52681d1b9a555 🍪

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment:
...

💬 maflcko commented on issue "`dumptxoutset` rollback feature does not take forks into account":
(https://github.com/bitcoin/bitcoin/issues/32817#issuecomment-3009013387)
> you'll just be unable to dump at that height.

Could do a manual `invalidateblock` of the low-work forks to work around the error, but yea, could be annoying if the forks are more than 1, or longer than 1 block.

💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2169429571)
Yeah.

💬 maflcko commented on pull request "util: explicitly close all AutoFiles that have been written":
(https://github.com/bitcoin/bitcoin/pull/29307#discussion_r2169431059)
If a `Commit` is not possible without closing the file, then `Commit` should close the file. Requiring all call sites of `Commit` to manually close the file seems verbose and less safe to me.

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3009050890)
> Whiteboarded in person. Hopefully this explanation is clear and explains it in a more permanent location. If this ends up being correct we can adapt the benchmark to be more realistic.

💬 musaHaruna commented on pull request "rpc: Distinguish between vsize and sigop adjusted mempool vsize":
(https://github.com/bitcoin/bitcoin/pull/32800#discussion_r2169450138)
Done! Thanks for the suggestion it was realy insightful.

🚀 fanquake merged a pull request: "depends: Build `qt` package for FreeBSD hosts"
(https://github.com/bitcoin/bitcoin/pull/32731)

💬 HowHsu commented on pull request "checkqueue: implement a new scriptcheck worker pool with atomic variables":
(https://github.com/bitcoin/bitcoin/pull/32791#issuecomment-3009069508)
> For the CI docs, see https://github.com/bitcoin/bitcoin/tree/master/ci#ci-scripts, but you'll likely have to run that on a 64 core system to recreate the system error

Thanks, maflcko. The thing is this patchset is to extend numbers of scriptcheck threads to nCores-1, so I guess it bound to fail the CI tests. What should I do now.

💬 musaHaruna commented on pull request "rpc: Distinguish between vsize and sigop adjusted mempool vsize":
(https://github.com/bitcoin/bitcoin/pull/32800#discussion_r2169453387)
Fixed

💬 musaHaruna commented on pull request "rpc: Distinguish between vsize and sigop adjusted mempool vsize":
(https://github.com/bitcoin/bitcoin/pull/32800#discussion_r2169457387)
You are right it should be scalled down and rounded up as done in ` return (std::max(nWeight, nSigOpCost * bytes_per_sigop) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR; `. Fixed in [d6f4caf](https://github.com/bitcoin/bitcoin/pull/32800/commits/d6f4caf851ad7a4d9df7a8dc67215870ba9bfe14)

🚀 fanquake merged a pull request: "node: cap `-maxmempool` and `-dbcache` values for 32-bit"
(https://github.com/bitcoin/bitcoin/pull/32530)