💬 jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450446603)
> I think 32MB might be low enough that a flush gets triggered every block?

I didn't see that in the logs

💬 maflcko commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#issuecomment-2450447158)
> We could have used `ReadLE64` to unify the byte order for keys and writable values, but that shouldn't be necessary, since both have the same endianness locally that shouldn't be affected by a byte-by-byte xor.

The s390x unit tests fail:


```
./src/test/streams_tests.cpp(40): error: in "streams_tests/xor_bytes": check { expected.begin(), expected.end() } == { actual.begin(), actual.end() } has failed.
Mismatch at position 0: � != |
Mismatch at position 1: Y != �
Mismatch at positio
...

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#issuecomment-2450465825)
> The s390x unit tests fail:

I don't know how to access that, is it part of CI? Does the test suite pass on it otherwise or was it just curiosity? Do you know the reason it fails, is my assumption incorrect that endianness should apply to both parts (key and value) the same way?

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824904589)
I prefer the new `key_missing` part, it did confuse me once during development as well

💬 davidgumberg commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450469057)
> I didn't see that in the logs

You can see flushes with `-debug=coindb`

Every block was ambitious, sorry, maybe every ~15 blocks or so.

👍 instagibbs approved a pull request: "test: added test to assert TX decode rpc error on submitpackage rpc"
(https://github.com/bitcoin/bitcoin/pull/31139#pullrequestreview-2408693031)
reACK https://github.com/bitcoin/bitcoin/pull/31139/commits/d7fd766feb2f579bdba0e778bacdeb13103e8282

💬 jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450507672)
maybe ECC ram would be smarter too... could just be getting hit by cosmic rays or something

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1824943979)
I think this is resolved now with the rewrite of `ChangeSet::CalculateMemPoolAncestors()` -- let me know if you agree.

💬 instagibbs commented on pull request "include verbose "reject-details" field in testmempoolaccept response":
(https://github.com/bitcoin/bitcoin/pull/28121#discussion_r1824946074)
@pinheadmz could pop that field just like the check_mempool_result pops fee field?

📝 Sjors opened a pull request: "refactor: mining interface 30955 followups"
(https://github.com/bitcoin/bitcoin/pull/31197)
This PR implements the refactors suggested in https://github.com/bitcoin/bitcoin/pull/30955#pullrequestreview-2354931253.

💬 Sjors commented on pull request "Mining interface: getCoinbaseMerklePath() and submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/30955#discussion_r1824953742)
Done in #31197, though I used `leaf_pos`.

💬 Sjors commented on pull request "Mining interface: getCoinbaseMerklePath() and submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/30955#discussion_r1824954017)
Done in #31197

💬 Sjors commented on pull request "Mining interface: getCoinbaseMerklePath() and submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/30955#discussion_r1824954557)
Done in #31197

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1824955448)
I think I prefer letting the fuzzer pick it, so that I don't have to worry about whether there are other aspects of the transaction I'm overfitting (and thus getting worse coverage than if I let the fuzzer do all the work).

On the other hand, if there are certain transaction templates that we want to be sure are covered, then perhaps I can flip a bool and determine whether to use a pre-constructed transaction versus use one from the fuzzer.

I can't think of what that might be though, so
...

💬 instagibbs commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1824957314)
this is fine, feel free to resolve it

💬 polespinasa commented on pull request "rpc, logging: return "verificationprogress" of 1 when up to date":
(https://github.com/bitcoin/bitcoin/pull/31177#issuecomment-2450524432)
Some calls to the function have duplicated the last argument to pass the tests, but it is necessary to see how to correctly pass the ``best_header``.

💬 Sjors commented on pull request "depends, doc: List packages required to build `qt` package separately":
(https://github.com/bitcoin/bitcoin/pull/31192#issuecomment-2450525374)
Concept ACK.

💬 Sjors commented on pull request "depends, doc: List packages required to build `qt` package separately":
(https://github.com/bitcoin/bitcoin/pull/31192#discussion_r1824962864)
I suggest either leaving out `apt install` or also naming `brew install` and friends, to make it clear this applies to all platforms.

📝 darosior opened a pull request: "init: warn, don't error, when '-upnp' is set"
(https://github.com/bitcoin/bitcoin/pull/31198)
It prevented the GUI from starting when its settings.json had the -upnp option set. This also doesn't prevent the node from running, so this error didn't need to be fatal.

Thanks to Sjors for bringing attention to what i broke and to Maflcko for suggestion a simple short term fix.

💬 instagibbs commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1824965387)
I can't imagine it would greatly effect performance of the fuzz target as it's a single transaction, but it might matter more if more are constructed like in the rest of the harness.

💬 Sjors commented on issue "Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants":
(https://github.com/bitcoin/bitcoin/issues/31109#issuecomment-2450539742)
I made a note to add `waitNewPowBlock()` or something similar to the interface, but I think it can wait for a later release. And we should probably get some performance benchmarks to see if it's even worth it. It's possible that cluster mempool updates stuff so quickly we can just wait for it.