--- Log opened Thu Jun 12 00:00:10 2025
00:01 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has quit [Ping timeout: 260 seconds]
00:04 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
00:18 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has joined #bitcoin-core-dev
00:28 -!- emcy__ [~emcy@185.69.145.202] has joined #bitcoin-core-dev
00:29 -!- hardtotell8 [~hardtotel@user/hardtotell] has joined #bitcoin-core-dev
00:29 -!- sliv3r__- [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
00:30 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Remote host closed the connection]
00:30 -!- hardtotell [~hardtotel@user/hardtotell] has quit [Read error: Connection reset by peer]
00:30 -!- hardtotell8 is now known as hardtotell
00:31 -!- mcey_ [~emcy@185.69.145.202] has quit [Ping timeout: 260 seconds]
00:35 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:51 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
00:55 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 276 seconds]
00:58 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
01:08 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 268 seconds]
01:26 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has quit [Ping timeout: 260 seconds]
01:32 < vasild> #proposedmeetingtopic Rough poll - how many people use GCC and how many of those do generate code coverage with GCC? Context: https://github.com/bitcoin/bitcoin/issues/31047#issuecomment-2965646793
01:41 < fanquake> Seems like the wrong two questions? Shouldn't it just be, "What compiler do you use to generate code coverage?".
01:43 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
01:45 < janb84> clang + llvm-cov
01:45 < vasild> Well, if we want to know how many people would be affected if we drop X, then the question to ask it "Who is using X?". Also, another thing to consider is that people that use GCC but did not generate coverage in the past are potential users of the to-be-dropped stuff.
01:46 < fanquake> Yea. All of our fuzzing infra, mutation testing etc all use Clang, because it's the only thing that works
01:46 < maflcko> for one-off coverage I just use assert(false) or std::cout and see if it is hit (works with any compiler without coverage tooling)
01:47 < fanquake> Those people can still do whatever they want, assuming they can make it work amongst the matrix of tooling and lcov versions and gcov versions (another reason why it doesn't work out of the box consistently)
01:49 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has joined #bitcoin-core-dev
01:49 < dergoegge> https://maflcko.github.io/b-c-cov/ uses the gcc stuff, right?
01:50 < fanquake> My suggestion is just that we should switch what we have implemented, to be more convenient, for the majority of people already doing useful work (a few exceptions obviously, but that can likely accomodate/don't care too much)
01:54 < maflcko> yeah, corecheck as well: https://github.com/corecheck/corecheck/blob/7734c3773da2ae2f133b7a720dee7d3ede966520/workers/coverage-worker/entrypoint.sh#L50 So would have to remove -DCMAKE_BUILD_TYPE=Coverage there first, before removing it from the build system
01:56 < fanquake> I'm not saying we shouldn't remove it, I'm saying we implement it so it works with Clang, rather than GCC
01:57 < fanquake> *should
01:57 < hebasto> Using clang for coverage reports doesn’t need a dedicated build configuration at all
01:57 < fanquake> (and not try and use any compatibility modes etc)
01:58 < fanquake> Sure, but neither does GCC
02:02 -!- antanst9 [~antanst@user/antanst] has quit [Ping timeout: 272 seconds]
02:03 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
02:04 < hebasto> the coverage build configuration facilitates helping scripts when using cmake multi-config generators.
02:10 -!- antanst9 [~antanst@user/antanst] has joined #bitcoin-core-dev
02:11 < _aj_> i've done a cov build in the past; don't remember if it was gcc or clang. i mostly found the upstream tools confusing, vs problems with the autotools/make stuff (which is why i haven't tried it recently). my config.log suggests i was trying with clang at one point for whatever that's worth
02:11 < fanquake> Given multi-config is primarily to support Windows, it seems less relevant here? Is anyone doing multi-config converage builds (on windows?)?
02:12 < fanquake> _aj_: if you tried using Clang with the current coverage build type, you likely would have run into issues yea
02:13 < _aj_> fanquake: i mean "how do i get useful reports? ah, this then this then that then the other thing. ugh, it worked, but that was so annoying i never want to do it again" from what i remember, anyway
02:14 < _aj_> fanquake: easier to use the drahtbot links now :-/
02:21 < fanquake> _aj: sounds like a situation we need to improve
02:28 < bitcoin-git> [bitcoin] waketraindev closed pull request #32732: net, rpc, qt: add per-peer blocktxn stats to getpeerinfo and qt debug window (master...extra-blocktxn-stats) https://github.com/bitcoin/bitcoin/pull/32732
02:38 -!- tarotfied [~tarotfied@user/tarotfied] has quit [Ping timeout: 244 seconds]
02:39 -!- tarotfied [~tarotfied@user/tarotfied] has joined #bitcoin-core-dev
02:42 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has quit [Quit: Christoph_]
02:42 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
02:44 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
02:45 < bitcoin-git> [bitcoin] fanquake opened pull request #32735: [28.x] More backports (28.x...28_x_win_sign_cmake_4) https://github.com/bitcoin/bitcoin/pull/32735
02:47 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has quit [Ping timeout: 245 seconds]
02:49 -!- Cory [~Cory@user/pasha] has quit [Quit: Client closed]
02:49 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
02:49 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
03:01 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
03:03 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:10 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has quit [Ping timeout: 265 seconds]
03:22 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-dev
03:25 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds]
03:51 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:55 < bitcoin-git> [gui-qml] hebasto pushed 2 commits to main: https://github.com/bitcoin-core/gui-qml/compare/c7678375d081...07093a161c0d
03:55 < bitcoin-git> gui-qml/main b9a9007 johnny9: qml: Remove duplicate property in BlockClock
03:55 < bitcoin-git> gui-qml/main 07093a1 merge-script: Merge bitcoin-core/gui-qml#473: qml: Remove duplicate property in BlockClo...
03:55 < bitcoin-git> [gui-qml] hebasto merged pull request #473: qml: Remove duplicate property in BlockClock (main...duplicate-property) https://github.com/bitcoin-core/gui-qml/pull/473
03:57 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
04:01 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
04:03 -!- Cory [~Cory@user/pasha] has quit [Quit: Client closed]
04:03 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
04:07 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
04:09 < l0rinc> #proposedmeetingtopic [IBD] multi-byte block obfuscation (part of #32043)
04:09 < l0rinc> With the AutoFile batching now merged (#31551), seeking reviewers/reproducers for the block/index obfuscation optimizations in #31144 - achieving >20x performance gain and ~4% overall IBD speedup
04:09 < corebot`> https://github.com/bitcoin/bitcoin/issues/32043 | [IBD] Tracking PR for speeding up Initial Block Download by l0rinc · Pull Request #32043 · bitcoin/bitcoin · GitHub
04:09 < corebot`> https://github.com/bitcoin/bitcoin/issues/31551 | [IBD] batch block reads/writes during `AutoFile` serialization by l0rinc · Pull Request #31551 · bitcoin/bitcoin · GitHub
04:09 < corebot`> https://github.com/bitcoin/bitcoin/issues/31144 | [IBD] multi-byte block obfuscation by l0rinc · Pull Request #31144 · bitcoin/bitcoin · GitHub
04:10 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
04:22 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has quit [Ping timeout: 260 seconds]
04:25 -!- peter_wrighten [~halloy616@user/peter-wrighten:19862] has quit [Ping timeout: 252 seconds]
04:29 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has joined #bitcoin-core-dev
04:30 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
04:35 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has quit [Quit: adil]
04:35 -!- Guest14 [~Guest14@175.100.56.115] has joined #bitcoin-core-dev
04:35 -!- Guest14 [~Guest14@175.100.56.115] has quit [Client Quit]
04:46 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:06 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
05:11 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
05:20 -!- Guyver2 [Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
05:30 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:31 < vasild> achow101: (or whoever hosts the meeting) I will not be at the meeting. The point of the topic I proposed is to get an estimate of how many people would be affected if we remove something that they use (GCC coverage from CMake as it is now)
05:38 -!- janb84 [~janb84@user/janb84] has quit [Ping timeout: 244 seconds]
05:40 -!- janb84 [~janb84@user/janb84] has joined #bitcoin-core-dev
05:42 -!- sliv3r__- [~sliv3r__@user/sliv3r-:76883] has quit [Read error: Connection reset by peer]
05:42 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
06:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:00 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Read error: Connection reset by peer]
06:00 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
06:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
06:09 -!- Guyver2 [Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
06:21 -!- VonNaturAustreVe [~natur@2804:14c:65d7:8e6c:7541:3e0a:2a42:b855] has joined #bitcoin-core-dev
06:21 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has changed host
06:28 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
06:29 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
06:30 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Remote host closed the connection]
06:31 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
06:42 < bitcoin-git> [bitcoin] hodlinator opened pull request #32736: wallet: Warn upon failing to scan directory (master...2025/06/wallet_dir_iter) https://github.com/bitcoin/bitcoin/pull/32736
06:49 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
07:00 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Ping timeout: 252 seconds]
07:01 -!- Guest5082 [~ubuntu@197.237.184.179] has joined #bitcoin-core-dev
07:21 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
07:27 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
07:32 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
07:46 -!- mcey_ [~emcy@148.252.145.190] has joined #bitcoin-core-dev
07:49 -!- emcy__ [~emcy@185.69.145.202] has quit [Ping timeout: 252 seconds]
07:49 -!- Cory [~Cory@user/pasha] has quit [Quit: Client closed]
07:49 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
07:51 -!- Cory [~Cory@user/pasha] has quit [Client Quit]
07:51 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
07:53 < bitcoin-git> [bitcoin] rkrux opened pull request #32737: rpc, doc: clarify the response of listtransactions RPC (master...listtx) https://github.com/bitcoin/bitcoin/pull/32737
07:57 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:58 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
08:01 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
08:08 < lightlike> vasild: I usually use gcc and have used lcov with it on occasion before, but clang is necessary anyway (sanitizers, fuzzing), so I don't really care, just need something that works and is documented.
08:13 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has quit [Quit: Christoph_]
08:27 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:37 < bitcoin-git> [bitcoin] Bitchryankilledme opened pull request #32738: Create msbuild.yml (master...master) https://github.com/bitcoin/bitcoin/pull/32738
08:37 < bitcoin-git> [bitcoin] DrahtBot closed pull request #32738: Create msbuild.yml (master...master) https://github.com/bitcoin/bitcoin/pull/32738
08:43 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
08:45 -!- Cory [~Cory@user/pasha] has quit [Quit: Client closed]
08:45 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
08:51 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
08:55 -!- Emc99 [~Emc99@212.129.86.199] has joined #bitcoin-core-dev
08:58 -!- dermoth_ [~dermoth@user/dermoth] has joined #bitcoin-core-dev
09:00 <@achow101> #startmeeting
09:00 < corebot`> achow101: Meeting started at 2025-06-12T16:00+0000
09:00 < corebot`> achow101: Current chairs: achow101
09:00 < hodlinator> hi
09:00 < corebot`> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
09:00 < corebot`> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
09:00 < corebot`> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
09:00 < TheCharlatan> hi
09:00 <@achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
09:00 < maxedw> hi
09:00 -!- dermoth [~dermoth@user/dermoth] has quit [Ping timeout: 276 seconds]
09:00 < hebasto> hi
09:00 < furszy> hi
09:00 < johnny9dev> hi
09:00 < dergoegge> hi
09:00 < pinheadmz> hi
09:00 < fjahr> hi
09:00 < brunoerg_> hi
09:00 < vasild> hi (I am back on time)
09:00 < lightlike> hi
09:00 < instagibbs> hi
09:00 <@achow101> There are 2 preproposed meeting topics this week. Any last minute ones to add?
09:01 < eugenesiegel> hi
09:01 < stickies-v> hi
09:01 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
09:01 < l0rinc> hi
09:01 -!- enochazariah [~enochazar@102.91.103.249] has joined #bitcoin-core-dev
09:01 < cfields> hi
09:01 < jonatack> hi
09:01 <@achow101> #topic Fuzzing WG Update (dergoegge)
09:02 < dergoegge> Fuzzamoto (https://github.com/dergoegge/fuzzamoto) has been my primary focus the last couple months. Wrote some notes on what I’ve been up to here: https://gist.github.com/dergoegge/46c7a5fd2468b5b108f5c34ac1f88e45. Quick summary:
09:02 < dergoegge> The project now includes a custom fuzzing engine for structure aware fuzzing of p2p protocol message sequences. Coverage report for that as of jun 10: https://dergoegge.github.io/bitcoin-coverage/fuzzamoto/ir-jun10/coverage/bitcoin/index.html
09:02 < dergoegge> Highlights from the cov report:
09:02 < dergoegge> More net_processing coverage than the in-repo fuzz tests, in all coverage metrics (line, function, region, branch) coverage (e.g. ~70% vs ~ 64% line coverage). Also coverage for reorgs went from nothing to something (i.e. Chainstate::DisconnectTip, Chainstate::MaybeUpdateMempoolForReorg)
09:02 -!- dermoth_ is now known as dermoth
09:03 < dergoegge> I’m still working on extending the fuzzer to increase coverage (e.g. no compact block support atm) and brainstorming what kind of bug oracles are feasible (please lmk if you have any ideas, join the fuzzing wg)
09:03 < purpleKarrot> hi
09:03 < dergoegge> Lastly, it would be interesting to have a collection of real p2p/validation bugs to test the fuzzer against (beyond what’s list ed on https://bitcoincore.org/en/security-advisories/). If you know of or have found bugs in your own or other PRs please let me know! Any kind of bug (logic, crash, …) is fine.
09:03 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has joined #bitcoin-core-dev
09:03 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-dev
09:03 < marcofleon> hype
09:03 < instagibbs> nice re:reorgs
09:03 < rkrux> hi
09:03 < eugenesiegel> awesome about reorgs
09:04 < brunoerg_> nice
09:04 < sipa> hi
09:05 < sipa> dergoegge: cool, will think about bugs that can be included
09:06 <@achow101> #topic Kernel WG Update (TheCharlatan)
09:06 < TheCharlatan> I pushed a new version of #32427 including a write ahead log and crc32c checksums for each entry. Performance still seems to be a bit better compared to leveldb. This should make writes atomic and provide detection for potential corruption.
09:06 < corebot`> https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
09:07 < cfields> 🚀
09:07 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has quit [Client Quit]
09:07 < TheCharlatan> also looking for review on #32317
09:07 < corebot`> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
09:08 < TheCharlatan> that's all for now
09:08 < sipa> TheCharlatan: (sorry for being lazy and not looking at code), what path structure are you using?
09:08 < cfields> 32427 spawned a discussion about a new on-disk block layout that is a bit of a distraction...
09:08 < sr_gi[m]1> hi
09:08 < abubakarsadiq> hi
09:08 -!- enochazariah97 [~enochazar@169.197.85.174] has joined #bitcoin-core-dev
09:08 < sipa> cfields: jinx, ok...
09:08 < cfields> I think it might be worth having that discussion here a bit..
09:08 < TheCharlatan> path structures?
09:08 < cfields> sipa: hah
09:09 < sipa> TheCharlatan: directory/file names
09:09 -!- hernanmarino [~hernanmar@2800:2330:2800:2e7:90fa:a87a:ffb2:3428] has quit [Ping timeout: 268 seconds]
09:09 < l0rinc> TheCharlatan: "Performance still seems to be a bit better compared to leveldb" - I have measured a reindex until 888888 blocks for your PR and the performance seemed roughly the same
09:09 -!- enochazariah [~enochazar@102.91.103.249] has quit [Ping timeout: 272 seconds]
09:09 < TheCharlatan> oh, yeah, the PR does not touch the actual block storage hierarchy. 
09:09 < sipa> ah, ok
09:10 < cfields> tldr: in the review for 32427, several reviewers brought up the idea of changing the on-disk block format while we're at it. One suggested example is one-file-per-block...
09:10 < dergoegge> the on disk block index storage performance should not affect ibd at all, we keep all of it in memory no?
09:11 < sipa> dergoegge: flushes to utxo set trigger flushes of block data, which could take some marginal amount of time?
09:11 < TheCharlatan> I also think that given that we have some flexibility with the existing pair of 64bit numbers to point to a location on disk, we might be able to use the encoding for single block files.
09:11 < cfields> for 32427 to move forward, we either need to agree to punt on that discussion and bring it up again later, or bikeshed some layout changes. For the sake of not grinding the flat index changes to a halt, I prefer the former.
09:11 < dergoegge> sipa: ah right, ty
09:11 < vasild> "one-file-per-block" ... some filesystems may not handle well 1M files, is there any benefit from doing that?
09:12 < l0rinc> won't we have problems with so many open files on Windows - like we had with LevelDB?
09:12 < sipa> vasild: they can be grouped into subdirectories too, either by hash, or (my suggestion, i think) by height
09:12 < cfields> vasild: you don't really need an index anymore if the blocks can be located using the filesystem alone.
09:12 < vasild> sure, I do not mean 1M files in a single directory
09:12 < cfields> er, a much simpler index at least.
09:12 < sipa> yes, agree with that, don't put 1M files in a single directory :)
09:13 < l0rinc> would be really cool to try it out though - let me know if I can help with benchmarking anything
09:13 < TheCharlatan> dergoegge yes, in ibd time it is just good to know there are no regressions. The speedup during block index loading when starting a node is more significant though.
09:13 < lightlike> people tend to copy datadirs for backups etc. years ago that would take very long with millions of files, did that change?
09:13 < sipa> cfields: no need for the block data structure change (if any) to be made in the same PR, it suffices if it's in the same release
09:14 -!- enochazariah97 [~enochazar@169.197.85.174] has quit [Quit: Client closed]
09:14 -!- freedomcode [~reardenco@shrugged.reardencode.com] has quit [Remote host closed the connection]
09:14 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined #bitcoin-core-dev
09:15 < sipa> cfields: well "index" isn't the right word anymore then, but we still have a block database with things like validation status and so on (though, arguably, that belongs more in validation then block storage)
09:15 < vasild> cfields: that would be like outsouring the indexing to the OS/filesystem, e.g. blocks/1/15/153/153764 (for block 153764). The question is can we do better than the worst OS/FS that is going to use Bitcoin Core, or even, better than the best FS?
09:15 < l0rinc> would that mean that leveldb indexes can point to files and indexes now instead of duplicating any data? Or is that still problematic for pruned nodes?
09:15 < sipa> it'd be pretty awesome if the block index can go away, and its remaining fields moved into the chainstate
09:15 < vasild> I guess it has to be tested...
09:15 < cfields> sipa: right
09:16 < sipa> though maybe not more than an aesthetical advantage
09:16 < sipa> it's just ugly that we store validity of a block in the block index, it's not a storage-related thing but a validation-related one
09:16 < cfields> sipa: much easier for non-core software to read blocks. definitely not just aesthetic.
09:16 < sipa> cfields: i'm talking about the block index going away, independent of block storage structure used
09:17 < sipa> lightlike: yeah, i worry about that too - maybe in these days with fast SSDs that's less of an issue, but i don't actually know
09:18 < cfields> sipa: not sure what you mean. how does it go away if we still need to map them to a non-addressable location?
09:19 < TheCharlatan> also seems useful though to have block validity included for as long as we can't read the chainstate easily from external sources.
09:20 < sipa> cfields: sorry, i'm being confusing. I'm talking about the advantage of the block index going away, which is something that's only possible with a change to directory structure - but i'm just talking that that index going away itself is nice, ignoring the advantage that the directory structure may bring without that
09:20 < sipa> TheCharlatan: i disagree!
09:20 < sipa> TheCharlatan: it's pretty counterintuitive that someone just copying the block data, but not chainstate, would inherit the validity status from that block data
09:20 < cfields> sipa: ah, yes, completely agree.
09:22 < TheCharlatan> mmh, so you couldn't recreate the  block tree anymore without re-validating?
09:23 < sipa> TheCharlatan: i just wouldn't think of the validity status as part of the block data
09:23 < sipa> you can recreate it from just disk, but without a chainstate to fill in validity status, every block would be marked as non-validated
09:23 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has joined #bitcoin-core-dev
09:24 < sipa> this is probably getting a bit into the weeds for this meeting
09:24 < TheCharlatan> yes :)
09:24 < lightlike> i feel like the discussion of this idea deserves a separate issue, it's not that related to ThCharlatan's PR.
09:25 < TheCharlatan> sooo... next topic?
09:25 <@achow101> next topic
09:25 <@achow101> #topic Benchmarking WG Update (josie, l0rinc)
09:26 < l0rinc> I have opened the obfuscation PR in Oct 2024, split off other smaller optimizations since, some of those are merged already - the XOR block obfuscation one is next, reproducers and reviewers are welcome
09:26 < l0rinc> I've received 2 raspberry pi servers recently, I will be able to do benchmarks on those as well (already measured Sipa's #32545) - since many people are complaining they're IBDs are taking weeks
09:26 < corebot`> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
09:26 < l0rinc> And lately I'm measuring memory usages as well besides performance with massif and heaptrack as well - see #28531
09:27 < corebot`> https://github.com/bitcoin/bitcoin/issues/28531 | improve MallocUsage() accuracy by LarryRuane · Pull Request #28531 · bitcoin/bitcoin · GitHub
09:27 < jonatack> nice
09:27 < l0rinc> I noticed that GCC and Clang optimize differently - is it important to benchmark both?
09:27 -!- Guest5082 [~ubuntu@197.237.184.179] has quit [Ping timeout: 245 seconds]
09:28 < sipa> whatever is used for releases is what matters most
09:28 < fanquake> GCC 13.3.0
09:28 < sipa> which is IIRC clang for macOS and gcc for windows and linux
09:28 < fanquake> clang 18 for macos
09:29 < l0rinc> the tracking PR for speeding up Initial Block Download, where I have collected the results of the benchmarks I've done is in #32043
09:29 < corebot`> https://github.com/bitcoin/bitcoin/issues/32043 | [IBD] Tracking PR for speeding up Initial Block Download by l0rinc · Pull Request #32043 · bitcoin/bitcoin · GitHub
09:29 < jonatack> maybe you are already doing so, but benchmarking with slow internet connections for ibd/p2p might reveal additional issues in how a change under consideration impacts nodes under more hostile conditions like that
09:30 -!- Cory [~Cory@user/pasha] has quit [Quit: Client closed]
09:30 < l0rinc> the PI server are also on slightly slower network and lower memory (4 & 8GB)
09:30 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-dev
09:31 < dzxzg> it's challenging to create realistic bad network conditions in a way that is also reproducible
09:31 < l0rinc> if you think it's important, I can simulate slow connections as well to see what that reveals (the Hetzner servers I have are very fast for normal IBD as well, I guess the nodes it find are probably also from Hetnzer)
09:32 < jonatack> benchmarking how bitcoind holds up under tough conditions seems valuable (i find it does very well currently, apart from ibd time)
09:33 < jonatack> (and the stalling/timeout->disconnect logic)
09:33 < sipa> yeah i think those are very different things to measure
09:33 < l0rinc> I've also checked swiftsync with very simpmple xor instead of muhash - and locally on my laptop it finished a reindex until 888888 blocks in 29 minutes
09:33 < sipa> pure computation/disk/io based effects
09:33 < abubakarsadiq> not sure whether it will help, but having a node with few peers as well? like doing ibd without inbounds, someone complained to me that their ibd was slow.
09:33 < abubakarsadiq> when I checked it due to having very few peers, basically no inbounds at all.
09:33 < sipa> vs network block IBD fetching effects
09:33 < eugenesiegel> I have heard that netem can be used to simulate latency
09:34 <@achow101> sorry, going to try to keep things moving since we have 2 actual topics this week
09:34 <@achow101> we can have further discussion after the meeting, or in an issue on github
09:34 < l0rinc> k, thanks
09:34 <@achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
09:35 < sipa> not much to report
09:35 < sipa> next to review remains reorg support in txgraph, #31553
09:35 < corebot`> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
09:36 < sipa> had some activity on a test-only but non-blocking PR, #30605, which had a review club, and grew a bit in more test improvements since
09:36 < corebot`> https://github.com/bitcoin/bitcoin/issues/30605 | Cluster linearization: separate tests from tests-of-tests by sipa · Pull Request #30605 · bitcoin/bitcoin · GitHub
09:36 < sipa> i posted instructions for more intensive benchmarking of the new linearization algorithm in #32545, if people want to participate in that
09:36 < corebot`> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
09:36 < sipa> that's it from me
09:36 <@achow101> #topic MuSig2 WG Update (achow101, rkrux)
09:37 <@achow101> Not much to update, #31244 has gotten some review which I've been addressing
09:37 < corebot`> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
09:37 <@achow101> The change to the BIP is still waiting to see if anyone has an opinion on the duplicate participants
09:37 <@achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
09:37 < sipa> achow101: link to BIP change?
09:37 < sipa> ah, or that's on the ML?
09:37 <@achow101> sipa: ML
09:37 < jonatack> https://github.com/bitcoin/bips/pull/1867
09:37 < johnny9dev> Significant progress was made this week on rebasing the project and moving it to CMake+Qt6. Both hebasto and pinheadmz have PRs now to test and fix issues with the update. bitcoin-core/gui-qml#470 bitcoin-core/gui-qml#472. Both PRs are now able to load up the QML app and get to the main navigation and views. 
09:37 < johnny9dev> For myself, I've been focused on the current Send and Recieve PRs that are in review. I've also been making updates to how address inputs are handled, bitcoin amount label formatting, and address label formatting to get closer to the design spec.
09:37 < corebot`> https://github.com/bitcoin-core/gui-qml/issues/470 | [WIP] Sync with main repo: CMake + Qt 6 by hebasto · Pull Request #470 · bitcoin-core/gui-qml · GitHub
09:37 < sipa> achow101: thanks
09:38 < corebot`> https://github.com/bitcoin-core/gui-qml/issues/472 | Rebase gui-qml on bitcoin/bitcoin, include qt6 and cmake by pinheadmz · Pull Request #472 · bitcoin-core/gui-qml · GitHub
09:38 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
09:38 < hebasto> bitcoin-core/gui-qml#472 is preferred 
09:38 < corebot`> https://github.com/bitcoin-core/gui-qml/issues/472 | Rebase gui-qml on bitcoin/bitcoin, include qt6 and cmake by pinheadmz · Pull Request #472 · bitcoin-core/gui-qml · GitHub
09:39 <@achow101> #topic Script Validation WG Update (fjahr)
09:40 < fjahr> Nothing really noteworthy this week, more time for the *actual* topics ;)
09:40 <@achow101> #topic Erlay WG Update (sr_gi, gleb)
09:41 < sr_gi[m]1> Nothing much to report on my end either, I've been off a couple of weeks. Currently picking warnet sims where I left them before leaving. Will report once I'm finished
09:41 <@achow101> #topic Rough poll - how many people use GCC and how many of those do generate code coverage with GCC? (vasild)
09:41 < vasild> Trying to get an estimate of how many people are using the current GCC-oriented coverage we have in CMake.
09:41 < eugenesiegel> I use gcc for code coverage
09:41 <@achow101> I use gcc, but I haven't generated coverage with it in ~5 years (or any other coverage really)
09:42 < sipa> i use GCC for creating benchmarking builds, and clang for fuzzing builds; i haven't used coverage tools for a long time (maybe i should?)
09:42 -!- Guest4319 [~ubuntu@197.237.184.179] has joined #bitcoin-core-dev
09:42 < fjahr> Only have been using clang for anything cov related since that was what was recommended to me, but definitely not a heavy user lately
09:42 < eugenesiegel> coverage reports are nice for telling you where the fuzzer is stuck
09:43 < fanquake> eugenesiegel: are you using GCC for fuzzing? Or just switching to it for coverage?
09:44 < eugenesiegel> fanquake: I use libfuzzer to fuzz on a VM, and then run the corpus through with gcc coverage on my mac
09:44 < fanquake> gcc on a mac is clang though? So brew installed GCC?
09:44 < l0rinc> I usually use test code coverage in cLion which automatically adds the `-DCMAKE_CXX_FLAGS="-fcoverage-mapping -fprofile-instr-generate" -DCMAKE_C_FLAGS="-fcoverage-mapping -fprofile-instr-generate"` options
09:45 < dergoegge> l0rinc: and then you (or cLion) uses the llvm tools to create the actual report?
09:46 < l0rinc> there's a built-in report, haven't checked how it generates it
09:46 < eugenesiegel> fanquake: oh, I didn't know that. I use gcov so I assumed it was gcc
09:47 < fanquake> What is the output of gcc --version
09:47 < dergoegge> eugenesiegel: to clarify, your reports look like this: https://maflcko.github.io/b-c-cov/fuzz.coverage/index.html ?
09:47 < vasild> for the records, the context of this topic is https://github.com/bitcoin/bitcoin/issues/31047
09:48 < eugenesiegel> fanquake: clang 16
09:48 < fanquake> Right, so that'll probably be Clang in compat mode
09:49 < eugenesiegel> dergoegge: no they don't, they look like this https://crypt-iq.github.io/fuzz_coverage_reports/cmpctblock-nyx-cov-06012025/
09:49 < jonatack> brew says gcc 15.1, but currently for me gcc --version is Apple clang version 17.0.0 (clang-1700.0.13.5)
09:49 <@achow101> I'm fine with replacing the gcc based coverage with clang based. IIRC, the current instructions don't even work?
09:50 -!- Sjors[m]1 [~provooste@2620:6e:a000:ce11::1f] has quit [Quit: Reconnecting]
09:50 <@achow101> already have to switch compilers to use libfuzzer, and to get things like thread-safety warnings
09:50 -!- Sjors[m]1 [~provooste@2620:6e:a000:ce11::1f] has joined #bitcoin-core-dev
09:50 < marcofleon> I think we have proper clang coverage instructions in the docs?
09:50 < dergoegge> eugenesiegel: got it! "Generated by llvm-cov", so you're using the clang and the llvm tooling
09:51 < vasild> achow101: current instructions work for me: https://github.com/bitcoin/bitcoin/issues/31047#issuecomment-2658930755
09:51 < dergoegge> (that's what it says at the bottom)
09:51 < Sjors[m]1> #31047
09:51 < corebot`> https://github.com/bitcoin/bitcoin/issues/31047 | build: RFC Coverage build type · Issue #31047 · bitcoin/bitcoin · GitHub
09:51 < dzxzg> Isn't it possible to compile with gcc and make a coverage report with lcov?
09:52 <@achow101> vasild: hmm ok. I did try a while ago and it didn't work, but didn't try to debug what went wrong
09:52 < eugenesiegel> dergoegge: oops. I think I used to use gcc but I guess not anymore
09:52 < fanquake> dzxzg: it depends on the system, the verison of the tools, might require additional options etc
09:53 < fanquake> i.e there are breaking changes between lcov 1.6 and 2.0
09:53 < dergoegge> I think the llvm reports are also just more readable (see my comment here: https://github.com/bitcoin/bitcoin/issues/31047#issuecomment-2396661558)
09:53 < fanquake> using clang / llvm, unless you're installation is somehow broken, everything will just work in harmony
09:53 < fanquake> and you get working sanitizers, fuzzing, thread safety etc
09:54 < fanquake> (hence why all of our important infra is using it)
09:54 <@achow101> i think further discussion can happen in the issue
09:54 < dergoegge> so no one is using gcc is the conclusion?
09:54 < sipa> except release builds
09:54 < sipa> :p
09:54 <@achow101> dergoegge: seems like it
09:54 < vasild> :)
09:55 <@achow101> #topic [IBD] multi-byte block obfuscation (l0rinc)
09:55 < dergoegge> :D
09:55 < l0rinc> I have already talked about this, thanks
09:56 <@achow101> ah, it was just asking for more review?
09:56 <@achow101> Any other topics to discuss?
09:56 < l0rinc> and I haven't talked about this before, just decided to join IRC, so wanted to give some context :)
09:58 <@achow101> #endmeeting
09:58 < corebot`> achow101: Meeting ended at 2025-06-12T16:58+0000
09:58 < corebot`> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-06-12_16_00.log.json
09:58 < corebot`> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-06-12_16_00.log.html
09:58 < corebot`> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-06-12_16_00.html
09:58 -!- Emc99 [~Emc99@212.129.86.199] has quit [Quit: Client closed]
09:58 <@achow101> vasild: I think last time I tried lcov was before we merged cmake, so maybe the problem was autotools :)
09:59 < vasild> ;-)
09:59 < bitcoin-git> [bitcoin] fanquake opened pull request #32739: tsan: drop Qt wildcard suppressions (master...unwildcard_qt) https://github.com/bitcoin/bitcoin/pull/32739
10:01 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
10:02 -!- dzxzg [~dzxzg@user/dzxzg] has quit []
10:02 < darosior> vasild: most of the time i use gcc for default builds and clang for fuzzing or using sanitizers. I generate source-based coverage with LLVM. I have never used gcov based coverage as presented in our doc.
10:03 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has quit [Quit: Christoph_]
10:07 -!- Guest4319 [~ubuntu@197.237.184.179] has quit [Remote host closed the connection]
10:10 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
10:10 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
10:11 -!- cotsuka [~cotsuka@user/cotsuka] has quit [Remote host closed the connection]
10:13 -!- cotsuka [~cotsuka@user/cotsuka] has joined #bitcoin-core-dev
10:19 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
10:25 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
10:32 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
10:55 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
11:00 < vasild> darosior: looks like one more confirmation of "< dergoegge> so no one is using gcc is the conclusion?" :)
11:08 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
11:14 -!- Cory93 [~Cory@user/pasha] has joined #bitcoin-core-dev
11:18 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:18 -!- Cory [~Cory@user/pasha] has quit [Ping timeout: 272 seconds]
11:21 < hodlinator> vasild: I've used GCC mainly for getting benchmarks resembling release builds, otherwise I'm happy to use Clang. Haven't really used coverage that much yet.
11:28 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
11:38 < fanquake> CoreCheck is using it, however speaking to Max, he was already looking into migrating to LLVM/Clang
11:55 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has quit [Ping timeout: 260 seconds]
12:15 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
12:19 -!- Cory15 [~Cory93@user/pasha] has joined #bitcoin-core-dev
12:23 -!- Cory93 [~Cory@user/pasha] has quit [Ping timeout: 272 seconds]
12:24 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:31 -!- dyscope [~dyscope@91.218.89.24] has joined #bitcoin-core-dev
12:32 -!- dyscope_ [~dyscope@91.218.89.24] has joined #bitcoin-core-dev
12:32 -!- dyscope [~dyscope@91.218.89.24] has quit [Remote host closed the connection]
12:32 -!- dyscope_ [~dyscope@91.218.89.24] has quit [Remote host closed the connection]
12:32 -!- dyscope [~dyscope@91.218.89.24] has joined #bitcoin-core-dev
12:36 -!- dyscope [~dyscope@91.218.89.24] has quit [Remote host closed the connection]
12:36 -!- dyscope [~dyscope@91.218.89.24] has joined #bitcoin-core-dev
12:37 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has joined #bitcoin-core-dev
12:43 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has quit [Ping timeout: 248 seconds]
12:55 -!- robobub [uid248673@id-248673.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:05 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
13:16 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
13:20 < bitcoin-git> [bitcoin] danielabrozzoni opened pull request #32740: refactor: Optimizations & simplifications following #25717 (master...upforgrabs/25968) https://github.com/bitcoin/bitcoin/pull/32740
13:24 -!- dyscope [~dyscope@91.218.89.24] has quit [Quit: Leaving]
13:26 -!- Guest22 [~Guest22@199.19.145.27] has joined #bitcoin-core-dev
13:28 -!- Guest22 [~Guest22@199.19.145.27] has quit [Client Quit]
13:54 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 260 seconds]
13:56 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
14:05 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
14:19 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
14:51 < bitcoin-git> [bitcoin] waketraindev opened pull request #32741: rpc: add optional nodeid param to filter getpeerinfo (master...2025-06-getpeerinfo-filterid) https://github.com/bitcoin/bitcoin/pull/32741
14:56 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has quit [Remote host closed the connection]
15:01 -!- kevkevin [~kevkevin@2607:fb90:9b24:d22b:e9da:8ef6:2374:2a08] has joined #bitcoin-core-dev
15:07 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
15:21 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
15:23 -!- kevkevin [~kevkevin@2607:fb90:9b24:d22b:e9da:8ef6:2374:2a08] has quit [Remote host closed the connection]
15:53 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
15:54 -!- kevkevin [~kevkevin@2607:fb90:9b24:d22b:e9da:8ef6:2374:2a08] has joined #bitcoin-core-dev
15:54 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
16:01 < bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/5757de4ddd37...19765dca197a
16:01 < bitcoin-git> bitcoin/master 331a25c furszy: test: indexes, avoid creating threads when sync runs synchronously
16:01 < bitcoin-git> bitcoin/master 0a24870 Ryan Ofsky: indexes, refactor: Stop requiring CBlockIndex type to call IsBIP30Unspenda...
16:01 < bitcoin-git> bitcoin/master 6f1392c Ryan Ofsky: indexes, refactor: Remove remaining CBlockIndex* uses in index Rewind meth...
16:01 < bitcoin-git> [bitcoin] achow101 merged pull request #32694: index: move disk read lookups to base class (master...2025_indexes_remove_CBlockIndex_access) https://github.com/bitcoin/bitcoin/pull/32694
16:12 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
16:38 -!- hernanmarino [~hernanmar@2800:2330:2800:14a:2ac5:5534:eadb:be0e] has joined #bitcoin-core-dev
16:44 -!- hernanmarino [~hernanmar@2800:2330:2800:14a:2ac5:5534:eadb:be0e] has quit [Ping timeout: 268 seconds]
16:47 -!- hernanmarino [~hernanmar@181.85.47.153] has joined #bitcoin-core-dev
17:01 -!- Guest36 [~Guest36@2601:246:5682:66b0:79e2:cfb7:ae70:5627] has joined #bitcoin-core-dev
17:02 -!- Guest36 [~Guest36@2601:246:5682:66b0:79e2:cfb7:ae70:5627] has left #bitcoin-core-dev []
17:04 -!- jespada [~jespada@r179-25-148-209.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 252 seconds]
17:07 < bitcoin-git> [bitcoin] theStack opened pull request #32742: test: fix catchup loop in outbound eviction functional test (master...202506-test-complete-catchup-loop-in-p2p_outbound_eviction) https://github.com/bitcoin/bitcoin/pull/32742
17:29 -!- dyscope [~dyscope@91.218.89.24] has joined #bitcoin-core-dev
17:43 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
17:45 -!- wafflefrie [uid478376@id-478376.uxbridge.irccloud.com] has joined #bitcoin-core-dev
17:48 -!- kevkevin [~kevkevin@2607:fb90:9b24:d22b:e9da:8ef6:2374:2a08] has quit [Remote host closed the connection]
18:01 -!- dyscope [~dyscope@91.218.89.24] has quit [Quit: Leaving]
18:39 -!- kevkevin [~kevkevin@2603:300a:2305:c000:49f9:b4a8:89:98eb] has joined #bitcoin-core-dev
18:44 -!- kevkevin [~kevkevin@2603:300a:2305:c000:49f9:b4a8:89:98eb] has quit [Ping timeout: 260 seconds]
19:42 -!- TallTim_ [~talltim@24.124.35.28] has joined #bitcoin-core-dev
19:43 -!- TallTim [~talltim@24-124-35-28-dynamic.midco.net] has quit [Ping timeout: 244 seconds]
19:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:50 -!- wafflefrie [uid478376@id-478376.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
19:52 -!- VonNaturAustreVe [~natur@2804:14c:65d7:8e6c:7541:3e0a:2a42:b855] has joined #bitcoin-core-dev
19:52 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has changed host
19:53 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has quit [Read error: Connection reset by peer]
20:54 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
20:58 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:13 -!- rszarka [~szarka@2603:3003:4eac:100:809b:95db:6a31:3] has joined #bitcoin-core-dev
21:16 -!- robszarka [~szarka@2603:3003:4eac:100:3c4d:a401:db8b:2324] has quit [Ping timeout: 260 seconds]
21:23 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
21:54 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
22:04 -!- trev [~trev@user/trev] has left #bitcoin-core-dev [ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)]
22:04 < bitcoin-git> [bitcoin] romanz opened pull request #32743: chore: use `std::vectorstd::byte` for `BlockManager::ReadRawBlock()` (master...read-raw-bytes) https://github.com/bitcoin/bitcoin/pull/32743
22:37 < bitcoin-git> [bitcoin] maflcko closed pull request #32685: wallet: Allow read-only database access for info and dump commands (master...wallet-readonly-access) https://github.com/bitcoin/bitcoin/pull/32685
22:37 < bitcoin-git> [bitcoin] maflcko reopened pull request #32685: wallet: Allow read-only database access for info and dump commands (master...wallet-readonly-access) https://github.com/bitcoin/bitcoin/pull/32685
23:10 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has joined #bitcoin-core-dev
23:10 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:353f:ec3a:a049:af38] has quit [Client Quit]
--- Log closed Fri Jun 13 00:00:11 2025