💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395440892)
@dr-orlovsky Does running with `-deprecatedrpc=warnings` fix your issue?

💬 epiccurious commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395452735)
Saw someone's tweet about having to increase `rpcworkqueue`.

https://x.com/_behodler/status/1842657622018683198

📝 kevkevinpal opened 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)
After joining the bitcoin pr review club about https://github.com/bitcoin/bitcoin/pull/30793

I learned about [`CVE-2012-3789`](https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L4693)

So I was motivated to write a functional test that covers this part of the code,

This test should add the max number of orphans to a nodes orphanage and then attempt to add another, then asserts that the number of orphans is still at the max amount

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