💬 purpleKarrot commented on pull request "cmake: Use builtin support for .manifest files":
(https://github.com/bitcoin/bitcoin/pull/33585#issuecomment-3389932816)
> What is the logic behind merging `${target}.manifest` with a linker-generated manifest?

The logic is internal to the MSVC linker. See: https://learn.microsoft.com/en-us/cpp/build/reference/manifestinput-specify-manifest-input

> 2. I'm not entirely sure that any fix of https://gitlab.kitware.com/cmake/cmake/-/issues/23244 will follow the same logic for MinGW as for MSVC.

We can never be entirely sure. But we can expect that different outcomes for MinGW as for MSVC should not be conside
...

💬 Crypt-iQ commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2420169460)
> I'm not sure what scenario you have in mind - a fork in which our active chain reorged away from the peer's best chain? This seems hypothetical enough that performance is probably not too important.

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? I was just thinking out loud about the second case, where per
...

👍 instagibbs approved a pull request: "cluster mempool: control/optimize TxGraph memory usage"
(https://github.com/bitcoin/bitcoin/pull/33157#pullrequestreview-3323336944)
reACK 7421e58dee402ee8b5b58a18684953a89ad350d7

`git range-diff master 5ac32aa441bf3ec1f1fa826f689405bc4a7b7354 7421e58dee402ee8b5b58a18684953a89ad350d7`

💬 instagibbs commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2420073068)
de8ebdd795e35644435c7b68b2c2bc5f54ea9d7c

Not immediately clear this is necessary. These are all freshly generated, and shouldn't have holes, and capacities should be proportional?

💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2420320280)
No holes, indeed. But the capacities may be higher than needed, because transactions have been added one by one through `vector::push_back` in `m_mapping`, `m_linearization`, and `m_depgraph.entries`. When vector addition causes capacity to be exceeded, most C++ stdlibs use some exponential growing (e.g. doubling the capacity every time).

💬 jotapea commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390264891)
@delta1 Let me help clarify anything you might need help understanding. Ai slop is generally useless. This is the opposite, a concise and straightforward upgrade to improve OP_RETURN relay policy configuration.

🤔 luke-jr requested changes to a pull request: "Add coins (UTXOs) tab and makes it view-only"
(https://github.com/bitcoin-core/gui/pull/898#pullrequestreview-3323706446)
Should probably only be available if advanced coin control is enabled in settings, and maybe only on a menu even then (if it made sense to do it as a tab, it should be within the main window, not a new window).

The SVG source for the new icon should also be included.

💬 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.