💬 hebasto commented on pull request "ci: remove 3rd party js from windows dll gha job":
(https://github.com/bitcoin/bitcoin/pull/32513#issuecomment-3321471464)
On the [master](https://github.com/bitcoin/bitcoin/actions/runs/17921155333/job/50956194860) branch:
```
VSCMD_ARG_HOST_ARCH: x64
VSCMD_ARG_TGT_ARCH: x64
```

However, with this [PR](https://github.com/bitcoin/bitcoin/actions/runs/17807365691/job/50622408408):
```
VSCMD_ARG_HOST_ARCH: x86
VSCMD_ARG_TGT_ARCH: x86
```

📝 fanquake opened a pull request: "ci: add Valgrind fuzz"
(https://github.com/bitcoin/bitcoin/pull/33461)
Valgrind fuzz runtime?

💬 glozow commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321521194)
> This specific PR seeks clarity in the datacarrier options' future availability

+1. I think the comments so far are largely on topic, but let's try to avoid rehashing the motivations around the policy change itself or re-litigating what the default value should be. Reminder that delving bitcoin, mailing list posts, and a meta topic on the bitcoin-core discussions page exist. Thanks!

💬 polespinasa commented on issue "cli:passing non-integers to datacarriersize":
(https://github.com/bitcoin/bitcoin/issues/33460#issuecomment-3321528433)
There's no need to rever https://github.com/bitcoin/bitcoin/commit/63091b79e70b8e230a122fa6fb3dac91c80638e7
Checking how we handle args, I saw that many numeric args accept strings without crashing.
See `-limitancestorcount` or `-bytespersigop` for example.

`-dustrelayfee` on the ther side does have type handling:
`Error: Invalid amount for -dustrelayfee=<amount>: 'aaa'`

Maybe this is a issue worth checking to add assertions on args types.

🤔 glozow reviewed a pull request: "rpc: Always return per-wtxid entries in submitpackage tx-results"
(https://github.com/bitcoin/bitcoin/pull/33427#pullrequestreview-3255249545)
ACK cad9a7fd7370f6df38370569f9d2de6ac6b7137a

💬 glozow commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2370347016)
Fwiw not a huge deal but I wouldn't recommend doing an unnecessary refactor at the same time as a fix to the missing RPC result.

Looks like this is creating a copy of the string to avoid 2 calls to `GetHex()`, which seems sensible.

💬 chrisguida commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321570824)
NACK

This is too little, too late.

It does not matter whether this option is deprecated or not. With the merging of #32406, core has already signaled that it is absolutely unwilling to address data spam, ever, and is now accelerating towards spam maximization.

Since **our hostility** to spam _is_ the main deterrent against spam (see: why Vitalik stopped trying to build Ethereum on bitcoin: ["I did not want to build on a base protocol whose dev team would be at war with me"](https://x.co
...

💬 l0rinc commented on pull request "[30.0] Final changes + rc2":
(https://github.com/bitcoin/bitcoin/pull/33424#issuecomment-3321628724)
crACK 2db6dde838c820249178593a8d35e436ed838b82

thank you for cherry picking these over

💬 parabitdev commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321715193)
Removal of `and are expected to be removed in a future version` for technical accuracy is an admirable objective. A complete removal of deprecation is a bit hasty unless someone plans to resolve the behavior changes this flag exhibits with regards to things like multiple op_returns in a single transaction.

I only support this change if someone plans to champion that work, otherwise this feature is deprecated in the truest sense and failing to mark it as such would be irresponsible.

Code is
...

💬 RandyMcMillan commented on issue "cli:passing non-integers to datacarriersize":
(https://github.com/bitcoin/bitcoin/issues/33460#issuecomment-3321760175)
@polespinasa - thanks for looking.

💬 RandyMcMillan commented on issue "cli:passing non-integers to datacarriersize":
(https://github.com/bitcoin/bitcoin/issues/33460#issuecomment-3321779375)
I will let a mod rename and categorize the issue.

💬 mzumsande commented on pull request "wallet: reduce unconditional logging during load":
(https://github.com/bitcoin/bitcoin/pull/33299#issuecomment-3321875750)
After talking to @furszy I'll push a slightly different approach, will put it in draft until then.

📝 mzumsande converted_to_draft a pull request: "wallet: reduce unconditional logging during load"
(https://github.com/bitcoin/bitcoin/pull/33299)
Currently the unconditional log during init with a default wallet happens three times:
```
2025-09-03T19:57:16Z init message: Verifying wallet(s)…
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
(...)
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z init
...

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2370693304)
The line it is commenting is always required, including in normal operation when a `musig()` is present, and when a `musig()` is now known but the keys are. The comment is there to inform future readers wondering why the secnonces are unconditionally added.

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2370723203)
It must still have the correct parity bit. While it is the key must be found in the script, the script is not where the key is sourced from.

💬 l0rinc commented on pull request "log: always print initial script verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2370760229)
That's what I had before, but this was specifically requested: https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2362231753
It's not a very big difference in my opinion, I don't mind either.

📝 benthecarman opened a pull request: "qt: Fix dark mode detection on Linux"
(https://github.com/bitcoin-core/gui/pull/895)
Enable GTK3 platform theme integration on Linux to properly detect
system dark/light mode settings. Without this, Qt applications on
Linux don't automatically adapt to the system theme, unlike macOS
where it works out of the box.

The fix sets QT_QPA_PLATFORMTHEME to "gtk3" before QApplication
initialization, but only if the user hasn't already set a platform
theme. This respects existing user configurations while providing
better defaults for desktop environments using G
...

🤔 w0xlt reviewed a pull request: "log: always print initial script verification state"
(https://github.com/bitcoin/bitcoin/pull/33336#pullrequestreview-3255852704)
reACK https://github.com/bitcoin/bitcoin/pull/33336/commits/010cf81407c0df8de766fd2a116463d180f25f33

💬 ariard commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3322176062)
Concept ACK.

To give a single data point, it took 3.5 years to go from an initial proposal about
`-mempoolfullrbf` during the release cycle of [v22.0](https://gnusha.org/pi/bitcoindev/CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com/) to a release completely deprecating
the ability for a full node operator to police its processed transactions with the opt-in
RBF policy (v[29.0](https://github.com/bitcoin/bitcoin/pull/30592)). If there is no consensus, it's wiser to take t
...

🤔 pablomartin4btc reviewed a pull request: "doc: remove unrelated `bitcoin-wallet` binary from `libbitcoin_ipc` description"
(https://github.com/bitcoin/bitcoin/pull/33459#pullrequestreview-3255954505)
ACK fbde8d9a81d82e53933fe45e36d3a70206a48e0e

I agree that the tool is unrelated to IPC/ multiprocess, so removing it from the list of binaries that use libbitcoin_ipc is appropriate. As an offline wallet utility, it doesn’t provide full “management” like a running wallet RPC (no sending, no RPC-based operations); its capabilities are basically limited to creating wallets, showing wallet details, and importing/exporting wallet data.