💬 laanwj commented on issue "windows: usage of deprecated `std:wstring_convert`":
(https://github.com/bitcoin/bitcoin/issues/32361#issuecomment-2838264061)
So in principle modern Windows can use UTF-8 on the 8-bit APIs, removing need for any conversion, but i'm not sure starting from when, and this relies on setting a specific code page globally at startup.

Alternatively we could borrow these (windows specific) functions from our leveldb patch:
```
// Converts a Windows wide multi-byte UTF-16 string to a UTF-8 string.
// See http://utf8everywhere.org/#windows
std::string toUtf8(const std::wstring& wstr) {
if (wstr.empty()) return std::st
...

👍 brunoerg approved a pull request: "descriptors: Reject + sign while parsing unsigned"
(https://github.com/bitcoin/bitcoin/pull/32365#pullrequestreview-2802901832)
code review ACK fa655da159876861251d1149a5c31a830bd35596

💬 laanwj commented on issue "XOR existing mempools":
(https://github.com/bitcoin/bitcoin/issues/32372#issuecomment-2838311332)
Why don't we? Isn't the `mempool.dat` always written from scratch and not changed in place?

💬 rot13maxi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2838382161)
> > Anything that can appear in your mempool via `OP_RETURN` can already appear as an inscription, at 1/4th the cost for the attacker.
>
> Incorrect. Because 'inscriptions' are an exploit, they have to break up that data into ~500 byte chunks partitioned by PUSH opcodes. This means the largest contiguous piece of raw data to contend with is ~500 bytes.
>
> With unlimited sized OP_RETURN, we now have to deal with ~100KB contiguous pieces of data... 200x more. Far more dangerous from an exte
...

💬 hebasto commented on issue "Option to use dark theme for Windows":
(https://github.com/bitcoin-core/gui/issues/378#issuecomment-2838429843)
Also https://bitcoin.stackexchange.com/questions/126170/bitcoin-core-development

💬 theDavidCoen commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2838436958)
I agree with Pieter Wuille when he wrotes: "(...) these arguments do not apply to OP_RETURN limits, which don't serve an objective harm reduction beyond a subjective "that isn't what you should be using the chain for".

So yes, maybe OP_RETURN limits do not work to prevent spam and we can remove the default value that is totally arbitrary, but node policies are subjective by definition and, as a node operator, I should be allow to define my own size limit without recurring to a fork of Bitcoin
...

⚠️ fanquake opened an issue: "test: interface_usdt_net.py failure under --valgrind"
(https://github.com/bitcoin/bitcoin/issues/32374)
Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-58-generic x86_64)
gcc (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0
valgrind-3.25.0

```bash
cmake -B build -DWITH_USDT=ON
cmake --build build
./build/test/functional/test_runner.py --timeout-factor=9999 --valgrind interface_usdt_net.py
```

```bash
/root/ci_scratch/test/functional/combine_logs.py '/tmp/test_runner_₿_🏃_20250429_111832/interface_usdt_net_0'
test 2025-04-29T11:18:32.583000Z TestFramework (INFO): PRNG seed is: 3961365374660180483
test 2025-04-29T1
...

⚠️ laanwj opened an issue: "Stop shipping ARM32 builds for releases?"
(https://github.com/bitcoin/bitcoin/issues/32375)
Clearly there is no hurry here. This is more of a brainstorming issue than a proposal.

For:

- 64-bit ARM is the standard nowadays for the type of computing hardware our users tend to have (modern Raspberry Pi's and ARM servers). While 32-bit ARM is only still used in low-power embedded systems, an unlikely combination with a bitcoin node.

- 32-bit ARM is the last 32-bit architecture that we ship releases for. After removing this, we could fully focus on optimizing for large virtual address sp
...

🤔 janb84 reviewed a pull request: "descriptors: Reject + sign while parsing unsigned"
(https://github.com/bitcoin/bitcoin/pull/32365#pullrequestreview-2803180000)
tACK [fa655da](https://github.com/bitcoin/bitcoin/pull/32365/commits/fa655da159876861251d1149a5c31a830bd35596)

💬 vasild commented on pull request "build: enable libc++ hardening in debug builds":
(https://github.com/bitcoin/bitcoin/pull/31424#issuecomment-2838575673)
> `ENABLE_HARDENING` and the `hardening_interface` have been removed.

Thanks for the note. There was a silent merge conflict.

`a3a799c77c...e83494d75f`: rebase

💬 hebasto commented on issue "windows: usage of deprecated `std:wstring_convert`":
(https://github.com/bitcoin/bitcoin/issues/32361#issuecomment-2838589290)
> This requires providing a "Fusion manifest for an unpackaged Win32 app", whatever that means, if we can even do this with mingw32.

I believe we can use an approach similar to the one described at https://stackoverflow.com/questions/33000158/embed-manifest-file-to-require-administrator-execution-level-with-mingw32.

💬 Sjors commented on issue "XOR existing mempools":
(https://github.com/bitcoin/bitcoin/issues/32372#issuecomment-2838655864)
> Isn't the `mempool.dat` always written from scratch and not changed in place?

I just realized I should check that...

⚠️ gmart7t2 opened an issue: "Cannot import descriptors with label and internal:false"
(https://github.com/bitcoin/bitcoin/issues/32376)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

```
$ bitcoin-cli importdescriptors '[{"desc":"addr(bcrt1pm2kch7zv4tuc203tfv97yhfck3z456656u3852m03zfl8x2hnnpqw0jzka)#0ygsck2x","timestamp":"now","internal":false,"label":"l"}]'
[
{
"success": false,
"error": {
"code": -8,
"message": "Internal addresses should not have a label"
}
}
]
```

### Expected behaviour

Setting internal:false should not be interpreted a
...

✅ Sjors closed an issue: "XOR existing mempools"
(https://github.com/bitcoin/bitcoin/issues/32372)

💬 Sjors commented on issue "XOR existing mempools":
(https://github.com/bitcoin/bitcoin/issues/32372#issuecomment-2838733407)
Ah, so we have an optional `-persistmempoolv1` that's used to maintain the old version.

Without that `FastRandomContext{}.fillrand(xor_key);` is used every time. So indeed it does:

> it seems candidate for "use a new random XOR key on every rewrite".

🤔 pinheadmz reviewed a pull request: "Replace libevent with our own HTTP and socket-handling implementation"
(https://github.com/bitcoin/bitcoin/pull/32061#pullrequestreview-2799390114)
Thanks so much for the great review @romanz I took most of your suggestions, there's still an open question about `m_recv_buffer` but I really appreciate all your attention to string copying!

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2063711938)
This comment may need to be applied upstream in https://github.com/bitcoin/bitcoin/pull/30988

FWIW, the `Sockman` backend might not be what we end up going with, as @theuni and I are considering an alternative.

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2063952597)
Great thanks, done.

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2064167023)
done

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2064155842)
by internal buffer I assume you mean `m_recv_buffer` which im trying to copy from into the HTTPRequest object, then clear the buffer. I left another response about maybe changing the type of that buffer to reduce unnecessary copies, but am going to leave it alone for this current rebase. What I did here though was swap out `TrimString()` with `TrimStringView()` so at least that's one less.