💬 maflcko commented on pull request "test: Remove 0.16.3 test from wallet_backwards_compatibility.py":
(https://github.com/bitcoin/bitcoin/pull/30920#issuecomment-2395476278)
I keep seeing the shutdown bug, also locally:

```
test 2024-10-03T15:31:32.242000Z TestFramework (INFO): Test that wallets created in master are too new for 0.16
test 2024-10-03T15:31:32.242000Z TestFramework.node11 (DEBUG): Stopping node
test 2024-10-03T15:31:32.340000Z TestFramework (ERROR): Unexpected exception caught during testing
Traceback (most recent call last):
File "/ci_container_base/test/function
...

💬 garlonicon commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2395484489)
> Testnet coins are nearly impossible to get without an ASIC

Meanwhile, some coins are sitting for hundreds of confirmations in addresses, spendable by anyone: https://mempool.space/testnet4/address/tb1pfees9rn5nz

Also, the whole problem is not because of ASICs, but because of CPUs. Every time, when some ASIC block is there, then the current time is put into the block, which is why after one ASIC block, you can immediately see a bunch of CPU blocks following it. So, mining on top of ASIC b
...

🤔 tdb3 reviewed a 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#pullrequestreview-2350562205)
Concept ACK
Thanks, this is useful!
I'm uncertain if this check is better suited for `p2p_orphan_handling` or `rpc_getorphantxs` (or for a `feature_orphanage` or `mempool_orphanage`). If `p2p_orphan_handling` is the preferred location, I'm happy to include your commit (preserving you as author) in #31037.

https://github.com/bitcoin/bitcoin/blob/master/test/functional/README.md#naming-guidelines

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1789154195)
From https://github.com/bitcoin/bitcoin/pull/30997#pullrequestreview-2337118352:
> > It'd be good if [49b0256](https://github.com/bitcoin/bitcoin/commit/49b025636be266fa17cbb4cdb9d541c0e71f2ef8) explained why bumping to 12 is needed, as the Qt 6 supported platforms for Linux claims anything down to GCC 9 should be supported: https://doc.qt.io/qt-6/supported-platforms.html#linux-x11. I'm guessing this is just because we are using 12 to compile the bins, and could also be worked around.

All ne
...

💬 dr-orlovsky commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395525458)
@sipa yes, it fixed! However this arg is undocumented. Also, I believe that without it Bitcoin Core should not crash but just disconnect the client.

Anyway, I have a solution for the urgent problem, the rest waits. Thank you!

💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395526825)
@dr-orlovsky Are you sure it crashes? That sounds unlikely, based on the changes in this release. Does it segfault? What appears in debug.log?

💬 achow101 commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395527308)
> Basically mempool electrs v3.0.0 in combination with Bitcoin Core v28.0 kill each other once Bitcoin core stops IBS and mempool load

I'm not observing any RPC issues yet with https://github.com/mempool/electrs/commit/055aba1e8d0d8f4cf7080014c89e3b3055e3d0b7, except for it not handling xor'd blocks, but that's a different problem.

> However this arg is undocumented.

It's in the help for `getblockchaininfo`, and also in the release notes.

> Bitcoin Core still crashes right after loa
...

💬 dr-orlovsky commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395528179)
I just attached a screenshot to my previous comment: systemd restarts the node, and reports its crash:

```
Oct 06 17:54:18 core bitcoind[16532]: 2024-10-06T17:54:18Z initload thread exit
Oct 06 17:55:43 core systemd[1]: bitcoind.service: A process of this unit has been killed by the OOM killer.
░░ Subject: A process of bitcoind.service unit has been killed by the OOM killer.
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A process of unit @UNIT has been killed
...

💬 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.