🤔 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`

💬 davidgumberg commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165221968)
can drop this since the `std::ceil` call is dropped.

💬 davidgumberg commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165236159)
The reason that the fuzz tests fail before changing this to `uint32_t` (e.g. this commit: https://github.com/davidgumberg/bitcoin/commit/01a4557b10b31e620716cff04c554e6f1a95653a) is because `CFeeRate::GetFee` takes an unsigned int, but then passes it to `EvaluateFeeUp()` which implicitly converts `at_size` to a signed value, and large examples of `uint32_t` values become negative integers, this results in `EvaluateFee()` getting passed a negative number and asserting.

Wouldn't it be better
...

💬 jsarenik commented on issue "getdescriptorinfo returns unusable descriptor":
(https://github.com/bitcoin/bitcoin/issues/29320#issuecomment-3003152393)
Yes. It works also on v29.0.0 (Termux arm64 build). Thanks!

Closing.

✅ jsarenik closed an issue: "getdescriptorinfo returns unusable descriptor"
(https://github.com/bitcoin/bitcoin/issues/29320)

💬 polespinasa commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165819775)
done

💬 polespinasa commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165819887)
done

💬 polespinasa commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#issuecomment-3003478781)
db63d5bf81895d78d39fe8cf94ded6f63d81d614 removes an unused include and some nit on arg names.
990010f49ca97479f9fe46e288ed0f0fbb0fde94 modifies the code to use uint instead of ints see https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165236159 for context

💬 polespinasa commented on pull request "refactor: CFeeRate encapsulates FeeFrac internally":
(https://github.com/bitcoin/bitcoin/pull/32750#discussion_r2165877940)
That would make sense. Implemented on a separated commit 990010f49ca97479f9fe46e288ed0f0fbb0fde94 (will clean and squash later).

@sipa, I would like to know your opinion on this. Is there any reason you used int32 for `EvaluateFee` in the first place? The two `Assume` at the beginning of the function cut the function to only positive numbers.

🤔 ismaelsadeeq reviewed a pull request: "util: detect and warn when using exFAT on MacOS"
(https://github.com/bitcoin/bitcoin/pull/31453#pullrequestreview-2956792851)
Code review and tested ACK 2ad18fc9784e6a37e453bf844ba10c4e46f54754

bitcoind
```
2025-06-25T06:12:15Z [warning] The following paths are on exFAT which is known to have intermittent corruption problems on MacOS: data directory ("/Volumes/StoreJet/bitcoin_temp"). Move these directories to a non-exFAT formatted drive to avoid corruption.
```

gui
<img width="577" alt="Screenshot 2025-06-25 at 07 29 37" src="https://github.com/user-attachments/assets/1e1340e6-9e3e-4aed-beb6-8ab5a5eed678" /
...