💬 shahsb commented on pull request "fuzz: Suppress abort message on Windows":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2072293276)
```suggestion
#ifdef _WIN32
```

`_WIN32` is a compiler flag and could be used for both windows platform i.e windows_x86 (32-bit) as well as windows_x64 (64-bit)

💬 shahsb commented on pull request "fuzz: Suppress abort message on Windows":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2848379451)
Concept ACK

💬 monlovesmango commented on pull request "tests: Added progress tracker when running fuzz test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/32354#discussion_r2072307529)
I think it should be this:
```suggestion
num_targets_completed = log_fuzz_progress(num_targets_completed, len(targets), done_stat, target, target_max_len)
```

My preference would probably change the argument `targets` to `test_list` (and also update the name in args.generate) because this is more consistent with the other modes. However I understand if this is out of scope.

💬 kevkevinpal commented on pull request "tests: Added progress tracker when running fuzz test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/32354#discussion_r2072312807)
I actually had to update this since `test_list` wasnt defined in this function, so I just got the `num_of_targets` at the top and used it here [3af8f62](https://github.com/bitcoin/bitcoin/pull/32354/commits/3af8f625fa1087fc659f5cbf0c5f568f15d89ee1)

lemme know if that looks good!

💬 monlovesmango commented on pull request "tests: Added progress tracker when running fuzz test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/32354#discussion_r2072319868)
lgtm!

💬 monlovesmango commented on pull request "tests: Added progress tracker when running fuzz test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/32354#issuecomment-2848432297)
ACK 3af8f625fa1087fc659f5cbf0c5f568f15d89ee1

💬 hebasto commented on pull request "fuzz: Suppress abort message on Windows":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2072334684)
The current code is consistent with our entire code base.

⚠️ QuantumAlchemist03 opened an issue: "Enhancement: Persist User Settings Across Sessions in Bitcoin Core GUI"
(https://github.com/bitcoin/bitcoin/issues/32410)
Currently, the Bitcoin Core GUI does not retain user preferences such as window size, position, and selected tabs between sessions. This requires users to reconfigure their interface each time they launch the application, which can be inconvenient.

💬 QuantumAlchemist03 commented on issue "Enhancement: Persist User Settings Across Sessions in Bitcoin Core GUI":
(https://github.com/bitcoin/bitcoin/issues/32410#issuecomment-2848488817)
Implement a mechanism to save user interface settings upon application exit and restore them upon startup. This could involve storing preferences in a configuration file or utilizing platform-specific settings storage.

✅ QuantumAlchemist03 closed an issue: "Enhancement: Persist User Settings Across Sessions in Bitcoin Core GUI"
(https://github.com/bitcoin/bitcoin/issues/32410)

💬 romanz commented on pull request "test: add test for decoding PSBT with MuSig2 PSBT key types (BIP 373)":
(https://github.com/bitcoin/bitcoin/pull/32305#issuecomment-2848492497)
tACK 7d301184016a3f59c2e363dff631263cdbe21da0

Tested with both https://github.com/romanz/electrs and https://github.com/romanz/bindex-rs.

💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#issuecomment-2848493348)
tACK https://github.com/bitcoin/bitcoin/commit/7d301184016a3f59c2e363dff631263cdbe21da0

Tested with both [electrs](https://github.com/romanz/electrs) and [bindex](https://github.com/romanz/bindex-rs).

📝 rkrux opened a pull request: "doc: update CWallet::SignTransaction doc to mention SIGHASH_DEFAULT"
(https://github.com/bitcoin/bitcoin/pull/32411)
While `SIGHASH_DEFAULT` & `SIGHASH_ALL` are effectively the same, it's helpful to mention in the function doc exactly what's present in the code.

It can be seen in the function implementation that `SIGHASH_DEFAULT` is passed to the overloaded `SignTransaction` function.

Ref: https://github.com/bitcoin/bitcoin/blob/f490f5562d4b20857ef8d042c050763795fd43da/src/wallet/wallet.cpp#L2177-L2194

<!--
*** Please remove the following help text before submitting: ***

Pull requests without a ra
...

💬 mrberlinorg commented on issue "Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:":
(https://github.com/bitcoin/bitcoin/issues/32402#issuecomment-2848517542)
The core issue with the recent OP_RETURN limit change isn’t the size itself, but that it allows an unlimited number of its outputs per transaction. the PR creator force-resolved my comment. It’s shocking that *a random individual* can arbitrarily change such a base Bitcoin rule.


📝 rkrux opened a pull request: "Musig2 fields followups"
(https://github.com/bitcoin/bitcoin/pull/32412)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2072365927)
It seems to still return a `std::string`:
```
src/util/string.cpp: std::string LineReader::ReadLength(size_t len)
src/util/string.h: std::string ReadLength(size_t len);

```

💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2072367360)
nit: `key` & `value` can also be a `string_view` (here and below)

📝 rkrux opened a pull request: "test: test that descriptorprocesspsbt removes non witness utxos in PSBT"
(https://github.com/bitcoin/bitcoin/pull/32413)
`descriptorprocesspsbt` RPC uses a different flow internally from the `walletprocesspsbt` RPC, which was already tested in the tests.

This patch ensures that `descriptorprocesspsbt` RPC can correctly sign the PSBT while removing the non witness UTXOs in case of Segwit V1 only inputs.

This was identified in the review of #31622 PR.
Ref: https://github.com/bitcoin/bitcoin/pull/31622#discussion_r1979463960

<!--
*** Please remove the following help text before submitting: ***

Pull requ
...

💬 rkrux commented on pull request "psbt: add non-default sighash types to PSBTs and unify sighash type match checking":
(https://github.com/bitcoin/bitcoin/pull/31622#discussion_r2072380490)
I attempted this^ in PR #32413.

💬 pinheadmz commented on issue "Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:":
(https://github.com/bitcoin/bitcoin/issues/32402#issuecomment-2848598024)

> Non-standard transactions: Multiple OP_RETURN outputs in a transaction are considered non-standard. Allowing them could lead to network inconsistencies, as some nodes might not be able to properly process or relay these transactions.

Bitcoin Core changes relay policy regularly, here's one: https://github.com/bitcoin/bitcoin/pull/30239 The policy change rolls out over time on the network and although that literally does "lead to network inconsistencies" that doesn't affect any user's usage of
...

✅ pinheadmz closed an issue: "Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:"
(https://github.com/bitcoin/bitcoin/issues/32402)