👍 tdb3 approved a pull request: "test: Remove redundant verack check"
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2106242208)
ACK fa4f453281e1b38ec4bc87eadbfcfee11d6ea530
Makes sense. Version handshake occurs before ping/pong.

As a sanity check, ran functional tests to see the tests continue to function properly (all passed). Also viewed node traffic between two regtest nodes, and saw ping/pong occur after version/verack exchange.

💬 tdb3 commented on pull request "test: Remove redundant verack check":
(https://github.com/bitcoin/bitcoin/pull/30252#discussion_r1632312842)
nit:
`check it by waiting for a ping`
The code waits for successful pongs rather than pings.

💬 EthanHeilman commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1632314639)
1. If I understand, you don't want to replace `MixExtract` entirely when the deterministic test RNG is used, because want `MixExtract` to still run and add/mix entropy in case someone decides to generate a keying material while the deterministic test RNG is on. This was what I was missing.

2. I like the name deterministic mode because it makes it more clear this is a RNG wide change.

3. Thought I had after waking up this morning was to change this to `bool fail_on_deterministic_mode`. Thus
...

📝 maflcko opened a pull request: "log: use error level for critical log messages"
(https://github.com/bitcoin/bitcoin/pull/30255)
This picks up the first commit from https://github.com/bitcoin/bitcoin/pull/29231, but extends it to also cover cases that were missed in it.

As per https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#logging, LogError should be used for severe problems that require the node to shut down.

💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1632321305)
How about having an `always_use_real_rng` bool instead, with meaning `!allow_deterministic`. That means the "deterministic" terminology would be more clearly referring to the mode (is the deterministic PRNG enabled), but not to the produced numbers.

🤔 tdb3 reviewed a pull request: "refactor: performance-for-range-copy in psbt.h"
(https://github.com/bitcoin/bitcoin/pull/30253#pullrequestreview-2106277965)
Approach ACK.
Less copying makes sense. Briefly searched for other instances in psbt.h where potentially unnecessary copying is done.

Would it also make sense to adjust these references to const (or is there a specific reason why const should not be used here)? Adjusted to `const auto& entry` and ran unit and functional tests (no issues observed).

https://github.com/bitcoin/bitcoin/blob/fab01b5220c28a334b451ed9625bd3914c48e6af/src/psbt.h#L355-L359

https://github.com/bitcoin/bitcoin/blo
...

💬 maflcko commented on pull request "test: Remove redundant verack check":
(https://github.com/bitcoin/bitcoin/pull/30252#discussion_r1632322469)
Thanks, fixed.

👍 tdb3 approved a pull request: "test: Remove redundant verack check"
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2106279027)
ACK fa6627706580ea213fc5df23fe990f1feedec11d

💬 maflcko commented on pull request "refactor: performance-for-range-copy in psbt.h":
(https://github.com/bitcoin/bitcoin/pull/30253#issuecomment-2156654277)
> Less copying makes sense. Briefly searched for other instances in psbt.h where potentially unnecessary copying is done.

The examples you provided are already const references. In C++, when calling a member method that is marked `const`, member access will be const. Moreover, `auto&` is a reference that hides the type, including the const-ness, so `const auto&` and `auto&` should be identical in this context (const references that do not copy), and no further change should be needed.

👍 EthanHeilman approved a pull request: "Several randomness improvements"
(https://github.com/bitcoin/bitcoin/pull/29625#pullrequestreview-2106304644)
ACK 125509f395a214465ebf379164e41e4c6d19d443
I have not tested the code. All my comments have been addressed.

💬 marcofleon commented on pull request "fuzz: add I2P harness":
(https://github.com/bitcoin/bitcoin/pull/30230#issuecomment-2156686118)
> My only note: I think it would be worthwhile to point out in the PR description what changes you have made to the original harness and why they were necessary.

Done. Thanks for all the help @dergoegge.

💬 maflcko commented on pull request "consensus: Store transaction nVersion as uint32_t":
(https://github.com/bitcoin/bitcoin/pull/29325#issuecomment-2156694207)
ACK 429ec1aaaaafab150f11e27fcf132a99b57c4fc7 🐿

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: ACK 429ec1aaaaafab150f11e27fcf
...

💬 theStack commented on pull request "Ephemeral Anchors, take 2":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2156706861)
Is it an option to be more restrictive and only allow zero-value outputs as ephemeral anchors, for not having to deal with the concept of dust at all? Or, asked differently: what would be the motivation/benefit for users to ever create an anchor output with nValue > 0? (Note that I haven't looked too deep into the concept of ephemeral anchors and the predecessor PR #29001, so very likely I'm missing something obvious here, but I guess the answer could be interesting for other potential reviewers
...

👍 theStack approved a pull request: "refactor: performance-for-range-copy in psbt.h"
(https://github.com/bitcoin/bitcoin/pull/30253#pullrequestreview-2106322753)
utACK fab01b5220c28a334b451ed9625bd3914c48e6af

💬 tdb3 commented on pull request "refactor: performance-for-range-copy in psbt.h":
(https://github.com/bitcoin/bitcoin/pull/30253#issuecomment-2156718032)
>no further change should be needed.

Thanks.
ACK fab01b5220c28a334b451ed9625bd3914c48e6af

💬 naiyoma commented on pull request "cli: restrict multiple exclusive argument usage in bitcoin-cli":
(https://github.com/bitcoin/bitcoin/pull/30148#issuecomment-2156762313)
> Rather than checking each one of these options individually, why not have an `OptionsCategory` for them, and iterate over that? That has the advantage that it lists them separately when you invoke `bitcoin-cli -help`,

Thanks for this suggestion, I have applied the patch and pushed an update

📝 l2xl opened a pull request: "Allow to configure custom libzmq prefix"
(https://github.com/bitcoin/bitcoin/pull/30256)
This change allows to to configure bitcoin build with ZeroMQ library
installed at any place standard or CUSTOM.
This is useful if needed to use libzmq of different version from installed by distro.

📝 maflcko opened a pull request: "build: Remove --enable-gprof"
(https://github.com/bitcoin/bitcoin/pull/30257)
It is unclear what benefit this option has, given that:

* `gprof` requires re-compilation (`perf` and other tools can instead be used on existing executables)
* `gprof` requires hardening to be disabled
* `gprof` doesn't work with `clang`
* Anyone really wanting to use it could pass the required flags to `./configure`
* I couldn't find any mention of the use of `gprof` in the discussions in this repo, apart from the initial pull request adding it (cfaac2a60f3ac63ae8deccb03d88bd559449b78c)
...

👍 TheCharlatan approved a pull request: "build: Remove --enable-gprof"
(https://github.com/bitcoin/bitcoin/pull/30257#pullrequestreview-2106371803)
ACK fa780e1c25e8e98253e32d93db65f78a0092433f

🤔 furszy reviewed a pull request: "indexes: Don't wipe indexes again when continuing a prior reindex"
(https://github.com/bitcoin/bitcoin/pull/30132#pullrequestreview-2106239011)
Code review ACK f68cba29b3be0dec7877022b18a193a3b78c1099

Great last commit.

Question about 804f09dfa116300914e2aeef05ed9710dd504e8c commit description:

> Also the previous set of
options did not allow rebuilding the block database without also
rebuilding the chainstate database, when it should be possible to do
those independently.

is this tested anywhere?

💬 furszy commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1632309533)
tiny nit
```suggestion
options.wipe_block_tree_db = m_args.GetBoolArg("-reindex", false);
options.wipe_chainstate_db = options.wipe_block_tree_db || m_args.GetBoolArg("-reindex-chainstate", false);
```

Side note:
I don't think this is used anywhere.