<bitcoin-git>
[bitcoin] fametrano opened pull request #36409: sign: use fresh randomness as BIP340 auxiliary data (master...sign-bip340-aux-rand) https://github.com/bitcoin/bitcoin/pull/36409
<bitcoin-git>
[bitcoin] fametrano opened pull request #36410: test: cover compact blocks far ahead of the tip (master...test-cmpctblock-revert-to-headers) https://github.com/bitcoin/bitcoin/pull/36410
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
smartin has joined #bitcoin-core-dev
ghost43_ has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master fa0e84e MarcoFalke: ci: refactor: Use printf %q quoting for BITCOIN_CONFIG
<bitcoin-git>
bitcoin/master fa18f9a MarcoFalke: ci: Doc: Move all config comments right next to the option they explain
<bitcoin-git>
bitcoin/master fa90a8a MarcoFalke: ci: [refactor] Use eval-based string-to-argv conversion for FUZZ_TESTS_ARGS
<bitcoin-git>
[bitcoin] fanquake merged pull request #36052: ci: Doc: Move all config comments right next to the option they explain (master...2608-ci-doc-comments) https://github.com/bitcoin/bitcoin/pull/36052
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
smartin2 has joined #bitcoin-core-dev
smartin has quit [Ping timeout: 274 seconds]
smartin2 is now known as smartin
<bitcoin-git>
[bitcoin] fanquake opened pull request #36411: ci: drop `-Wno-error=maybe-uninitialized` from win64 cxx flags (master...win_drop_maybe_uninitialized) https://github.com/bitcoin/bitcoin/pull/36411
enochazariah has joined #bitcoin-core-dev
tarotfied has quit [Quit: WeeChat 4.1.1]
tarotfied has joined #bitcoin-core-dev
tarotfied has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #36412: ci: drop `-U_FORTIFY_SOURCE` from TSAN job (master...tsan_drop_fortify_workaround) https://github.com/bitcoin/bitcoin/pull/36412
enochazariah__ has joined #bitcoin-core-dev
<yancy>
Modifying draft bot sounds like more work for not a lot of benift imo. I think it's fine to add to corecheck.dev since people reviewing will know to look there, and also regular contributers.
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<willcl-ark>
I wouldn't be interested in adding a review to corecheck. I don't think many people look there (sadly). If anything, I'd prefer corecheck to report in it's own comment on the PR too! Although I think the data is often wrong, so not sure that would be useful currently...
<maxedw>
will take a look a look at that example, thanks. It's no good if it's not accurate!
<brunoerg>
I’m not sure about commenting on the PR, would create noise, and won’t produce real conversations (e.g in case of arguing on something suggested by the LLM)
<maxedw>
brunoerg: I agree posting the output of LLM in the comment is noisy. I was thinking more along the lines of headline findings such as regression on coverage.
<maxedw>
Hopefully this can be a prompt to review the output which should be a virtuous circle of then reporting any bad output on corecheck.
adil has quit [Ping timeout: 261 seconds]
adil1 is now known as adil
<yancy>
I agree that PR noise is ideally kept to a min. This is already a very hard project to follow with the volume of activity.
<bitcoin-git>
bitcoin/master f2a0e73 fanquake: ci: drop -U_FORTIFY_SOURCE from TSAN job
<bitcoin-git>
bitcoin/master c57ef54 fanquake: ci: use LLVM libc++ 23.1.2
<bitcoin-git>
bitcoin/master a829aea Hennadii Stepanov: Merge bitcoin/bitcoin#36412: ci: drop `-U_FORTIFY_SOURCE` from TSAN job
<bitcoin-git>
[bitcoin] hebasto merged pull request #36412: ci: drop `-U_FORTIFY_SOURCE` from TSAN job (master...tsan_drop_fortify_workaround) https://github.com/bitcoin/bitcoin/pull/36412
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
adil has quit [Quit: adil]
AtleoS has quit [Quit: AtleoS]
<maxedw>
fanquake: I've had a quick look at that PR and Corecheck is correctly reporting the difference, what is incorrect is this is not caused by the PR but by non-deterministic nature of the test runs. Two proposed solutions would be for corecheck to ignore known lines that hit unpredictably or probably my preferred approach add some more tests that reliably hit those lines.
<maxedw>
As for the benchmarks I need to look into it more but this potentially feels a bit harder as Corecheck highlights when the benchmarks is more than 10% different which happens without code changes. I'm not really sure what the solution is as raising the % difference might hide some meaningful reports? Your thoughts here are appreciated.
deadmanoz has quit [Ping timeout: 251 seconds]
<bitcoindev1337>
how do people feel about llm generated fuzzing targets being added? they're very good at expanding coverage, but not always in ways that actually test something
<bitcoindev1337>
possibly as a separate set of lower quality targets
deadmanoz has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
bitcoindev1337 has quit [Remote host closed the connection]
bitcoindev1337 has joined #bitcoin-core-dev
nymius has joined #bitcoin-core-dev
Guest44 has joined #bitcoin-core-dev
Guest44 has quit [Client Quit]
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
<andrewtoth_>
I think all (or most) code submitted today should be LLM generated, fuzz targets or otherwise. That doesn't mean writing a one-shot prompt and submitting the output. It's a back-and-forth between the LLM and author to get the code to a high enough bar. Every line that is submitted as a PR must be reviewed and understood by the author.
eugenesiegel has joined #bitcoin-core-dev
<bitcoindev1337>
another question, currently disk io failures are handled kind of randomly based on where they happen and what code path they took to get there
cotsuka has quit [Read error: Connection reset by peer]
<bitcoindev1337>
in general any disk io failure seems like a good reason to at least restart the daemon if not just abort
cotsuka has joined #bitcoin-core-dev
<instagibbs>
bitcoindev1337 search issues for that, i think issues are a good place to dsicuss
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Yudis-bit opened pull request #36417: bip352: verify redeem script and pubkey hash in GetPubKeyFromInput (master...bip352-verify-redeem-script) https://github.com/bitcoin/bitcoin/pull/36417
hirish has quit [Ping timeout: 241 seconds]
hirish has joined #bitcoin-core-dev
durandal_ has quit [Remote host closed the connection]
macgyver13 has quit [Quit: macgyver13]
durandal_ has joined #bitcoin-core-dev
durandal__ has joined #bitcoin-core-dev
durandal__ has quit [Client Quit]
<bitcoin-git>
[bitcoin] alexanderwiederin opened pull request #36418: kernel: document that btck_WriteBytes may receive a null pointer (master...kernel-writebytes-nonnull) https://github.com/bitcoin/bitcoin/pull/36418
enochazariah has quit [Read error: Connection reset by peer]
enochazariah has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
l0rinc has quit [Remote host closed the connection]
l0rinc_ has joined #bitcoin-core-dev
l0rinc_ has quit [Read error: Connection reset by peer]
l0rinc has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
bitcoindev1337 has quit [Remote host closed the connection]
eugenesiegel has quit [Quit: Client closed]
bitcoindev1337 has joined #bitcoin-core-dev
memset has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
<bitcoin-git>
bitcoin/master 963f557 fanquake: ci: drop -Wno-error=maybe-uninitialized from win64 flags
<bitcoin-git>
bitcoin/master 65896ac merge-script: Merge bitcoin/bitcoin#36411: ci: drop `-Wno-error=maybe-uninitialized` fro...
<bitcoin-git>
[bitcoin] fanquake merged pull request #36411: ci: drop `-Wno-error=maybe-uninitialized` from win64 cxx flags (master...win_drop_maybe_uninitialized) https://github.com/bitcoin/bitcoin/pull/36411
deadmano- has joined #bitcoin-core-dev
ozdeadman has quit [Ping timeout: 254 seconds]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<bitcoindev1337>
instagibbs: unfortunately the issue/pr about this i found is.. i think not productive in nature
<andrewtoth_>
lol
<instagibbs>
another issue should fix it
<instagibbs>
;)
<sipa>
xkcd 927 strikes again
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<bitcoindev1337>
instagibbs: i mean it's a pr so the original author annoyingly does matter
<bitcoin-git>
[bitcoin] brunoerg opened pull request #36422: test: check unconnecting headers don't reset the getheaders rate limit (master...2026-10-test-unconnecting-headers-getheaders-rate-limit) https://github.com/bitcoin/bitcoin/pull/36422
eugenesiegel has joined #bitcoin-core-dev
enochazariah__ has quit [Quit: Connection closed for inactivity]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
IsaqueFranklin has joined #bitcoin-core-dev
IsaqueFranklin has quit [Changing host]
IsaqueFranklin has joined #bitcoin-core-dev
IsaqueFranklin has quit [Client Quit]
IsaqueFranklin has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
WizJin_ has joined #bitcoin-core-dev
WizJin has joined #bitcoin-core-dev
WizJin__ has quit [Ping timeout: 242 seconds]
WizJin_ has quit [Ping timeout: 255 seconds]
<bitcoindev1337>
sipa: it seems to me that we don't have protection against holes in the leveldb wal, if a batchwrite happens to lineup perfectly and the system fails we could miss an entire batch, extremely unlikely of course but seems possible
IsaqueFranklin has quit [Ping timeout: 243 seconds]
<sipa>
bitcoindev1337: yes, i think that's a known issue with leveldb
<bitcoindev1337>
we could pretty trivially close this by writing a sequence counter per batch
<bitcoindev1337>
otoh i can't find a single person ever reporting something that looks like this, it seems to be triggerable with ext4 and writeback
<sipa>
interruptions at the application level within a batch should be fine; the replay logic can handle that
<sipa>
but i believe it is known that inside leveldb it is possible to cause corruptions by having crashes at the wrong time
<sipa>
leveldb-level corruptions, not application-level corruptions
<bitcoindev1337>
sipa: an entire batch can disappear, nothing leveldb does ensures wal entries are written to disk in order unless fsync is enabled for everywrite, and certain filesystems (notably ext4 dataorder=writeback) will read back zeros (sparse file) when a later part of the file was written
cotsuka has quit [Read error: Connection reset by peer]
<bitcoindev1337>
so you can have an entire batch disappear without later batches failing, though i dont know how this could happen and the 6 block check on start wouldn't also fail
<bitcoindev1337>
you'd have to have a disk that was intermittently connected and later batches got written and earlier batches failed to write?
<bitcoindev1337>
oh and importantly leveldb skips blocks of zeros instead of throwing an error