💬 andrewtoth commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#issuecomment-2109229135)
After #28233 keeping the entire utxo set in memory will also help connect new blocks as fast as possible, not just for IBD.

💬 fanquake commented on pull request "guix: build with glibc 2.31":
(https://github.com/bitcoin/bitcoin/pull/29987#issuecomment-2109382473)
Pulled in the most recent commits to the 2.31 branch. Mostly make 4.4 compat.

💬 maflcko commented on pull request "wallet: Implement independent BDB parser":
(https://github.com/bitcoin/bitcoin/pull/26606#discussion_r1599457229)
To fix the warning, maybe this can be pulled into a `constexpr` context? Otherwise, `unreachable-code` can be disabled.

```
wallet/bdb.cpp:397:90: error: code will never be executed [-Werror,-Wunreachable-code]
397 | pdb_temp->set_lorder(std::endian::native == std::endian::little ? 4321 : 1234);
| ^~~~
wallet/bdb.cpp:533:97: error: code will never be executed [-Werror,-Wunreach
...

💬 maflcko commented on pull request "cli: Detect port errors in rpcconnect and rpcport":
(https://github.com/bitcoin/bitcoin/pull/29521#discussion_r1599459825)
It is a false positive, so it needs to be disabled, like in the other CI tasks.

✅ maflcko closed an issue: "ci: Android NDK has too old libc++"
(https://github.com/bitcoin/bitcoin/issues/29360)

💬 maflcko commented on issue "ci: Android NDK has too old libc++":
(https://github.com/bitcoin/bitcoin/issues/29360#issuecomment-2109407166)
Let's continue discussion in https://github.com/bitcoin/bitcoin/pull/30049

💬 maflcko commented on issue "ci: Android NDK has too old libc++":
(https://github.com/bitcoin/bitcoin/issues/29360#issuecomment-2109415759)
> UPD. https://bugreports.qt.io/browse/QTQAINFRA-5771

For reference, I guess this was fixed in qt 6.7 then?

💬 Sjors commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#issuecomment-2109418347)
Rebased to make it easier to test the interaction with (merged) #28233. However, any potential benefit goes away after the first restart. The only time -dbcache is filled beyond its previous 16GB limit is during IDB.

In order to benefit from having the full UTXO set in RAM after a restart, we'd have to proactive load the entire UTXO set into -dbcache if space permits.

Added "Make sure you have enough RAM." warning to the GUI.

👋 fanquake's pull request is ready for review: "depends: build zeromq with CMake"
(https://github.com/bitcoin/bitcoin/pull/29723)

👍 cbergqvist approved a pull request: "net: Favor peers from addrman over fetching seednodes"
(https://github.com/bitcoin/bitcoin/pull/29605#pullrequestreview-2054464070)
re ACK b41bbd5688f8f04b2c0e8d7f60d6df6931c17079

Passed functional tests (with `--extended --exclude=feature_dbcrash`).

💬 Sjors commented on pull request "Stratum v2 Noise Protocol":
(https://github.com/bitcoin/bitcoin/pull/29346#issuecomment-2109446347)
@ryanofsky thanks for the suggestion! Maybe I could start by having the `getblocktemplate` RPC use that new interface? So instead of having:

```cpp
NodeContext& node = EnsureAnyNodeContext(request.context);
ChainstateManager& chainman = EnsureChainman(node);
...
Chainstate& active_chainstate = chainman.ActiveChainstate();
...
const CTxMemPool& mempool = EnsureMemPool(node);
...
pblocktemplate = BlockAssembler{active_chainstate, &mempool}.CreateNewBlock(scriptDummy);
```

I would wr
...

💬 Sjors commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1599496409)
It could be a problem if we want test vectors early in the chain. But that can be fixed by a reset once those test vectors are available.

🤔 1440000bytes requested changes to a pull request: "add `-limitdummyscriptdatasize` option"
(https://github.com/bitcoin/bitcoin/pull/29520#pullrequestreview-2054477820)
NACK

This option is useless and adding more "filters" to maintain this will be a waste of time for everyone. There are lot of important and useful things which do not get added in bitcoin core because it will be a maintenance burden. Example: https://github.com/bitcoin/bitcoin/pull/29134

Users who are willing to experiment with different types of "filters" should use knots as it keeps adding them in every release.

Pull requests such as https://github.com/bitcoinknots/bitcoin/pull/78 ma
...

💬 josibake commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1599531009)
Fixed!

💬 josibake commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1599534119)
Thanks for the code snippets @sipa . Seems like there is appetite for this, so added this script to `test/functional/test_framework/crypto/secp256k1.py` as a unit test and removed the sage code from the comment.

💬 josibake commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#issuecomment-2109499772)
Updated the comment to remove the sage code and replaced with a python unit test for calculating H per @paplorinc and @sipa 's suggestion.

💬 russeree commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1599536664)
I don't think the fact the chain has been mined on has any large impact and may even reduce the value proposition later on since there would be 'large' swaths of coins that the early devs have.

Disclaimer: I mined 800K+ testnet4 coins with 700Th/s. I also don't mind burning those coins with OP_RETURN if desired by the community.

💬 paplorinc commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1599557543)
is it possible to avoid hard coding? That kinda' defeats the purpose of the test I think

💬 paplorinc commented on pull request "refactor: reserve memory allocation for transaction outputs":
(https://github.com/bitcoin/bitcoin/pull/30093#discussion_r1599564471)
I've added benchmarks to verify:
```
| ns/op | op/s | err% | total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
| 2,089.91 | 478,489.15 | 0.1% | 1.10 | `BenchmarkAddOutputsEmplaceBackReserve`
| 1,257.81 | 795,031.71 | 0.1% | 1.10 | `BenchmarkAddOutputsInPlaceEmplaceBackReserve`
| 2,594.12 | 385,487.12 | 0.2% | 1.10 | `Benchmar
...

💬 josibake commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1599569794)
I don't think so? The purpose of adding this code is to give a precise definition of how the constant from BIP341 is calculated. The assert confirms that this code generates a point which matches the expected value from BIP341 and allows anyone else to verify that the code == constant in `src/pubkey.cpp` == value from BIP341.