📝 solveforceapp opened a pull request: "~"
(https://github.com/bitcoin/bitcoin/pull/32807)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

✅ fanquake closed a pull request: "~"
(https://github.com/bitcoin/bitcoin/pull/32807)

💬 kevkevinpal commented on pull request "test: added fuzz coverage for consensus/merkle.cpp":
(https://github.com/bitcoin/bitcoin/pull/32243#issuecomment-3001984288)
> Missing line in unit and functional tests coverage.

A good follow-up could be to add coverage to this line in the functional tests

🤔 pablomartin4btc reviewed a pull request: "cli: rework -addrinfo cli to use addresses which aren’t filtered for quality/recency"
(https://github.com/bitcoin/bitcoin/pull/26988#pullrequestreview-2955473819)
tACK c2f3225622cbbe516ac23059bff47ed3c28653cf

> my personal preference is for displaying only the relevant total addresses stats

I also lean toward showing only the total known addresses, as I think it better reflects what the node has in its addrman and avoids suggesting that only the filtered set "counts."
I'd consider whether passing an argument might offer one or both views (filtered/unfiltered) depending on the use case, but I’ve read the previous discussions here and in #27511, and
...

💬 stickies-v commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2164992810)
I agree `NeedsRateLimiting` has too many responsibilities. I think it's okay as-is, but your comment nerdsniped me into revisiting this. I'm working on a branch that removes the side effects from `NeedsRateLimiting` and a couple of other improvements. I'm not sure yet if it'll be too much of a detour for this PR, but at least it'll be interesting to be able to compare. Should have it ready tomorrow.

💬 fjahr commented on pull request "rpc: use CScheduler for HTTPRPCTimer":
(https://github.com/bitcoin/bitcoin/pull/32796#discussion_r2164987582)
Did you consider avoiding the dependency to node context and just give the Inteface it's own `CScheduler` instead?

💬 fjahr commented on pull request "rpc: use CScheduler for HTTPRPCTimer":
(https://github.com/bitcoin/bitcoin/pull/32796#discussion_r2164975420)
nit: new blank line seems unnecessary

🤔 fjahr reviewed a pull request: "rpc: use CScheduler for HTTPRPCTimer"
(https://github.com/bitcoin/bitcoin/pull/32796#pullrequestreview-2955445625)
Concept ACK

💬 fjahr commented on pull request "rpc: use CScheduler for HTTPRPCTimer":
(https://github.com/bitcoin/bitcoin/pull/32796#discussion_r2164968472)
Seems weird to mention libevent here as a point of reference since it's in the past after this change is applied. I would put this in the commit message and just say that it's not accurate enough here.

🤔 w0xlt reviewed a pull request: "descriptors: Allow `H` as a hardened indicator"
(https://github.com/bitcoin/bitcoin/pull/32788#pullrequestreview-2955511313)
ACK https://github.com/bitcoin/bitcoin/pull/32788/commits/b6252655fe502ed1bbb97ab9597d9bbcf8c4484c

🤔 w0xlt reviewed a pull request: "descriptors: MuSig2"
(https://github.com/bitcoin/bitcoin/pull/31244#pullrequestreview-2955519593)
reACK https://github.com/bitcoin/bitcoin/pull/31244/commits/5fe7915c865a8e7c0a95ec376d0f1ff737f5d1c2

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3002071721)
> Does it ever make sense to have multiple announcements for the same wtxid to be m_reconsider? I'm wondering if AddChildrenToWorkSet should skip wtxids for which a reconsider-announcement already exists.

Indeed, we don't need to reconsider the same transaction more than once if nothing's changed. I'm wondering how bad it is for `AddChildrenToWorkSet` to iterate through all of them every time - it might be slightly more efficient to allow multiple `m_reconsider`s and reset all to false in `Ge
...

💬 fjahr commented on pull request "Embed default ASMap as binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2165074707)
I am addressing this in https://github.com/asmap/asmap-data/pull/26

💬 Crypt-iQ commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-3002106439)
> > The relevant code is in UDPRelayBlock
>
> `UDPRelayBlock` is relevant only for FIBRE to FIBRE connections, and these also have [bespoke](https://github.com/w0xlt/bitcoinfibre/blob/45897a826b37eb417cba93ac17ff7bebb272893c/src/udprelay.cpp#L495) logic for receiving FIBRE block announcements. The way that FIBRE nodes announce to "default" nodes is the same as the way that "default" nodes announce to each other. [Below](https://github.com/w0xlt/bitcoinfibre/blob/45897a826b37eb417cba93ac17ff7beb
...

💬 Crypt-iQ commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3002134730)
> The fact that you're enabling FIBRE on a connection can just be taken as implicitly soliciting compact blocks on that connection, so I don't think this is a problem.

Right, my earlier comment was wrong.

I think that dropping unsolicited cmpctblock in the non -blocksonly case is kind of ineffective as pointed out by others. But I also don't have a strong opinion about it given that it doesn't affect FIBRE.

💬 Crypt-iQ commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2165122471)
> One could special-case it to account for allowing empty block reconstruction on blocks-only nodes but it feels like dead weight in the code.

Yeah, I feel like the complexity isn't worth it.

💬 luke-jr commented on pull request "Refactor: Redefine CTransaction equality to include witness data":
(https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-3002139031)
Seems like it might be best to forbid operator== entirely and require comparisons to be explicit about whether witness data is compared or not.

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3002183417)
I adapted the bench for any announcement limit, and changed the ManyPeers scenario https://github.com/glozow/bitcoin/commits/2025-06-bench-31829/

Ultimately, regardless of the number of peers you have, the most you can exceed the usage limit with 1 transaction is ~400K, so the max number of transactions you can evict is 400K/240 (240wu being the smallest transaction size). We can increase this with more heap operations by making sure each peer is neck and neck for "DoSiest" at each iteration.
...

💬 truongsonplus3 commented on issue "IPC via TCP Sockets":
(https://github.com/bitcoin/bitcoin/issues/32802#issuecomment-3002318845)
tương tự

💬 davidgumberg commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165233501)
nit: the argument name should probably be `m_feerate_kvb`