💬 github12101 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450347899)
> > > hmm I have a small dbcache size I just noticed... can't remember why I set it to that. maybe the increased fsyncs is increasing the chance of a bug somehow? can't think of anything else if its not a hardware issue.
> >
> >
> > Can/did you run memtest86, for several hours? No errors?
>
> I haven't done that yet because I run my entire business (https://damus.io) off this node. my system has been stable for years.

I am afraid, until you do, you can't rule out memory problems. Unti
...

💬 github12101 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450352153)
> 32MB does seem pretty small...

Good point, @jb55 any only 32MiB for dbcache?
I gave it the following:
`dbcache=16384`

Is it recommended to give it as much as you can spare. If you have free RAM, give it couple of gigabytes.

💬 hebasto commented on pull request "cmake: Set top-level target output locations":
(https://github.com/bitcoin/bitcoin/pull/31161#issuecomment-2450355793)
> Concept ACK.
>
> ... we currently have:
>
> ```cmake
> set_target_properties(bitcoin-chainstate PROPERTIES
> SKIP_BUILD_RPATH OFF
> )
> ```
>
> Which I think can be removed now, no?

No, we can't. Only for Windows builds, `*.exe` and `*.dll` files reside in a single `bin` subdirectory. For other platforms, shared libraries still reside in their own `lib` subdirectory, which still require using RPATH.

No, we can't. Only for Windows builds `*.exe` and `*.dll` files resi
...

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1824849464)
> Where does this patch come from? If upstream, can you link to the issue/commits? If not upstream/ it's a bug in Qt, has an issue been opened upstream?

It’s the latter. However, the issue only manifests when cross-compiling for macOS, which is not supported by the Qt project. Therefore, I doubt there’s a reproducible case for the supported build scenarios.

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2450398106)
> There's probably enough GUI-only stuff here, i.e `bison, ninja-build, python3, xz-utils`, that this could be moved to it's own `#### Gui` section.

> See #31192.

Fellow reviewers!

Please review https://github.com/bitcoin/bitcoin/pull/31192 first :)

📝 Sjors opened a pull request: "Remove processNewBlock from mining interface"
(https://github.com/bitcoin/bitcoin/pull/31196)
This method was added in 7b4d3249ced93ec5986500e43b324005ed89502f, but became unnecessary with the introduction of interfaces::BlockTemplate::submitSolution in 7b4d3249ced93ec5986500e43b324005ed89502f.

Suggested in https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2404460342

💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2450415920)
I opened #31196 to drop `processNewBlock`.

💬 instagibbs commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1824870223)
removed the line and updated commit message

💬 jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450422819)
I set it to 1024, will see if that helps

💬 maflcko commented on pull request "[POC] ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#discussion_r1824873424)
IIRC the Ubuntu mirrors are often down, so this would lead to intermittent issues without caching.

🤔 maflcko reviewed a pull request: "[POC] ci: Test cross-built Windows executables on Windows natively"
(https://github.com/bitcoin/bitcoin/pull/31176#pullrequestreview-2408594619)
Thanks for the POC!

Without caching I wonder how useful this is. However, caching may be the hardest part to get right.

Taking a step back, I wonder what was the last real issue found by Wine, which wasn't found by the native Windows task? If there are none, or not too many, I think this could also be made a nightly CI task, only run on master after a merge (without caching), or in a completely separate repo. The same is done for other stuff, like the valgrind tasks, or the s390x tasks.

💬 maflcko commented on pull request "[POC] ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#discussion_r1824875135)
At least with QT, this may be too slow without caching.

💬 maflcko commented on pull request "[POC] ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#discussion_r1824859575)
Forgot to copy the comment?

```suggestion
container: debian:bookworm # Check that https://packages.debian.org/bookworm/g++-mingw-w64-x86-64-posix (version 12.2, similar to guix) can cross-compile
```

💬 maflcko commented on pull request "[POC] ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#discussion_r1824861385)
Also, would be good to remove (in the same commit) `wine` from `ci/test/00_setup_env_win64.sh`, or at least set `RUN_UNIT_TESTS=false`.

💬 Urpferd commented on issue "Bitcoin Core 28.0 (Flatpak Linux Mint) pointing or saving blockchain to external drives does not work":
(https://github.com/bitcoin/bitcoin/issues/31188#issuecomment-2450434016)
Thank you so much, good catch, it is my bad!
Although I don't know when this change into .config might have happened, weird. I don't remember creating this file but copy pasting.

Blocks get now written on external drive but not the other data. Seems some command-line arg switches path back to default datadir, is there any way to change this?

It would be so much easier for less tech savvy people and normies being able to adjust paths trough GUI like other software does.
```
...
Defaul
...

💬 davidgumberg commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2450443551)
Even if a bigger dbcache mitigates the issue because of fewer flushes, using a low dbcache setting should not result in leveldb block checksum mismatches, I will experiment with syncing a node with `-dbache=32`.

With such a low dbcache you are definitely doing way more writing than a node with default dbcache, so I imagine the rate of wear on the disk is somewhat high

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