💬 maflcko commented on pull request "improve MallocUsage() accuracy":
(https://github.com/bitcoin/bitcoin/pull/28531#discussion_r2109129254)
https://cirrus-ci.com/task/4825274484785152?logs=ci#L3624

```
in sync_mempools
[23:01:19.556] raise AssertionError("Mempool sync timed out after {}s:{}".format(
[23:01:19.556] AssertionError: Mempool sync timed out after 2400s:
[23:01:19.556]

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2109129595)
weight / WITNESS_SCALE_FACTOR = vbytes

A bit confusing

💬 naiyoma commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2109130072)
Delete this instead of commenting it out.

💬 maflcko commented on pull request "improve MallocUsage() accuracy":
(https://github.com/bitcoin/bitcoin/pull/28531#discussion_r2109130959)

that size -> than size [incorrect preposition]
beyojnd -> beyond [typographical error]

💬 naiyoma commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2109136833)
nit: Snake case is preferred for variables. https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#coding-style-c

💬 Crypt-iQ commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-2912452626)
> Dropping seemingly-unsolicited compact blocks seems fine, we already do that for the parallel portion, this should be a change just to the first one?

Yup. You wrote the code so I'm sure you know, but for viewers at home, just the first "slot" would need to be accounted for as the other two slots are [guaranteed to be HB.](https://github.com/bitcoin/bitcoin/blob/87860143be792d219aac7f4a04e79d00016df627/src/net_processing.cpp#L4506)

> So I think the CB probing, in fact, is an additional inform
...

💬 instagibbs commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-2912461827)
> I don't think this is true anymore.

It's ostensibly forwarded once PoW/merkle checks pass, but not promising utxo/script/etc checks.

💬 fanquake commented on pull request "guix: accomodate migration to codeberg":
(https://github.com/bitcoin/bitcoin/pull/32439#issuecomment-2912474792)
Guix Build
```bash
8e7798bc42e611c15022d90cfb525fdaccb0eda0753f3d9a1f85f5d947bcced1 guix-build-c8d9baae942c/output/aarch64-linux-gnu/SHA256SUMS.part
e7b1f02d7f0a8390f596e4ba857e503041c2b8f51099763f2a94527493456d81 guix-build-c8d9baae942c/output/aarch64-linux-gnu/bitcoin-c8d9baae942c-aarch64-linux-gnu-debug.tar.gz
6a29f3b05a22a6c52468218ad0e62a38743ebe67c7b05754f90016ee1046e330 guix-build-c8d9baae942c/output/aarch64-linux-gnu/bitcoin-c8d9baae942c-aarch64-linux-gnu.tar.gz
9b624000937c03f2e
...

💬 hodlinator commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2109164428)
True, I wasn't clear on vbytes. Seems bytes would still be less fuzzy but hardly worth changing even if you were forced to touch for other reasons.

👍 hebasto approved a pull request: "guix: accomodate migration to codeberg"
(https://github.com/bitcoin/bitcoin/pull/32439#pullrequestreview-2871055732)
My Guix build:
```
aarch64
8e7798bc42e611c15022d90cfb525fdaccb0eda0753f3d9a1f85f5d947bcced1 guix-build-c8d9baae942c/output/aarch64-linux-gnu/SHA256SUMS.part
e7b1f02d7f0a8390f596e4ba857e503041c2b8f51099763f2a94527493456d81 guix-build-c8d9baae942c/output/aarch64-linux-gnu/bitcoin-c8d9baae942c-aarch64-linux-gnu-debug.tar.gz
6a29f3b05a22a6c52468218ad0e62a38743ebe67c7b05754f90016ee1046e330 guix-build-c8d9baae942c/output/aarch64-linux-gnu/bitcoin-c8d9baae942c-aarch64-linux-gnu.tar.gz
9b624000
...

🚀 fanquake merged a pull request: "test: fix and augment block tests of invalid_txs"
(https://github.com/bitcoin/bitcoin/pull/32591)

🤔 rkrux reviewed a pull request: "wallet, rpc: Return normalized descriptor in parent_descs"
(https://github.com/bitcoin/bitcoin/pull/32594#pullrequestreview-2870949997)
ACK a759a22d59e805834d077a28c95695e4834983a9

Agree that normalized descriptors are more useful as no further hardened derivation is required.

Not suggesting any change, only a question: Specific for the `listunspent` RPC though where both `parent_descs` and `desc` fields are present, is `parent_descs` field useful only when the unspent is not solvable? Because `parent_descs` seem like the superset of `desc` from few values I checked and also by its name.

💬 rkrux commented on pull request "wallet, rpc: Return normalized descriptor in parent_descs":
(https://github.com/bitcoin/bitcoin/pull/32594#discussion_r2109239705)
IIUC, this is just a dummy signing provider being passed here and essentially the last hardened xpub would be retrieved from the desc cache because I don't see this provider being populated in the call stack.

https://github.com/bitcoin/bitcoin/blob/f7cc7f6468afeb20b01ee86575c7b6329ed2faf9/src/script/descriptor.cpp#L533-L536

Ideally, passing a null for the provider arg could have been better to emphasise on this but I see the function signature accepts a reference instead.

https://github
...

💬 rkrux commented on pull request "wallet, rpc: Return normalized descriptor in parent_descs":
(https://github.com/bitcoin/bitcoin/pull/32594#discussion_r2109107403)
Nit: Most likely this sentence was reworded midway because it ends abruptly on first line and the content is duplicated on the next.

👍 hebasto approved a pull request: "test: Add missing ipc subtree to lint"
(https://github.com/bitcoin/bitcoin/pull/32623#pullrequestreview-2871162934)
ACK fa2bf6bdb7e5f8940fe4bce1aaab29bf2e063b49.

💬 hebasto commented on pull request "test: Add missing ipc subtree to lint":
(https://github.com/bitcoin/bitcoin/pull/32623#discussion_r2109243775)
Maybe add a reverse reference to this list in `test/lint/test_runner/src/main.rs`?

💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2109251771)
Does it matter though? If it crashes before sync_all we either have all zero in xor.dat or a random key that has not yet been used for xoring anything. On next run it will either rewrite a new key if still zero or start using the previously written random key.

💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2109256380)
`into_inner` flushes before returning. https://doc.rust-lang.org/std/io/struct.BufWriter.html#method.into_inner

🤔 jonatack reviewed a pull request: "blocks: avoid recomputing block header hash in `ReadBlock`"
(https://github.com/bitcoin/bitcoin/pull/32487#pullrequestreview-2871187569)
ACK 09ee8b7f278627b917f0784adf23cbc76cae5fa0

💬 jonatack commented on pull request "blocks: avoid recomputing block header hash in `ReadBlock`":
(https://github.com/bitcoin/bitcoin/pull/32487#discussion_r2109259969)
If you retouch now or in another pull, would be clearer to state which blockhash is expected vs actual.

```suggestion
LogError("GetHash() doesn't match index at %s while reading block (actual %s != expected %s)",
```

✅ andrewtoth closed a pull request: "contrib: add xor-blocks tool to obfuscate blocks directory"
(https://github.com/bitcoin/bitcoin/pull/32451)