💬 hebasto commented on issue "cmake: (release) version handling is broken":
(https://github.com/bitcoin/bitcoin/issues/31898#issuecomment-2666549006)
@fanquake

Could you demonstrate how a release source tarball becomes broken when _all_ steps in the release process have been followed?

💬 TheCharlatan commented on pull request "cmake: Set top-level target output locations":
(https://github.com/bitcoin/bitcoin/pull/31161#discussion_r1960273581)
Nit: These headers in the comments seem a bit inconsistent at the moment. What makes the secp subtree special enough to get its own header? Where do these sections end? Why don't the other components get their own headers?

👍 TheCharlatan approved a pull request: "cmake: Set top-level target output locations"
(https://github.com/bitcoin/bitcoin/pull/31161#pullrequestreview-2624512587)
ACK f7d8a44ce42cce0b3010a7f7d14ec180e959f3e4

💬 hodlinator commented on pull request "doc: Improve `dependencies.md`":
(https://github.com/bitcoin/bitcoin/pull/31895#discussion_r1960318327)
```
₿ touch A
₿ touch a
₿ ls [Aa]
a A
```
Doesn't match GNU `ls` order.. but it does match ASCII order. :+1:

💬 maflcko commented on issue "cmake: (release) version handling is broken":
(https://github.com/bitcoin/bitcoin/issues/31898#issuecomment-2666613449)
For reference, I reviewed and tested this specifically for the cmake switch last year and I concluded that everything has been ported accurately. So I don't think there is a regression or a release-blocker.

In any case, it would be good to include full steps to reproduce here, starting from a fresh clone, because IIRC in some edge cases, the parent directory structure may influence the result if it is a git dir. The edge-cases aren't well documented, sometimes only mentioned in the release note
...

💬 GregTonoski commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2666626452)
> just saw you included logs. It's just very slow, so clearly no deadlock or livelock

I would suggest investigating the number of "generated table ..." logs. There shouldn't be so many of them especially in comparison to a correct execution.

💬 ismaelsadeeq commented on pull request "mining: drop unused -nFees and sigops from CBlockTemplate":
(https://github.com/bitcoin/bitcoin/pull/31897#issuecomment-2666698825)
ACK d1cc874d1f87a654aa2da50dbcf850b84517e938

> I think it's more intuitive for block.vtx and these two vectors to have the same length.

No strong opinion but I tend to prefer @ryanofsky diff because it is precise. Since the coinbase transaction does not have fees, we should not simply add 0 for the size of `vTxFees` to match `vtx` .

They are two different list with different meaning
`vtx` is the list of transactions in the block, while `vTxFees` is the list of fees for each transactio
...

💬 maflcko commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2666700079)
How fast is the hardware? What is the speed for contiguous reads/writes that do not go through the filesystem cache? What is the speed for random read/writes that also do not go through the filesystem cache?

💬 achow101 commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2666737879)
I've notarized the arm64 binaries, does running the downloaded the binaries still result in an error?

💬 GregTonoski commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2666758852)
> How fast is the hardware? What is the speed for contiguous reads/writes that do not go through the filesystem cache? What is the speed for random read/writes that also do not go through the filesystem cache?

Tell me what they are expected to be normally and I will measure the actual values, please.

📝 tnull opened a pull request: "Fix delimeter in `package-msg` field of `submitpackage` RPC"
(https://github.com/bitcoin/bitcoin/pull/31900)
Previously, the `submitpackage` RPC call returned a response key named `package_msg`, which is inconsistent with the other field names that are using `-` as a delimiter. Here, we align the style of `package-msg`.

cc @glozow @instagibbs

🤔 zaidmstrr reviewed a pull request: "Feature: Use different datadirs for different signets"
(https://github.com/bitcoin/bitcoin/pull/29838#pullrequestreview-2624854068)
Concept ACK
A very much-needed feature when you're working with different signet chains.

💬 jonatack commented on pull request "doc: clarify loadwallet path loading for wallets":
(https://github.com/bitcoin/bitcoin/pull/30302#discussion_r1960490229)
I think so, best avoid needing to (remember to) retouch those.

🤔 glozow reviewed a pull request: "Fix delimeter in `package-msg` field of `submitpackage` RPC"
(https://github.com/bitcoin/bitcoin/pull/31900#pullrequestreview-2624878185)
lgtm, though I've heard we don't like hyphens, so perhaps go in the other direction and change all the other ones to `_`?

💬 sipa commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1960516927)
Both options are O(n log n), but a vector + sorting + deduplication has much better constant factors.

In theory, using an `std::unordered_map` could asymptotically faster for large numbers, but I suspect not for the numbers we care about. I haven't tried or benchmarked it, though.

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1960520612)
Agreed, I calculated recently.
This is better.

The constant factors for GetDistinctClusters implementation using vector and then sorting is also better 👍🏾
Please resolve.

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1960020302)
It can be called when oversized but for staging `DoWork` it will be no-op when it is oversized.

💬 philmb3487 commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#issuecomment-2666829924)
@sipa Thanks for bringing this up. Apple moved the exFat filesystem to userspace and it had nasty side effects. What a terrible idea, what is Apple even thinking?
To be sure, have other drivers been moved to user-space?
For all we know they might also be broken. It needs to be checked, it seems doubtful they would only move one driver over.

On Tue, Feb 18, 2025 at 21:00, l0rinc ***@***.***(mailto:On Tue, Feb 18, 2025 at 21:00, l0rinc <<a href=)> wrote:

> @l0rinc commented on this pull request.
...

💬 tnull commented on pull request "Fix delimeter in `package-msg` field of `submitpackage` RPC":
(https://github.com/bitcoin/bitcoin/pull/31900#issuecomment-2666838815)
> lgtm, though I've heard we don't like hyphens, so perhaps go in the other direction and change all the other ones to `_`?

Hmm, sure, happy to change if that would be preferable, mostly went this way as I saw other examples using `-` (e.g., `p2sh-segwit` in `decodescript` result, `bit125-replaceable` in the wallet RPCs, etc), but I now realize there are also many (more?) that use `_`. This makes me wonder if we are really positive it's worth breaking the current API, if neither of the option
...

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r1960532733)
thanks, removed `DEFAULT_MAX_ORPHAN_TRANSACTIONS`