💬 TheCharlatan commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-2511028472)
>One alternative that I have considered before (for chainstate fuzzing) is to abstract and further modularize BlockManager, which would allow us to have an InMemoryBlockManager for tests (especially useful for fuzzing but also nice in unit tests).
Forgot to post this here at the time, but I was working on an abstract block store for a different context some months ago: https://github.com/TheCharlatan/bitcoin/commit/5f35e506554bae293012ac108d8336801da2204a. I'm not sure how useful this actuall
...
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-2511028472)
>One alternative that I have considered before (for chainstate fuzzing) is to abstract and further modularize BlockManager, which would allow us to have an InMemoryBlockManager for tests (especially useful for fuzzing but also nice in unit tests).
Forgot to post this here at the time, but I was working on an abstract block store for a different context some months ago: https://github.com/TheCharlatan/bitcoin/commit/5f35e506554bae293012ac108d8336801da2204a. I'm not sure how useful this actuall
...
💬 maflcko commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-2511041671)
> since mounting a ramdisk just is very easy
It is indeed easy, but for some reason I found mixed results when doing it by default in the CI: https://github.com/bitcoin/bitcoin/pull/31182 . I couldn't find a real improvement there, except for the `utxo_total_supply` fuzz target. (See also https://github.com/bitcoin-core/qa-assets/issues/158#issuecomment-2118120742)
So forcing the blockstore into ram for this target (and possibly others) could still be useful.
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-2511041671)
> since mounting a ramdisk just is very easy
It is indeed easy, but for some reason I found mixed results when doing it by default in the CI: https://github.com/bitcoin/bitcoin/pull/31182 . I couldn't find a real improvement there, except for the `utxo_total_supply` fuzz target. (See also https://github.com/bitcoin-core/qa-assets/issues/158#issuecomment-2118120742)
So forcing the blockstore into ram for this target (and possibly others) could still be useful.
🚀 fanquake merged a pull request: "ci, macos: Install `pkgconf` Homebrew's package"
(https://github.com/bitcoin/bitcoin/pull/31399)
(https://github.com/bitcoin/bitcoin/pull/31399)
🚀 fanquake merged a pull request: "Remove `src/config` directory"
(https://github.com/bitcoin/bitcoin/pull/31390)
(https://github.com/bitcoin/bitcoin/pull/31390)
💬 Sjors commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2511123617)
> We already clamp the block size in the block assembler
True, but I think it's always better to clearly inform the user when they're trying to do something impossible. That said, not everyone might agree with that. If other reviewers don't like it you can always drop the check.
Will review shortly.
(https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2511123617)
> We already clamp the block size in the block assembler
True, but I think it's always better to clearly inform the user when they're trying to do something impossible. That said, not everyone might agree with that. If other reviewers don't like it you can always drop the check.
Will review shortly.
🚀 fanquake merged a pull request: "dbwrapper: Bump LevelDB max file size to 32 MiB to avoid system slowdown from high disk cache flush rate"
(https://github.com/bitcoin/bitcoin/pull/30039)
(https://github.com/bitcoin/bitcoin/pull/30039)
📝 dergoegge opened a pull request: "doc: correct libfuzzer-nosan preset flag"
(https://github.com/bitcoin/bitcoin/pull/31402)
`--prefix` is not the correct option for using a preset (it's not a option at all).
(https://github.com/bitcoin/bitcoin/pull/31402)
`--prefix` is not the correct option for using a preset (it's not a option at all).
✅ fanquake closed an issue: "Cmake build system breaks with symbolic links"
(https://github.com/bitcoin/bitcoin/issues/31145)
(https://github.com/bitcoin/bitcoin/issues/31145)
🚀 fanquake merged a pull request: "cmake, qt: Use absolute paths for includes in MOC-generated files"
(https://github.com/bitcoin/bitcoin/pull/31361)
(https://github.com/bitcoin/bitcoin/pull/31361)
💬 maflcko commented on pull request "doc: correct libfuzzer-nosan preset flag":
(https://github.com/bitcoin/bitcoin/pull/31402#issuecomment-2511148334)
lgtm ACK 16b140f225a24b9075ef6e4cf6f0788bf96ace5f
(https://github.com/bitcoin/bitcoin/pull/31402#issuecomment-2511148334)
lgtm ACK 16b140f225a24b9075ef6e4cf6f0788bf96ace5f
✅ fanquake closed a pull request: "doc: Update license year range to 2025"
(https://github.com/bitcoin/bitcoin/pull/31400)
(https://github.com/bitcoin/bitcoin/pull/31400)
💬 fanquake commented on pull request "doc: Update license year range to 2025":
(https://github.com/bitcoin/bitcoin/pull/31400#issuecomment-2511150850)
This will happen at some later point.
(https://github.com/bitcoin/bitcoin/pull/31400#issuecomment-2511150850)
This will happen at some later point.
🚀 fanquake merged a pull request: "doc: correct libfuzzer-nosan preset flag"
(https://github.com/bitcoin/bitcoin/pull/31402)
(https://github.com/bitcoin/bitcoin/pull/31402)
💬 dergoegge commented on pull request "[POC] cmake: Introduce LLVM's Source-based Code Coverage reports":
(https://github.com/bitcoin/bitcoin/pull/31394#issuecomment-2511161883)
Would we keep supporting generating coverage with gcc?
(https://github.com/bitcoin/bitcoin/pull/31394#issuecomment-2511161883)
Would we keep supporting generating coverage with gcc?
💬 laanwj commented on issue "macOS 13.7 depends build can't find qt (symlink)":
(https://github.com/bitcoin/bitcoin/issues/31050#issuecomment-2511163338)
Yes, this is a different problem. #31361 had to do with generated (moc) files, not finding Qt itself.
(https://github.com/bitcoin/bitcoin/issues/31050#issuecomment-2511163338)
Yes, this is a different problem. #31361 had to do with generated (moc) files, not finding Qt itself.
💬 Sjors commented on pull request "Miner: never create a template which exploits the timewarp bug":
(https://github.com/bitcoin/bitcoin/pull/31376#issuecomment-2511166913)
> in any normal circumstance
By normal circumstance you mean when nobody else on the network is attempting a timewarp attack? But what if there is one?
Let's say the software is deployed in the future with `MAX_TIMEWARP` set to `300`. But honest miner Alice is still running the v29 release with this PR it, using `600`. Mean miner Bob now wants to produce a block at the end of the retarget period such that others accidentally produce an invalid block. They would set it 600 seconds in the fu
...
(https://github.com/bitcoin/bitcoin/pull/31376#issuecomment-2511166913)
> in any normal circumstance
By normal circumstance you mean when nobody else on the network is attempting a timewarp attack? But what if there is one?
Let's say the software is deployed in the future with `MAX_TIMEWARP` set to `300`. But honest miner Alice is still running the v29 release with this PR it, using `600`. Mean miner Bob now wants to produce a block at the end of the retarget period such that others accidentally produce an invalid block. They would set it 600 seconds in the fu
...
💬 fanquake commented on pull request "cmake: Add `CheckLinkerSupportsPIE` module":
(https://github.com/bitcoin/bitcoin/pull/31359#issuecomment-2511181438)
> Enhances robustness
Can you explain this further? Why is CMakes own check not "robust" enough to use directly? Is this another bug/something that should be improved upstream?
(https://github.com/bitcoin/bitcoin/pull/31359#issuecomment-2511181438)
> Enhances robustness
Can you explain this further? Why is CMakes own check not "robust" enough to use directly? Is this another bug/something that should be improved upstream?
🚀 fanquake merged a pull request: "cmake: Improve build script correctness"
(https://github.com/bitcoin/bitcoin/pull/31357)
(https://github.com/bitcoin/bitcoin/pull/31357)
💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2511204009)
Trivial rebase after #31399.
I disabled ASan + LSan + UBsan again, see previous failure log: https://github.com/bitcoin/bitcoin/actions/runs/11970857809/job/33374462331?pr=30975
(this drops fda0d98237b4a82a94a5672f6bd263bca04adf35 and adjusts 0b5c84bc988e600484012f43df0e9950e7c444f5 to enable multiprocess for `ci/test/00_setup_env_native_valgrind.sh`)
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2511204009)
Trivial rebase after #31399.
I disabled ASan + LSan + UBsan again, see previous failure log: https://github.com/bitcoin/bitcoin/actions/runs/11970857809/job/33374462331?pr=30975
(this drops fda0d98237b4a82a94a5672f6bd263bca04adf35 and adjusts 0b5c84bc988e600484012f43df0e9950e7c444f5 to enable multiprocess for `ci/test/00_setup_env_native_valgrind.sh`)
💬 l0rinc commented on pull request "refactor: prohibit direct flags access in CCoinsCacheEntry and remove invalid tests":
(https://github.com/bitcoin/bitcoin/pull/30906#discussion_r1865645185)
It's not the purpose of this PR to add additional coverage, but after these refactors it's now possible to exercise the negative cases as well (which are missing here but tested in the other test methods, hence the TODO), similarly to how the above PR does for fuzzing.
(https://github.com/bitcoin/bitcoin/pull/30906#discussion_r1865645185)
It's not the purpose of this PR to add additional coverage, but after these refactors it's now possible to exercise the negative cases as well (which are missing here but tested in the other test methods, hence the TODO), similarly to how the above PR does for fuzzing.