🤔 pablomartin4btc reviewed a pull request: "wallet: init, don't error out when loading legacy wallets"
(https://github.com/bitcoin/bitcoin/pull/32449#pullrequestreview-2845981748)
It seems that `wallet_backwards_compatibility.py` is being skipped in the CIs?


And I got this error when I run it locally:

```
2025-05-16T13:44:41.540000Z TestFramework (INFO): Testing inactive hd chain bad derivation path cleanup
2025-05-16T13:44:43.146000Z TestFramework (INFO): Test that legacy wallets are ignored during startup on v29+
2025-05-16T13:44:43.592000Z TestFramework (INFO): Stoppin
...

💬 pablomartin4btc commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2092636812)
nit: I'd use the same ref to the `node_master` as above...
```suggestion
self.restart_node(node_master.index, extra_args=[])
# Verify node is active after restart
node_master.getblockcount()
```

💬 pablomartin4btc commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093187305)
I think something like this (or within a function called `assert_restart_raises_init_warning`):
```suggestion
# Restart latest node and verify that the legacy wallet load is skipped with a warning during init.
with node_master.assert_debug_log([f"Failed to open database path '{wallet_path}'. The wallet appears to be a Legacy wallet, please use the wallet migration tool (migratewallet RPC or the GUI option)."]):
self.restart_node(node_master.index, extra_args=[])

...

💬 fanquake commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#issuecomment-2887005738)
> It seems that wallet_backwards_compatibility.py is being skipped in the CIs?

It is run in the previous releases CI, which is the one that is failing in this PR: https://github.com/bitcoin/bitcoin/runs/42313448794.

💬 l0rinc commented on pull request "refactor: reenable `implicit-integer-sign-change` check for `serialize.h`":
(https://github.com/bitcoin/bitcoin/pull/32296#issuecomment-2887006170)
Thanks for the reviews and for splitting out `prevector`!
A follow-up that reenables the coins cache sanitizers by fixing the used cache accounting is done in https://github.com/bitcoin/bitcoin/pull/32313

💬 pablomartin4btc commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#issuecomment-2887006977)
> > Is it worth it to verify that, previous to this PR, the node with the legacy wallet in its `settings.json` was failing to restart (using `assert_start_raises_init_error`)?
>
> That's what is being tested. You can run the test on master and it will fail due to that behavior.

I meant without switching to `master` and once this PR gets merged, I thought there was a release with this failure and your fix will be in the next one, but both changes will be part of the same release so the answ
...

💬 pablomartin4btc commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093241973)
I've left a [suggestion](https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093187305).

💬 mzumsande commented on issue "avoid using invalidateblock to directly test reorg behavior":
(https://github.com/bitcoin/bitcoin/issues/32531#issuecomment-2887013040)
> > Why not simply submit the fork chain at the right point in time
>
> Sure, that works too, it just seemed easiest since you can use ~all the tooling to generate blockchains. e.g., if you want stuff in the fork blocks (and make as many blocks as you like) it's trivial to do via rpcs like generateblock.

Oh ok I see now, as in https://github.com/bitcoin/bitcoin/pull/32516/commits/16af944a547bfea8f1f910938491a8ad11a47de5. Could also prepare the fork chain on a second node using whatever toolin
...

📝 fanquake opened a pull request: "Update leveldb subtree to latest upstream"
(https://github.com/bitcoin/bitcoin/pull/32534)
Pulls in
* https://github.com/bitcoin-core/leveldb-subtree/pull/51

Remove the related warning suppression.

💬 rkrux commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#discussion_r2093245598)
> Not sure what would be verified? After invalidateblock and before the crash, we do verify that the coinbase transaction is marked abandoned.

I wanted to check that the best block locator is indeed persisted to disk after invalidation but the `getwalletinfo` RPC reads from memory, which can't be used for verifying this PR's change. The coinbase transaction verification was done before this PR as well, so that also not verifies.

Previously, I had in mind some functionality that reads from
...

💬 maflcko commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2887022304)
> > After this PR, it will mean your chain tip's timestamp is within 2 hours of now.
>
> I think that's a worse cure than the disease. In case we **know** there are unprocessed blocks in the chain (because we have their headers), we shouldn't say progress: 1.

I don't think this is making anything worse. This is already possible on current master, when a miner sets the timestamp to a future one (compared to your time), even if there are still blocks ahead.

💬 pablomartin4btc commented on pull request "wallet, refactor: Remove Legacy wallet unused warnings and errors":
(https://github.com/bitcoin/bitcoin/pull/32481#discussion_r2093251942)
maybe neither do this one:

https://github.com/bitcoin/bitcoin/blob/39090518f62cca5432413d1669a85924ba721278/src/wallet/wallet.cpp#L448

(just to confirm and do both in 1 go)

💬 l0rinc commented on pull request "Update leveldb subtree to latest upstream":
(https://github.com/bitcoin/bitcoin/pull/32534#issuecomment-2887030315)
utACK 7015052eba23368539dcd1a9b4217ce1cacd2999

For the record, there are other `LevelDB` changes that could use some reviews: https://github.com/bitcoin-core/leveldb-subtree/pulls

💬 furszy commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#issuecomment-2887030525)
The issue is caused by the stderr warning message not being consumed. The framework expects stderr to be empty at the end of the test, without accounting for warning messages. Will update the test to clear the buffer after startup.

💬 mzumsande commented on pull request "validation: ensure assumevalid is always used during reindex":
(https://github.com/bitcoin/bitcoin/pull/31615#discussion_r2093270847)
I meant the 2100 (two weeks) of of blocks. I didn't test this, but is there a reason this couldn't just be a few blocks (plus a few more that aren't sent to the node)?

💬 maflcko commented on pull request "[28.x] build: suppress `-Wunterminated-string-initialization` in secp256k1":
(https://github.com/bitcoin/bitcoin/pull/32484#issuecomment-2887069576)
An alternative would be to just ignore the warning? CI on 28.x isn't using gcc 15 and users aren't really expected to compile with werror?

🤔 darosior reviewed a pull request: "test: properly check for per-tx sigops limit"
(https://github.com/bitcoin/bitcoin/pull/32533#pullrequestreview-2847007268)
Concept ACK

💬 fanquake commented on pull request "[28.x] build: suppress `-Wunterminated-string-initialization` in secp256k1":
(https://github.com/bitcoin/bitcoin/pull/32484#issuecomment-2887084027)
We could also do that. I guess it depends where we expect this branch to be compiled. Any downstream CIs, build systems, packagers etc may be turning warnings into errors. It doesn't seem bad for us to suppress known non-issues.

📝 maflcko opened a pull request: "rev_32343_wip_nomerge_ci"
(https://github.com/bitcoin/bitcoin/pull/32535)
pls ignore this is just a #32524 playground

💬 fanquake commented on pull request "build: Introduce internal kernel library":
(https://github.com/bitcoin/bitcoin/pull/28690#discussion_r2093340350)
Should also be easy to get `bitcoin_clientversion` out of here.