💬 pinheadmz commented on pull request "wallet: fix crash on double block disconnection":
(https://github.com/bitcoin/bitcoin/pull/31757#discussion_r1989334604)
nanonit: funny, the only occurrences of `assert(...` (with parenthesis instead of just a space) are in this test ;-)

👍 brunoerg approved a pull request: "Require sqlite when building the wallet"
(https://github.com/bitcoin/bitcoin/pull/31961#pullrequestreview-2674676295)
code review ACK ac6cde731314d981391bc313c98d671c68211d33

🤔 rkrux reviewed a pull request: "psbt: MuSig2 Fields"
(https://github.com/bitcoin/bitcoin/pull/31247#pullrequestreview-2674241033)
Partial review.

Some of the suggested comments I have not categorised as nits so that the newer changes are consistent with the rest of the wallet codebase. However, I'm open to them not being implemented if the PR author and other reviewers believe so.

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989154933)
Here and in other similar occurrences of 33.

```diff
-while (s_val.size() >= 33) {
+while (s_val.size() >= CPubKey::COMPRESSED_SIZE) {
```

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989175187)
Using `CPubKey::COMPRESSED_SIZE + 1` here instead of `34` would make it more explicit and reader-friendly (similarly in the other key unserialization flows below) like done for `PSBT_IN_PARTIAL_SIG` and `PSBT_IN_RIPEMD160` cases previously.

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989129187)
I think these 2 can be benefited with some documentation something like below. It was only after I read the below serialisation code that I understood this type.

```cpp
/** key is a pair of aggregate public key and leaf hash, value is a map of participant pubkey to pubnonce */
std::map<std::pair<CPubKey, uint256>, std::map<CPubKey, std::vector<uint8_t>>> m_musig2_pubnonces;
/** key is a pair of aggregate public key and leaf hash, value is a map of participant pubkey to partial sig */
std:
...

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989151765)
Nit for verbosity here and in the partial sigs loop below.

```diff
-for (const auto& [pubkey, pubnonce] : pubnonces) {
+for (const auto& [participant_pubkey, pubnonce] : pubnonces) {
```

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989218447)
Since it is being reused now, maybe a constant or an enum can also be an option.

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989223541)
I would be in favour of using `compressed` terminology here over `plain` like proposed in the BIP change here: https://github.com/bitcoin/bips/pull/1705

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989243401)
`agg_pubkey`?

Using only `key` alludes to the private key though in this case there is no aggregate private key but still to be consistent with the rest of the codebase and to get rid of any doubt in the mind of the reader.

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989209332)
Maybe?

`(2 * CPubKey::COMPRESSED_SIZE + 1)`
`(2 * CPubKey::COMPRESSED_SIZE + CSHA256::OUTPUT_SIZE + 1)`

💬 rkrux commented on pull request "psbt: MuSig2 Fields":
(https://github.com/bitcoin/bitcoin/pull/31247#discussion_r1989306381)
`_pubkeys` instead of `_keys`

In order to be consistent with the codebase

💬 l0rinc commented on issue "Fully validated AssumeUTXO starts revalidating after restart":
(https://github.com/bitcoin/bitcoin/issues/32029#issuecomment-2714449973)
Thanks for the context @mzumsande, @Sjors, @fjahr.

> so that a user that Ctrl+C's out of the first check

The first check finished fully (took me several nights), but now if I want to use that node, I still can't because it's validating again.

I didn't cancel it this time, the new validation after restart took *23.5 more minutes* (it's frustrating to wait here, maybe https://github.com/bitcoin/bitcoin/pull/31645 helps), telling me yet again that `has been fully validated`:
```bash
[...]
2025-0
...

💬 ryanofsky commented on pull request "build: Enhance Ccache performance across worktrees and build trees":
(https://github.com/bitcoin/bitcoin/pull/30861#issuecomment-2714472813)
> > I don't think there are any. Just mentioned this because `-fdebug-prefix-map` seems to be added conditionally in our build.
>
> Specifically, which condition are you referring to?

`-fdebug-prefix-map` is only added if `try_append_cxx_flags` succeeds and if the compilation target explicitly links against `core_interface`. It's reasonable to assume that these things are always true, but since correctness of the output when CCACHE_NOHASHDIR=1 is used seems to depend on them it would be go
...

💬 hebasto commented on pull request "qt: 29.0 translations update":
(https://github.com/bitcoin/bitcoin/pull/32004#issuecomment-2714561117)
> It would still be good to point to some place on Transifex where reviewers can see that discussion.

I've posted an announcement, which refers to this PR:
- on the Transifex website -- https://app.transifex.com/bitcoin/communication/d:4ca41e70-aeda-4632-83d1-b20b3bbd0dd9/?q=project%3Abitcoin
- on the ML -- https://groups.google.com/g/bitcoin-translators/c/qam5uo0h7cA

💬 ryanofsky commented on issue "build: ccache doesn't hit across build dirs":
(https://github.com/bitcoin/bitcoin/issues/31994#issuecomment-2714578102)
Thanks for writing this up so clearly. It would be good to add this to the documentation.

re: https://github.com/bitcoin/bitcoin/issues/31994#issuecomment-2708846512

> Additionally, ccache docs [state](https://ccache.dev/manual/4.9.1.html#config_hash_dir):
>
> > The CWD will not be included in the hash if [`base_dir`](https://ccache.dev/manual/4.9.1.html#config_base_dir) is set (_and matches the CWD_) and the compiler option `-fdebug-prefix-map` is used.

I still don't understand why setting
...

💬 hebasto commented on issue "build: ccache doesn't hit across build dirs":
(https://github.com/bitcoin/bitcoin/issues/31994#issuecomment-2714625797)
> Thanks for writing this up so clearly. It would be good to add this to the documentation.
>
> re: [#31994 (comment)](https://github.com/bitcoin/bitcoin/issues/31994#issuecomment-2708846512)
>
> > Additionally, ccache docs [state](https://ccache.dev/manual/4.9.1.html#config_hash_dir):
> > > The CWD will not be included in the hash if [`base_dir`](https://ccache.dev/manual/4.9.1.html#config_base_dir) is set (_and matches the CWD_) and the compiler option `-fdebug-prefix-map` is used.
>
> I st
...

👍 Mikaela11 approved a pull request: "Updated MacOS icon to more closely fit Apple's design standards"
(https://github.com/bitcoin-core/gui/pull/852#pullrequestreview-2674918483)
Michaela Lörinczova

💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2714686904)
Rebased c2c5a0f492ae2ce54afdd031e8a2f2689a8c4942 -> 7e4b3a6e3c6a1bc34dc6af9130922cb71f1f2670 ([`pr/subtree.20`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.20) -> [`pr/subtree.21`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.21), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree.20-rebase..pr/subtree.21)) due to conflict with #31982

👍 theuni approved a pull request: "cmake: Set top-level target output locations"
(https://github.com/bitcoin/bitcoin/pull/31161#pullrequestreview-2674970756)
ACK 568fcdddaec2cc8decba5a098257f31729cc1caa

+1 sjors.

I understand the arguments for/against the symlink, but don't feel strongly either way myself.