💬 TheCharlatan commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2353555803)
It seems to have found something:
```
#234857 REDUCE cov: 862 ft: 5138 corp: 265/28Kb lim: 1689 exec/s: 303 rss: 854Mb L: 1178/1640 MS: 4 ChangeByte-EraseBytes-InsertByte-InsertByte-
#236845 NEW cov: 862 ft: 5140 corp: 266/29Kb lim: 1699 exec/s: 303 rss: 854Mb L: 1652/1652 MS: 3 CopyPart-CMP-CopyPart- DE: "N10__cxxabiv"-
#237681 REDUCE cov: 862 ft: 5140 corp: 266/29Kb lim: 1699 exec/s: 303 rss: 855Mb L: 23/1652 MS: 2 EraseBytes-PersAutoDict- DE: "St9exception"-
ALARM: working on the last
...

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2353578407)
I think it would still be necessary to note what the session id is composed of.

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2353592463)
A cannot add their sig before B has added a pubnonce. Furthermore, if A added their sig, then the secnonce would be already be deleted.

If B instead provides a "new" PSBT which is really just the original PSBT with their pubnonce, and without A's pubnonce, then it's fine to "reuse" the nonce since that is equivalent to combining both PSBTs.

💬 fjahr commented on pull request "rpc: add scan_utxoset option to getbalance(s) to verify wallet balance accuracy":
(https://github.com/bitcoin/bitcoin/pull/33392#issuecomment-3300319224)
> Yes, I have looked into adding the option to importdescriptors by introducing a scan_utxoset flag and it's possible. The idea is that when enabled, the wallet would scan the UTXO set immediately after import to verify balances against chainstate, and if a discrepancy is detected (for example due to an incorrect birthdate), it could automatically trigger a full rescan from height 0 to restore missing history. This way, users wouldn’t have to manually diagnose incomplete balances — the import fl
...

💬 furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2353648451)
Very nice!
Played a bit with the code, pushed some (dirty and untested) extensions here: https://github.com/furszy/bitcoin-core/commits/2022_parallelize_blockfilter_index_2_fuzz/

> It seems to have found something

will check it out. Thanks!. I was having fun with the code first :).

🤔 l0rinc reviewed a pull request: "log: always print initial signature verification state"
(https://github.com/bitcoin/bitcoin/pull/33336#pullrequestreview-3231017555)
Thanks for the reviews, I have simplified the commits, removed the enum and replaced it with direct reason string, added an `off best‑header path` (thanks to @hodlinator), reworded the log to say "script verification" instead of "signature validations" to be in alignment with the "Script verification uses ... additional threads" and reverted the `fScriptChecks` and `m_prev_script_checks_logged` symbols.

There's a remaining suggestion to have friendlier reason in case of:
```
2025-09-16T21:00:03
...

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353625992)
Reverted since it caused more confusion that it fixed

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353349979)
Cheap script checks (such as sigop counts) are still checked regardless of this option, it's the signatures that aren't (so *some* script sanity checking is still happening, but the scripts aren't interpreted - that's my understanding, please correct me if I'm wrong. Maybe I should update the warning message in that case to make it clear that a few other checks are also skipped, not just the signatures).

And I want to propose a change to [skip bip30 checks](https://github.com/bitcoin/bitcoin/bl
...

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353190912)
Was trying to recreate production code logic in test, but I don't mind making it more explicit if you think it's more descriptive.
The block validation errors seem out-of-scope, but I don't mind them either, thanks, added you as coauthor to the last commit as well.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353637282)
I'm not sure I fully understand - do you want me to add a different reason when the current block is valid, but just after the assumevalid block?

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353628930)
fantastic, I had something similar but only got to 90%.
Added the change as node 3 since it has a similar starting condition as the rest of the nodes, simplifies the header send to only create the needed headers and send all of them and fixed the waiting condition.
Added you as coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353634828)
I have added a reason string with limited scope next to the `bool`, let me know what you think. Added you ad coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353201643)
The args are only invalid in relation to the blocks, so we need at least one block to invalidate the args.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2353652988)
Ii have reverted the naming

💬 l0rinc commented on pull request "help: enrich help text for `-loadblock`":
(https://github.com/bitcoin/bitcoin/pull/33343#issuecomment-3300371394)
I think we should try it ourselves before recommending it in the documentation

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2353675490)
I'm going to leave this as-is for now since changing the type causes a ton of other things to be changed, particularly in PSBT and SignatureData. We also use the fact that it's a vector to indicate when a pubnonce was not successfully created, and turning it into an array requires changing all of those returns as well.

📝 hebasto opened a pull request: "msvc: Update vcpkg manifest"
(https://github.com/bitcoin/bitcoin/pull/33408)
This PR updates the vcpkg manifest baseline from the ["2025.03.19 Release"](https://github.com/microsoft/vcpkg/releases/tag/2025.03.19) to the ["2025.08.27 Release"](https://github.com/microsoft/vcpkg/releases/tag/2025.08.27), with the following package
changes:
- `boost`: 1.87.0 --> 1.88.0
- `qtbase`: 6.8.2#1 -> 6.9.1
- `qttools`: 6.8.2 -> 6.9.1
- `sqlite3`: 3.49.1 --> 3.50.4

The previous update was made in https://github.com/bitcoin/bitcoin/pull/32213.

Additionally, the obsolete
...

👋 willcl-ark's pull request is ready for review: "Backport Cirrus runners to 28.x"
(https://github.com/bitcoin/bitcoin/pull/33406)

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2353681237)
We want to avoid libsecp includes and linking being everywhere throughout the codebase that a pubnonce might appear, so we prefer to use something that contains the serialized nonce, and deserializing it into `secp256k1_musig_pubnonce` when needed.

💬 l0rinc commented on pull request "log: show reindex progress in `ImportBlocks`":
(https://github.com/bitcoin/bitcoin/pull/33353#discussion_r2353681440)
Thanks @enirox001, I think the 0% is fine and we've just calculated `total_files`, no need to guard and the percentage is the same as the `nFile+1/total_files`, I don't see the need to duplicate it.