💬 m3dwards commented on pull request "net: Allow -proxy=[::1] on nodes with IPV6 lo only":
(https://github.com/bitcoin/bitcoin/pull/30245#discussion_r1664231914)
`ai_flags` only had `AI_ADDRCONFIG` set so without it it would be 0 anyway right?

💬 m3dwards commented on pull request "net: Allow -proxy=[::1] on nodes with IPV6 lo only":
(https://github.com/bitcoin/bitcoin/pull/30245#discussion_r1664237280)
We still need to check again if we do get the error though so checking the error would be more performant (not always having to call `getaddrinfo` twice) but _more_ code.

💬 maflcko commented on pull request "kernel: De-globalize validation caches":
(https://github.com/bitcoin/bitcoin/pull/30141#issuecomment-2206166257)
DrahtBot is open-source, so pull requests and bug reports are welcome. But I am not sure if the additional code is worth it for the rare case where someone write a comment containing `ACK` after they sent a proper review `ACK commit_hash`. If you care about the summary comment being correct, you can:

* Edit your comments after your review to not contain `ACK`, or
* Resubmit your review

💬 dergoegge commented on pull request "[WIP] p2p: send not_found msgs for unknown, pruned or unwilling to share blocks":
(https://github.com/bitcoin/bitcoin/pull/30385#issuecomment-2206166538)
> Currently, when the remote peer does not have the requested block data, it ignores the 'getdata' inventory block request. This lack of response causes the requesting node to wait (and stall if the request was for an IBD block) for 10 minutes until the request timeout is triggered.

Nodes advertise which blocks they have and what their current tip is, so the timeouts should only happen if the peer is misbehaving or if you disrespect the protocol by asking for things they don't have. Disconnec
...

👍 maflcko approved a pull request: "Several randomness improvements"
(https://github.com/bitcoin/bitcoin/pull/29625#pullrequestreview-2156620993)
re-ACK ce8094246ee95232e9d84f7e37f3c0a43ef587ce 🐈

<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: re-ACK ce8094246ee95232e9d8
...

💬 maflcko commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1664293289)
nit: (haven't tried), but in a follow-up this could use `m_rng`, because the lock is already taken IIRC.

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1664298064)
added

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1664298204)
done, thanks

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1664301048)
I suppose it's not super accurate to say that `UpdatedBlockTipSync` is the synchronous version of `UpdatedBlockTip`, as the point here is to fire whenever the chain tip changes at all, while `UpdatedBlockTip` skips some things. i.e. `InvalidateBlock` when our new tip is a step back instead of an advancement.

I've removed comments comparing it to `UpdatedBlockTip`, slightly changed the calling logic, and renamed it to `ActiveTipChange`.

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1664301296)
gating on whether ibd now

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#issuecomment-2206343668)
> Changes like this are inherently difficult to review

Yes, needs careful code review. The intermediate `Assume` in 4673e04cb3 may help as a sanity check. Lmk if anybody has ideas to structure the PR in a clearer way.

👍 theStack approved a pull request: "26.2 final changes"
(https://github.com/bitcoin/bitcoin/pull/30376#pullrequestreview-2156652690)
ACK eef5dbc21b3fd52069f2f0855fb76a13234ebbf3

💬 furszy commented on pull request "[WIP] p2p: send not_found msgs for unknown, pruned or unwilling to share blocks":
(https://github.com/bitcoin/bitcoin/pull/30385#issuecomment-2206361109)
> Nodes advertise which blocks they have and what their current tip is, so the timeouts should only happen if the peer is misbehaving or if you disrespect the protocol by asking for things they don't have.

We don't ask all peers about all the blocks they know about. If the node is it in the main-chain, most of the time we only know their last advertised header only.
Once we are headers-wise sync, the block downloading procedure download blocks from different peers. It has a window of 16 in-f
...

💬 sipa commented on pull request "[WIP] p2p: send not_found msgs for unknown, pruned or unwilling to share blocks":
(https://github.com/bitcoin/bitcoin/pull/30385#issuecomment-2206384707)
> The peer who advertised the header might not be the one who ends up providing the final block.

I don't think we ever ask for a block from a peer without that specific peer having announced the block or a descendant to us?

I can imagine asking a peer for a block that is not on the main chain (due to a very recent reorg) or due to just being pruned, though I don't know how often this happens.

I think this is generally a good change, but to judge how important it is, I think it's good to
...

👍 maflcko approved a pull request: "fuzz: improve utxo_snapshot target"
(https://github.com/bitcoin/bitcoin/pull/30329#pullrequestreview-2156663091)
lgtm. Thanks!

💬 maflcko commented on pull request "fuzz: improve utxo_snapshot target":
(https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1664319501)
style nit: Missing trailing `,`?

💬 maflcko commented on pull request "fuzz: improve utxo_snapshot target":
(https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1664318951)
nit: maybe also list the filename here, like in the other cases.

💬 maflcko commented on pull request "fuzz: improve utxo_snapshot target":
(https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1664333808)
nit: Could assert the chain tx value from the chain params constant?

💬 maflcko commented on pull request "fuzz: improve utxo_snapshot target":
(https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1664325174)
style-nit:
```suggestion
auto msg_start = chainman.Params().MessageStart();
```

💬 maflcko commented on pull request "fuzz: improve utxo_snapshot target":
(https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1664344893)
Should be fine to exceed the range here for fuzzing? Maybe `+1`, or `*3` instead of `*2`?