💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999102885)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995511334

> I think this `SnapshotcompletionResult` variant can be removed, no?

Good catch, removed.

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999444438)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995921074

> Nit: Are we still doing `-present` now? I thought I saw some discussion about that recently, but can't find it anymore.

The change to "present" never made sense to me because I think the only thing "present" could mean is "when this line was written", not what we might want it to mean like "whenever the code here was last modified" or "whenever the code here was published."

Since "present" just seems like a more
...

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999397249)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995597388

> In commit [9853c83](https://github.com/bitcoin/bitcoin/commit/9853c8384e1df9ad14c2801e780cc189ac20c6d0): Is the validity check required? AFAICT the historic chainstate is never invalid.

That's true. This anticipates a later change but there is no reason to add that complexity here. Dropped this condition.

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999459380)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995924122

> Nit: `s/if is/if it is/`. I think there are some missing articles around here too.

Thanks, fixed up various comments in this header.

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999111743)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995503615

> In commit [22bfd94](https://github.com/bitcoin/bitcoin/commit/22bfd948f0d45083748724a304fa2c8482464028): Just a note: The removal of this particular check in this commit seems a bit random with all the following kind of redundant assertions, but the code does get cleaned up in later commits.

We might be noticing different things here so let me know if you have suggestions for improving this, but I don't think this c
...

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r2001594456)
In commit "refactor: Add ChainstateManager::ActivateBestChains() method" (58265b955a3d8622f22958943f79409129d58b36)

re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1996247059

> Shouldn't this skip over the historical chainstate if `m_target_utxohash` is set?

Yes good catch. Updated this to be equivalent.

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r2001593749)
In commit "refactor: Add ChainstateManager::m_chainstates member" (5e22fdcdb2665c0bb5e47c53719796096afe2dd1)

re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1996212305

> I don't quite follow this change. What is wrong with using `CurrentChainstate` here?

IMO chainstatemanager should generally just validate and update chainstates with incoming data and not rely on concept of a "current" chainstate. The concept of a current chainstate is a little vague and makes more sense a
...

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r2001594940)
In commit "refactor: Delete ChainstateManager::GetAll() method" (ca48478fbfcc83cc6f8c928e57800707fe0c3b51)

re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1996249639

> I'm surprised this is not just taking the `m_chainstates` size. Why is that?

Wrote a better comment since existing comment wasn't really explaining what was happening here. It's possible this code might need to be updated to customize pruning behavior if more chainstates are added in the future. But I think
...

💬 ryanofsky commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1999460229)
re: https://github.com/bitcoin/bitcoin/pull/30214#discussion_r1995939302

> Nit: `s/this a/this is a/`

Thanks, fixed

💬 darosior commented on pull request "qa: fix an off-by-one in utxo snapshot fuzz target and sanity check its snapshot data":
(https://github.com/bitcoin/bitcoin/pull/31910#discussion_r2002057033)
I figured its name already implies what it's doing and expecting (an entirely valid block, not only valid PoW), and didn't want to just add a comment like "Process a block" (akin to `PrepareBlock` right below whose docstring states "Prepare a block"). I felt only the return value was not clear from the function declaration, hence why specifying it in the docstring.

💬 mzumsande commented on pull request "validation: stricter internal handling of invalid blocks":
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2002112881)
That's a good idea! I think we can even go one step further and use `highpow_outofchain_headers` for everything, also for `cand_invalid_descendants` (at the cost of doing a few `GetAncestor()` calls, which should be cheap enough). I pushed an updated version that uses this approach.

💬 mzumsande commented on pull request "validation: stricter internal handling of invalid blocks":
(https://github.com/bitcoin/bitcoin/pull/31405#issuecomment-2734888712)
[4ba2e48](https://github.com/bitcoin/bitcoin/commit/4ba2e480ffa0b77113953bee4ff5c9349e277e7e) to [fd39a64](https://github.com/bitcoin/bitcoin/commit/fd39a6420dad4cfc8bfff73f32df663da1ec00e2):
I changed the approach to `InvalidateBlock()` after the suggestion by @stickies-v: Instead of having 3 slightly different caches, now only one cache is used for everything (`highpow_outofchain_headers`). This should make the changes more simple and have a negligible overhead of a few additional `GetAncesto
...

💬 brunoerg commented on issue "Failure to run Fuzz tests when running with corpus":
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2734905310)
Worth adding this "false positive" information to the documentation?

🤔 murchandamus reviewed a pull request: "test: Add expected result assertions"
(https://github.com/bitcoin/bitcoin/pull/31656#pullrequestreview-2696483047)
ACK a015b7e13daacdfb6db0eada50563dec70c5afb2

🚀 fanquake merged a pull request: "test: avoid disk space warning for non-regtest"
(https://github.com/bitcoin/bitcoin/pull/32057)

💬 fanquake commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2002163254)
The comment still doesn't really explain why. Why is this needed (now, and not with Qt 5)? Why aren't the depends outputs already suitable for static linking? Why do we need to restrict the search paths, nothing should be looking outside of depends?

🚀 fanquake merged a pull request: "test: switch wallet_crosschain.py to signet and drop testnet4"
(https://github.com/bitcoin/bitcoin/pull/32088)

💬 mzumsande commented on pull request "test: Fix intermittent issue in p2p_orphan_handling.py":
(https://github.com/bitcoin/bitcoin/pull/32092#discussion_r2002175061)
it would be good to also add a comment in `disconnect_p2ps` that the wait there does not guarantee that the resources of all nodes (such as outstanding txrequests) are cleared.

💬 murchandamus commented on issue "BnB untested/unused condition in UTXO exclusion optimization":
(https://github.com/bitcoin/bitcoin/issues/32047#issuecomment-2734990522)
> The only way for the fees to be different is if the effective_value is different, however the previous condition: `utxo.GetSelectionAmount() != utxo_pool.at(utxo_pool_index - 1).GetSelectionAmount()` already compared the effective_values.

This is not accurate. You could have two UTXOs of different output types that have the same effective value but differing fees:

E.g.:

Feerate: 10 sat/vB

UTXO_1:
type: P2WPKH,
input weight: 68 vB
amount: 10,680 sats
eff_value: 10,680 - 680 = 10,000
...

👍 darosior approved a pull request: "leveldb: pull upstream C++23 changes"
(https://github.com/bitcoin/bitcoin/pull/31766#pullrequestreview-2696569585)
ACK c8fab356171a0e283d5716647e3243c04810ac51 -- checked it's a clean subtree pull from https://github.com/bitcoin-core/leveldb-subtree/tree/bitcoin-fork