Bitcoin Core Github
44 subscribers
120K links
Download Telegram
πŸ’¬ Sjors commented on issue "v27.2 guix build fails with hash mismatch":
(https://github.com/bitcoin/bitcoin/issues/31266#issuecomment-2471100700)
I was able to do a complete guix build for v27.2: https://github.com/bitcoin-core/guix.sigs/pull/1433
πŸ’¬ marcofleon commented on pull request "fuzz: Fix difficulty target generation in `p2p_headers_presync`":
(https://github.com/bitcoin/bitcoin/pull/31213#discussion_r1838474496)
Good call, done.
πŸ‘ danielabrozzoni approved a pull request: "doc: mention `descriptorprocesspsbt` in psbt.md"
(https://github.com/bitcoin/bitcoin/pull/31277#pullrequestreview-2430251087)
ACK ebb6cd82baf8406454b18afcb8ccb4e1dde0d43e
πŸ’¬ maflcko commented on pull request "test: Introduce ensure_for helper":
(https://github.com/bitcoin/bitcoin/pull/30893#discussion_r1838505227)
> Yeah, looking at it again, this doesn't make sense because the test may fail if someone actually scales the wait time down. I changed it back and will leave the mocktime approach for a follow-up.


Source: https://github.com/bitcoin/bitcoin/pull/30893#discussion_r1780172239
πŸš€ glozow merged a pull request: "test: enhance p2p_orphan_handling"
(https://github.com/bitcoin/bitcoin/pull/31037)
πŸ’¬ glozow commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2471185762)
reACK 5c2e291060c via range-diff. Nothing but a rebase and removing the conflict.
πŸ’¬ fanquake commented on issue "valgrind: Conditional jump or move depends on uninitialised value(s)":
(https://github.com/bitcoin/bitcoin/issues/29635#issuecomment-2471199603)
I think we could move to Ocular (gives us Valgrind 3.23.0, and we remember to switch to 25 before June), Clang 18 (31273) + some suppressions. Was running some tests of #31273 + this diff:
```bash
diff --git a/ci/test/00_setup_env_native_fuzz_with_valgrind.sh b/ci/test/00_setup_env_native_fuzz_with_valgrind.sh
index d3c95af99e..f0e8e92889 100755
--- a/ci/test/00_setup_env_native_fuzz_with_valgrind.sh
+++ b/ci/test/00_setup_env_native_fuzz_with_valgrind.sh
@@ -6,7 +6,7 @@

export LC_ALL
...
πŸ’¬ fanquake 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-2471201204)
> Wouldn't that require a cmake generation step from binary to header which would basically produce the exact same lines as what we have now?

Yes. See `bench/data/block413567.raw` & `bench/data/block413567.raw.h`, where at build time a header file of ~`125'000` lines is produced.

> Would it help if I simply extracted it to a separate header file instead?

I don't think so. The point is more to not add 100'000s of lines of "data" to this repo, which doesn't scale across many benchmarks, c
...
πŸ’¬ instagibbs commented on pull request "test: enhance p2p_orphan_handling":
(https://github.com/bitcoin/bitcoin/pull/31037#issuecomment-2471202429)
nice cleanup :+1:
πŸ’¬ maflcko commented on issue "valgrind: Conditional jump or move depends on uninitialised value(s)":
(https://github.com/bitcoin/bitcoin/issues/29635#issuecomment-2471212773)
> I think we could move to Ocular (gives us Valgrind 3.23.0

Isn't valgrind 3.22 enough, so we could just stay with the LTS Ubuntu? Also, the suppression won't work for libc++, likely. Not sure if this is worth it to support.
πŸ’¬ fanquake commented on issue "valgrind: Conditional jump or move depends on uninitialised value(s)":
(https://github.com/bitcoin/bitcoin/issues/29635#issuecomment-2471216093)
> Also, the suppression won't work for libc++

We aren't using libc++ though?
πŸ’¬ jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2471226445)
fwiw I ran a full memtest for 4 hours and had no memory issues, so at this point I have no idea. it seems to be running stable for now.
πŸ’¬ jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2471227779)
@laanwj suggested to post the utxoset when it gets corrupted again, will do that when it does.
πŸ‘ theStack approved a pull request: "Ephemeral Dust"
(https://github.com/bitcoin/bitcoin/pull/30239#pullrequestreview-2430361343)
re-ACK 5c2e291060cca3be500f3af0f6f2d3fd2177a7c9
πŸ’¬ instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1838568129)
mmm, seems like a test of generateblock to me? going to leave as is
πŸ’¬ ariard commented on pull request "Halt processing of unrequested transactions v2":
(https://github.com/bitcoin/bitcoin/pull/30572#issuecomment-2471402156)
> I was seeing were mostly non-segwit transactions - not unsolicited transactions. The problematic commit seems to be https://github.com/bitcoin/bitcoin/commit/c7bc444d02d34273a0a42806745e6a32b3146143.

@0xB10C Thanks, that’s interesting. I’ll dig into the `TxRequester`, if due to switching from iterating by status to iterate by peers, if the processing for non-segwit transactions and segwit transactions is always the same.

β€”β€”β€”β€”β€”

>Between 2024-10-29T22:50:51 and 2024-10-29T23:54 the nod
...