💬 instagibbs commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2420365990)
yep, just noting

💬 maflcko commented on pull request "DRAFT: add a freebsd job using systemlibs":
(https://github.com/bitcoin/bitcoin/pull/33562#issuecomment-3390297190)
Yeah, this would be adding FreeBSD to add coverage for a single short-term compile time issue encountered there. Though, we'd still be missing OpenBSD/NetBSD coverage for stuff that is different on those platforms: https://github.com/bitcoin/bitcoin/issues/33128 (which seems like a long-standing issue that has existed since ever and no one bothered to report?)

👍 stickies-v approved a pull request: "[29.x] Finalise 29.2"
(https://github.com/bitcoin/bitcoin/pull/33551#pullrequestreview-3323741676)
ACK 46d9b9091baa096da30da5e14329a32f1264229a

💬 pinheadmz commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390313025)
@jotapea it may not necessarily "imrpove" configuration but by definition does make it more complicated. What it will certainly do is reduce the quality of transaction relay and compact block propogation -- as explained repeatedly over the past several months in posts like these:

https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697

I encourage you to ask further questions on t
...

💬 Crypt-iQ commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3390328037)
crACK 01cc20f3307c532f402cdf5dc17f2f14920b725b

💬 glozow commented on pull request "[29.x] Finalise 29.2":
(https://github.com/bitcoin/bitcoin/pull/33551#issuecomment-3390328977)
29.2rc2 bins have only been up for 3 days. Planning to merge on ~tuesday assuming no reports.

💬 delta1 commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390394398)
@jotapea no issues understanding anything. It's apparent you used an LLM to write this. You should close this issue.

💬 Aa777263100 commented on issue "Set default datacarriersize to 160 bytes":
(https://github.com/bitcoin/bitcoin/issues/33543#issuecomment-3390416885)
###

💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2420487300)
I just noticed you said "proportional". Indeed, they are, but still off by a factor of up to 2, and 1.5 on average.

💬 jotapea commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390632428)
@delta1 You are partially right, ai was used as assistance to the original post. I can recommend it if you have similar needs, specially if is not your native language... Now, do you have anything concrete about the draft to discuss?

@pinheadmz Thank you for productively engaging. But please allow some discussion before deciding to close the issue.

By definition any additional configuration is adding complexity... ok I could agree. It is an extremely simple one though.

> reduce the quality of
...

📝 maflcko opened a pull request: "refactor: Construct g_verify_flag_names on first use"
(https://github.com/bitcoin/bitcoin/pull/33600)
The current usage of the `g_verify_flag_names` map seems fine and I can not see a static initialization order fiasco here.

However, it seems brittle to hope this remains the case in the future. Also, it triggers a msan false-positive in the fuzz CI task. (C.f https://github.com/bitcoin-core/qa-assets/actions/runs/18352815555/job/52413137315?pr=241#step:7:5245)

So just apply the "Construct on first use" idiom.

💬 delta1 commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390749391)
Go ahead and make your PR for this 👍 let’s see how it’s received

🤔 furszy reviewed a pull request: "rpc: add "ischange: true" to decoded tx outputs in wallet gettransaction response"
(https://github.com/bitcoin/bitcoin/pull/32517#pullrequestreview-3324273918)
utACK f6517df210f5e940d87823c86358976743de2641

left a small comment that would be nice to fix.

💬 furszy commented on pull request "rpc: add "ischange: true" to decoded tx outputs in wallet gettransaction response":
(https://github.com/bitcoin/bitcoin/pull/32517#discussion_r2420826370)
Should be a const ref:
```suggestion
void TxToUniv(const CTransaction& tx, const uint256& block_hash, UniValue& entry, bool include_hex = true, const CTxUndo* txundo = nullptr, TxVerbosity verbosity = TxVerbosity::SHOW_DETAILS, std::function<bool(const CTxOut&)> is_change_func = {});
```

🤔 glozow reviewed a pull request: "[29.x] Finalise 29.2"
(https://github.com/bitcoin/bitcoin/pull/33551#pullrequestreview-3324377596)
ACK 46d9b9091baa096da30da5e14329a32f1264229a

💬 hhhh3113 commented on something "":
(https://github.com/bitcoin/bitcoin/commit/8f55573ed327430609ec2d8f94cbb79ed03e8f64#r167672061)
==Deployments==

List of deployments.

State can be defined, active, failed. Dates are in UTC.

🚀 glozow merged a pull request: "[29.x] Finalise 29.2"
(https://github.com/bitcoin/bitcoin/pull/33551)

💬 kevkevinpal commented on pull request "doc: bump the template macOS version since 14 is now the minimum supported version":
(https://github.com/bitcoin/bitcoin/pull/33573#discussion_r2421007513)
I've updated to use these newer versions in [c80bcfb](https://github.com/bitcoin/bitcoin/pull/33573/commits/c80bcfba084aa316d113730d731f79c3aa472abf)

💬 glozow commented on issue "Minor Release 29.2":
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3390980492)
v29.2 has been tagged

💬 mzumsande commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2421152575)
> Is my understanding correct that pindexLastCommonBlock could be different across peers on the same chain as us (depending on which peers are processed first) or different because our peers may be on different chains from each other?

yes, that's correct. `pindexLastCommonBlock` is also moved forward [here](https://github.com/bitcoin/bitcoin/blob/becf1500131805bd6a47486cd5bc5bdb55839211/src/net_processing.cpp#L1481-L1486) in `FindNextBlocks` if all previous blocks have data, so each peer's `
...