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

👋 tdb3's pull request is ready for review: "rpc: getorphantxs follow-up"
(https://github.com/bitcoin/bitcoin/pull/31043)

💬 pilab-gwon commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2395841624)
> Fee estimation needs data, which consists of seeing transactions arrive, and seeing them be mined. Testnet just doesn't have much data.

I'd like to think that this is a problem caused by not having enough data, but that doesn't seem to be the case in my case.

I have two Bitcoin testnet nodes running (let's call them A and B).

Sometimes node A throws the error `Insufficient data or no feerate found`, while node B returns feerate without any problem.

Other times, both nodes A and B
...

💬 maflcko commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2395992525)
> Sometimes node A throws the error `Insufficient data or no feerate found`, while node B returns feerate without any problem.

This is expected, because the two nodes may not have seen the same transactions at the same times.

💬 maflcko commented on pull request "rpc: getorphantxs follow-up":
(https://github.com/bitcoin/bitcoin/pull/31043#discussion_r1789564241)
I wonder if it is possible to use mocktime and an exact assert?