⚠️ 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.

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

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

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2063909861)
we'd still want to erase the data after fulfilling the request though (if I'm understanding your comment correctly). Would it make more sense if `m_recv_buffer` was a `std::deque` or something where we can truncate the structure without copying/moving/shifting left?

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2064398722)
thanks I'll take it!

💬 pinheadmz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2063795724)
Could this be done in a followup? I actually just checked https://github.com/bitcoin/bitcoin/pull/30321 to see why we didn't do this back then -- I remember when that was authored and merged but I didn't realize you were the author!

💬 andrewtoth commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2838942988)
I think @wizkid057 raises a valid point. Merging this would significantly reduce the technical barriers to getting arbitrary large(ish) files stored plaintext on users' disks. I don't think appealing to what other software systems have gotten away with so far is relevant to this project.

The mempool is trivial to obfuscate, simply by restarting the node. The chainstate has been obfuscated for a decade, so there are not likely many users at risk. Nor are any standardness rules for adding plain
...

⚠️ l0rinc opened an issue: "Verify AssumeUTXO snapshot hashes during full validation as well"
(https://github.com/bitcoin/bitcoin/issues/32377)
### Summary

We already hard‑code the AssumeUTXO height/UTXO-snapshot-hash/tx-count pairs (e.g. for mainnet we have heights **840,000** and **880,000**) in https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp#L170-L183.
Currently, this commitment is enforced only when a node explicitly activates a snapshot via `loadtxoutset`.

During a regular initial block download, `-reindex`, or `-reindex-chainstate`, the node never cross‑checks the live chainstate against these values.


...