💬 achow101 commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395530872)
> Seems bitcoin core tries to allocate a lot of memory invalidly reading RPC data.

Do you know which RPC it is using that's causing the memory allocation? If you turn on `debug=rpc`, it will be logged in the debug.log.

This sounds like it could be related to #24542 but that should've been fixed by #30094 which is in this release.

Were previous releases working on this machine?

⚠️ dr-orlovsky opened an issue: "Crash due to inadequate memory allocation request upon RPC v1 connection in v28.0.0"
(https://github.com/bitcoin/bitcoin/issues/31041)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

On RPC v1 connection, after the block sync and mempool read is complete, a crash happens (see logs). I used mempool fork of electrs indexer which did an RPC request.

Original report can be found here: https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395525458

### Expected behaviour

No crash is expected

### Steps to reproduce

Run Bitcoin Core (I used machine with 8 core
...

💬 dr-orlovsky commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395532159)
@achow101 created issue as requested: https://github.com/bitcoin/bitcoin/issues/31041

Will add RPC info with `debug=rpc` there

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r1789195290)
done in https://github.com/bitcoin/bitcoin/pull/24539/commits/00ea9012534bdfb0d39c0d2d95103a3645047fd9

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r1789195458)
Collisions are supposed to be extremely rare, I'd rather keep the check as is.

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r1789195511)
done https://github.com/bitcoin/bitcoin/pull/24539/commits/00ea9012534bdfb0d39c0d2d95103a3645047fd9

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r1789195564)
changed in https://github.com/bitcoin/bitcoin/pull/24539/commits/00ea9012534bdfb0d39c0d2d95103a3645047fd9

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r1789195642)
done in https://github.com/bitcoin/bitcoin/pull/24539/commits/00ea9012534bdfb0d39c0d2d95103a3645047fd9

💬 sipa commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-2395534118)
SipHash with a 128-bit key seems like the correct choice for this.

It is indeed not cryptographic, in the sense that it is not practically collision-resistant (no 64-bit hash function can be, as that inherently allows a 2^32 birthday attack).

However, SipHash is effectively as secure and unpredictable as a 64-bit hash function can be, and is specifically designed for preventing attackers from triggering hash table collisions at scale, given that the salt is a uniform 128-bit key unknown to the
...

💬 dr-orlovsky commented on issue "Crash upon RPC v1 connection in v28.0.0":
(https://github.com/bitcoin/bitcoin/issues/31041#issuecomment-2395534798)
With the increase in memory to 8GB the crash has disappeared.

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-2395534947)
> Concept: I am curious about the justification for including this Index in Bitcoin Core vs implementing it as a third party index, especially since it is not required by anything inside of Core itself. It keeps the index in close sync with the chain state and de-duplicates effort among L2-implementations, but adds maintenance burden in Core.
>

I understand that adding new indexes must be justified. This one is simple and quite efficient now, the code is compact, isolated and easy to unders
...

👍 hebasto approved a pull request: "Fix display issues for IPv6 proxy setup in Options Dialog (UI only, no functionality impact)"
(https://github.com/bitcoin-core/gui/pull/836#pullrequestreview-2350580581)
ACK fee4cba48472239f7a426db62f45c4b6af8e5ef2, I have reviewed the code and it looks OK.

🚀 hebasto merged a pull request: "Fix display issues for IPv6 proxy setup in Options Dialog (UI only, no functionality impact)"
(https://github.com/bitcoin-core/gui/pull/836)

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1789208146)
A workaround applied.

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2395582980)
Compatibility issues with the release binaries for Linux platforms have been resolved.

The resulting `bitcoin-qt` binary from `bitcoin-b71b4ba2700b-x86_64-linux-gnu.tar.gz` has been successfully tested on Ubuntu 20.04.

💬 Zero-1729 commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2395588287)
Concept ACK

📝 hebasto opened a pull request: "build: Rename `PACKAGE_*` variables to `BITCOIN_PACKAGE_*`"
(https://github.com/bitcoin/bitcoin/pull/31042)
The use of `PACKAGE_NAME` for the project's variable name is problematic, as this name is commonly used in CMake's [interface variables](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-version-selection). If third-party CMake code handles with scopes improperly, our `PACKAGE_NAME` variable could end up with an unexpected value.

This PR avoids such conflicts by prefixing all `PACKAGE_*` variables with `BITCOIN_`.

The code in the master branch works correctly only i
...

✅ JayBitron closed an issue: "Unable to cross compile on linux for macos (28.x branch)"
(https://github.com/bitcoin/bitcoin/issues/31027)

📝 tdb3 opened a pull request: "rpc: getorphantxs follow-up"
(https://github.com/bitcoin/bitcoin/pull/31043)
Implements follow-up suggestions from #30793.

- Checks verbosity values >2
- Adds a test for `expiration` time
- Adds `entry` time to the returned orphan objects (verbosity >=1) to relieve the user from having to calculate it from `expiration`. Also adds associated test
- Minor cleanup (blank line removal and log message move)

Included a commit to rename the test to a more generic `get_orphans` to better accommodate future orphanage-related RPCs (e.g. `getorphanangeinfo`). Can drop th
...

💬 theStack commented on pull request "test: Assert that when we add the max orphan amount that we cannot add anymore and that a random orphan gets dropped":
(https://github.com/bitcoin/bitcoin/pull/31040#discussion_r1789334417)
I think this line makes the test flaky, as the orphan tx to drop in `TxOrphanage::LimitOrphans` is chosen randomly, i.e. it could also be the last one added (`tx_child_1` in this case). Didn't test locally yet, but I'd assume that about every 100th test run fails.

💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1789361727)
(yeah, marking pretty much all the moved stuff resolved)