💬 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?
(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
...
(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
...
(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?
(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
...
(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
(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
(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.
(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
(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
(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
(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
...
(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.
(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
...
(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.
(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)
(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.
(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.
(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
(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
...
(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
...