💬 owenkemeys commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840348273)
Concept ACK - but go further and clean this up once and for all.
We may not want data, but many do, and are happy to work around frictions including creating tooling to automate that.
Similarly, the fullrbf saga demonstrated that a minority of more permissive nodes is enough to undermine all filtering.

I entirely sympathise with the desire of many to minimise arbitrary data - I even agree. Bitcoin is not for that.
But the mechanics and economics of the situation dictate that as soon as any
...

💬 joecool1029 commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2840353696)
@hebasto I can confirm the above resolves the issue. (I am the Gentoo bug reporter on this)

🚀 achow101 merged a pull request: "net: Use GetAdaptersAddresses to get local addresses on Windows"
(https://github.com/bitcoin/bitcoin/pull/31014)

🤔 polespinasa reviewed a pull request: "policy: allow more than one OP_RETURN outputs per tx"
(https://github.com/bitcoin/bitcoin/pull/32381#pullrequestreview-2805192347)
uACK

Code lgtm, just a small question on the test code.

💬 polespinasa commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#discussion_r2067499756)
Why is this needed?

💬 achow101 commented on pull request "test: avoid stack overflow in `FindChallenges` via manual iteration":
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2840371986)
ACK 7e8ef959d0637ca5543ed33d3919937e0d053e70

✅ achow101 closed an issue: "ctest -C Debug fails on vs2022 (miniscript_tests (SEGFAULT))"
(https://github.com/bitcoin/bitcoin/issues/32341)

🚀 achow101 merged a pull request: "test: avoid stack overflow in `FindChallenges` via manual iteration"
(https://github.com/bitcoin/bitcoin/pull/32351)

💬 jonatack commented on pull request "miner: timelock the coinbase to the mined block's height":
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2840381768)
> I'm a bit reluctant to have this merged while BIP54 is in limbo (https://github.com/bitcoin/bips/pull/1800).

BIP54 draft merged.

💬 jonatack commented on pull request "net: remove unnecessary check from AlreadyConnectedToAddress()":
(https://github.com/bitcoin/bitcoin/pull/32338#issuecomment-2840389809)
Post-merge ACK

🤔 jonatack reviewed a pull request: "test: avoid stack overflow in `FindChallenges` via manual iteration"
(https://github.com/bitcoin/bitcoin/pull/32351#pullrequestreview-2805226308)
Post-merge ACK

💬 achow101 commented on pull request "Bugfix: Miner: Don't reuse block_reserved_weight for "block is full enough to give up" weight delta":
(https://github.com/bitcoin/bitcoin/pull/32355#issuecomment-2840393223)
ACK 524f981bb87319fdd6ff2ab4a932c4b4e31a7398

🚀 achow101 merged a pull request: "Bugfix: Miner: Don't reuse block_reserved_weight for "block is full enough to give up" weight delta"
(https://github.com/bitcoin/bitcoin/pull/32355)

💬 jackedproxy commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840431414)
NACK
Core holds 90%+ of node running software. It's the go-to, and as such has a responsibility of keeping to sound defaults.
Merging such a change with the amount of controversy it's generating on this thread (and elsewhere) is, at best, irresponsible.

💬 thesamesam commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2840446554)
> This approach appears suitable for Gentoo's Qt packages as well [...]

Yes, this is the conclusion I reached as well. The original Qt commit adding the improved version didn't have it optional, and I saw it referenced in headers which made me think the feature detection had enabled it -- but it only detected it, didn't enable it unless passed explicitly, as a followup Qt commit (a while later) disabled it until newer Binutils is widely adopted, I think.

Anyway, you're absolutely right, and it
...

💬 achow101 commented on pull request "wallet: refactor: various master key encryption cleanups":
(https://github.com/bitcoin/bitcoin/pull/31398#issuecomment-2840450528)
ACK a8333fc9ff9adaa97a1f9024f5783cc071777150

🚀 achow101 merged a pull request: "wallet: refactor: various master key encryption cleanups"
(https://github.com/bitcoin/bitcoin/pull/31398)

📝 w0xlt reopened a pull request: "Make `cs_db` mutex non-recursive"
(https://github.com/bitcoin/bitcoin/pull/32382)
Make `cs_db` mutex non-recursive (related to https://github.com/bitcoin/bitcoin/issues/19303).

💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840479090)
> A change such as this will have severe consequences on storage space, disincentivizing users from running nodes.

Absolutely false, @jackedproxy. This policy change does not increase the total data throughput allowed on the network. If anything, one could argue that it does the opposite: OP_RETURN data is not discounted like witness data is, thus the size of blocks with data in OP_RETURNs is smaller than those with data in witnesses.

💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840489884)
> Bitcoin's mempool and network already face challenges from known attack vectors like flood and loot attacks, replacement cycling, and irreversible fee attacks, which exploit transaction propagation and fee mechanics to burden nodes or disrupt confirmation reliability.
>
> By removing OP_RETURN limits, we risk introducing new vectors for abuse, such as flooding the network with large, unspendable data outputs, without clear mitigations. These could amplify mempool bloat, increase node resour
...