🚀 glozow merged a pull request: "txgraph: use enum Level instead of bool main_only"
(https://github.com/bitcoin/bitcoin/pull/33354)

📝 sipa converted_to_draft a pull request: "Replace cluster linearization algorithm with SFL"
(https://github.com/bitcoin/bitcoin/pull/32545)
Part of cluster mempool: #30289. Based on #30605.

This replaces the cluster linearization algorithm introduced in #30126 and #30286 (a combination of LIMO with candidate-set search), with a completely different algorithm: [spanning-forest linearization](https://delvingbitcoin.org/t/spanning-forest-cluster-linearization/1419/1), which appears to have much better performance for hard clusters. See [this post](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68) for a comparison be
...

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-3281455036)
I'm working on some improvements and reorganization of the commit here, so marking it as draft for now.

💬 sipa commented on pull request "txgraph: randomize order of same-feerate distinct-cluster transactions":
(https://github.com/bitcoin/bitcoin/pull/33335#discussion_r2341550686)
Eh. When seen individual comparisons in isolation, independently, each has a probability of exactly 2^-64 of being a collision.

But within a group of N clusters, the ability that at least one pair exists whose hashes will collide, is approximately `1-exp(-N*(N-1)/2^65)`. You can be even more precise, as only pairs of clusters which have chunks with equal feerates matter, but this is a sufficiently low bound that I don't think we care.

💬 l0rinc commented on pull request "validation: ensure assumevalid is always used during reindex":
(https://github.com/bitcoin/bitcoin/pull/31615#issuecomment-3281660246)
While just restarting the node with this commit didn't help for some reason, doing a reindex with it does seem to disable signature verification successfully. But it doesn't actually seem to fix the underlying problem, since `./build/bin/bitcoin-cli -datadir=$DATA_DIR getblockchaininfo | jq .headers` still returns `841150` for me.

So while it does seem to work around the issue described in https://github.com/bitcoin/bitcoin/pull/33336#issuecomment-3277968407, it doesn't seem to solve the unde
...

⚠️ fanquake opened an issue: "v30.0 Testing"
(https://github.com/bitcoin/bitcoin/issues/33368)
Umbrella issue for 30.0 testing. Please help testing on a wide variety of supported platforms, as well as interaction with different software.

Let us know which version you tested on which operating system.

If you find an issue, please search Github for known issues first and then open a new Github issue.

This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.

See [30.0 Release Notes Draft](https://github.com/bitcoin-core/bitcoi
...

⚠️ fanquake pinned an issue: "v30.0 Testing"
(https://github.com/bitcoin/bitcoin/issues/33368)
Umbrella issue for 30.0 testing. Please help testing on a wide variety of supported platforms, as well as interaction with different software.

Let us know which version you tested on which operating system.

If you find an issue, please search Github for known issues first and then open a new Github issue.

This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.

See [30.0 Release Notes Draft](https://github.com/bitcoin-core/bitcoi
...

💬 l0rinc commented on pull request "common: Make arith_uint256 trivially copyable":
(https://github.com/bitcoin/bitcoin/pull/33332#issuecomment-3281739187)
ACK 653a9849d5f98ba80e334ddc0ae9a5e367459f59

I'm fine with the change as it is currently, would prefer more implicit behavior instead (the original PR), but this is also better than before, thanks for doing it.

👋 l0rinc's pull request is ready for review: "coins: warn on oversized `-dbcache`"
(https://github.com/bitcoin/bitcoin/pull/33333)

🤔 enirox001 reviewed a pull request: "test/refactor: use test deque to avoid quadratic iteration"
(https://github.com/bitcoin/bitcoin/pull/33313#pullrequestreview-3212757868)
ACK https://github.com/bitcoin/bitcoin/commit/8c1f10233dc9a843147772c40973031f5bfdbb7c. This is a solid improvement. While the benefits may not be immediately obvious, it’s a valuable addition. I ran the functional tests and everything passed successfully.

💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#issuecomment-3281939547)
Rebased after #33354 merge.

💬 willcl-ark commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#issuecomment-3282061941)
Concept ACK

I think warning when someone is likely going to clobber their system performance is useful.

This change introduces a warning on lower limit of free RAM remaining; would it make sense to also include an upper bound to suppress/skip the warning? The cap is set to warn when < 1.5GB is left free in the case RAM is below 2GB, but will then warn when I have 16GB of ram free:

```
src/core/bitcoin on  pr-33333 [$] via △ v3.31.6 via 🐍 v3.13.3 via ❄️ impure (nix-shell-env) took 3s
...

💬 davidgumberg commented on pull request "ci: always use tag for LLVM checkout":
(https://github.com/bitcoin/bitcoin/pull/33364#issuecomment-3282063472)
ACK https://github.com/bitcoin/bitcoin/commit/b736052e39f1f466f63f261ace3dd2deba171e8a

👍 darosior approved a pull request: "Bump SCRIPT_VERIFY flags to 64 bit"
(https://github.com/bitcoin/bitcoin/pull/32998#pullrequestreview-3212374162)
ACK 652424ad162b63d73ecb6bd65bd26946e90c617f

I think it would also make sense, in a follow-up, to move the rest of the Script verification flags stuff to the new `verify_flags.h`.

💬 darosior commented on pull request "Bump SCRIPT_VERIFY flags to 64 bit":
(https://github.com/bitcoin/bitcoin/pull/32998#discussion_r2341455180)
I was curious why this constructor from `int` with a runtime check was necessary. It's because of all the `if ((flags & SCRIPT_VERIFY_X) != 0)` in the interpreter. This permits to implicitly construct a `script_verify_flags` from the `0` there instead of either having an implicit conversion *to* integer (the very thing this aims to avoid), or touching every single of those checks to make the conversion from the `0` integer explicit.

💬 darosior commented on pull request "Bump SCRIPT_VERIFY flags to 64 bit":
(https://github.com/bitcoin/bitcoin/pull/32998#discussion_r2341832137)
How is the rule of 5 relevant for this class? It does not need a user-defined destructor.

From cppreference's [Rule of 5 section](https://en.cppreference.com/w/cpp/language/rule_of_three.html#Rule_of_five):
> Because the presence of a user-defined (include = default or = delete declared) destructor, copy-constructor, or copy-assignment operator prevents implicit definition of the [move constructor](https://en.cppreference.com/w/cpp/language/move_constructor.html) and the [move assignment ope
...

💬 instagibbs commented on pull request "Bump SCRIPT_VERIFY flags to 64 bit":
(https://github.com/bitcoin/bitcoin/pull/32998#issuecomment-3282095349)
reACK https://github.com/bitcoin/bitcoin/pull/32998/commits/652424ad162b63d73ecb6bd65bd26946e90c617f

💬 l0rinc commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#issuecomment-3282103704)
> would it make sense to also include an upper bound to suppress/skip the warning

I'm afraid it would be interpreted as a recommendation in that case - all we can claim is that this is likely too high, we can't actually know the optimal size

> feels a shame to introduce new false positives if we can avoid it?

You mean that the uxto size is less than 48 GiB therefore the warning isn't relevant?

💬 theuni commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#discussion_r2342101039)
Hmm, is it necessary for `CMAKE_EXE_LINKER_FLAGS` to also contain `HOST_LDFLAGS`? I would have expected CMake to use both for exe's.

💬 katesalazar commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3282309789)
ty