💬 0xmatt11 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2854263883)
Removing the OP_RETURN limit is a sensible step. The 83-byte cap no longer serves its original purpose and only encourages inefficient workarounds. Larger, provably unspendable outputs don’t burden the UTXO set and open the door for legitimate use cases like sidechains and timestamping. Bitcoin should enable innovation, not restrict it arbitrarily.

💬 laanwj commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075287790)
i intentionally kept this as-is (eg converting to use `Split` slightly changes semantics), but thinking of it, calling `user_pass.find(':')`three times in a row is maybe a bit much.

💬 maflcko commented on issue "wallet: Data race in GetOrCreateLegacyScriptPubKeyMan vs IsMine":
(https://github.com/bitcoin/bitcoin/issues/27354#issuecomment-2854265066)
For reference, BDB removal https://github.com/bitcoin/bitcoin/pull/31250 was merged (for 30.0)

However, this issue may still exist, as `m_spk_managers` still exists.

💬 l0rinc commented on pull request "validation: periodically flush dbcache during reindex-chainstate":
(https://github.com/bitcoin/bitcoin/pull/32414#issuecomment-2854283411)
Finished measuring `reindex-chainstate` performance for max dbcache (best case scenario), where this PR shines most (i.e. to avoid the worst-case scenario of doing everything in-memory and crashing at the end without anything saved).

Measured it on an HDD with i7 processor, so disk writes are expensive here - would likely be better on SSD.
Unfortunately this change results in a 11% slowdown for scenarios that were hoarding memory, since it has to flush intermediary results regularly, so the
...

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075306983)
still fumbling this. In `mempool_datacarrier.py` I'm not explicitly stopping or restarting the nodes but allowing test teardown to do it. Should I just be stopping the node myself with the optional arg?

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075314466)
Documentation for this is in `src/kernel/mempool_options.h`, it can be further spelled out in policy.h for `IsStandardTx` if that helps?

👍 ismaelsadeeq approved a pull request: "fees: document non-monotonic estimation edge case"
(https://github.com/bitcoin/bitcoin/pull/31080#pullrequestreview-2818014449)
Code review ACK 1e0de7a6ba926487c8a075856b74af2a3a0eb8ef

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075329397)
done

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075329807)
done

💬 Sjors commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#issuecomment-2854351055)
Hah, I was planning on doing this undeprecating this morning, but couldn't find the deprecation message, so I figured someone already did it.

Concept ACK

💬 ryanofsky commented on issue "Intermittent issue in test/ipc_tests.cpp Fatal glibc error: pthread_mutex_lock.c:450 (__pthread_mutex_lock_full): assertion failed: e != ESRCH || !robust":
(https://github.com/bitcoin/bitcoin/issues/29889#issuecomment-2854354693)
This seems a lot like issue https://github.com/bitcoin-core/libmultiprocess/issues/154 which was fixed by https://github.com/bitcoin-core/libmultiprocess/pull/159

✅ Sjors closed an issue: "Make -stopatheight work with background sync"
(https://github.com/bitcoin/bitcoin/issues/28809)

💬 Sjors commented on issue "Make -stopatheight work with background sync":
(https://github.com/bitcoin/bitcoin/issues/28809#issuecomment-2854361655)
I stopped caring about this :-)

💬 adamandrews1 commented on pull request "fees: document non-monotonic estimation edge case":
(https://github.com/bitcoin/bitcoin/pull/31080#issuecomment-2854362619)
Code review ACK 1e0de7a

✅ Sjors closed an issue: "depends: llvm-ranlib (etc): "No such file or directory" on Intel macOS 15.0"
(https://github.com/bitcoin/bitcoin/issues/30978)

💬 Sjors commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854374755)
No longer an issue since #30997.

✅ Sjors closed an issue: "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7"
(https://github.com/bitcoin/bitcoin/issues/31009)

⚠️ fanquake reopened an issue: "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7"
(https://github.com/bitcoin/bitcoin/issues/31009)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Building bitcoin-qt produces a flood of errors:

```
In file included from /Users/sjors/dev/bitcoin/src/qt/csvmodelwriter.cpp:5:
In file included from /Users/sjors/dev/bitcoin/src/qt/csvmodelwriter.h:8:
In file included from /usr/local/opt/qt@5/lib/QtCore.framework/Headers/QList:1:
In file included from /usr/local/opt/qt@5/lib/QtCore.framework/Headers/qlist.h:48:
/usr/local/include/
...

💬 fanquake commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854377650)
It is still an issue, in the 29.x branch.

💬 Sjors commented on issue "ARM Windows build and release":
(https://github.com/bitcoin/bitcoin/issues/31388#issuecomment-2854384464)
We're at qt6 since #30997 landed. But it still needs to be natively compiled. I don't know if cross-compilation is a priority for QT? If not, then there's probably no point in keeping this open until the end of time.