<l0rinc>
and the good news is that I have benchmarked bitcoindev1337's idea to prefetch blocks before connection and it does show a significant speedup, more than my 5% estimation, so it's worth a deeper investigation!
<l0rinc>
bitcoindev1337 do you want to push something or do you want us to do it? If the latter, what's your github username to add you as coauthor?
<l0rinc>
that's it from me
<fjahr>
#topic QML GUI WG Update (johnny9dev)
<johnny9dev>
We got a ton of feedback last week on the preview and have started working on those issues. The project board will continue to the be place where we track the work.
<johnny9dev>
We currently have about 80 issues we want to complete before starting our PR and about 20 that we think need to have complete before it is releasable.
<johnny9dev>
I think the feedback/impressions i got on the current staging branch were all i needed to decide to change course. I am now working on just taking the best version of what we have and building up the application in stages. This will include introducing all of our testing frameworks right from the start. The different stages will be very similar to our current git history on the project
<johnny9dev>
1. Introduce the build and main 2.add first node lifecycle and model. 3. add onboarding, settings, and node running features 4. add desktop wallet creation 5. add send/activity/receive .... with he last few stages will be adding feature pages to the app.
l0rinc has quit [Quit: l0rinc]
<johnny9dev>
this should make cleaner history and easier to review. I will make an effort to attribute each commit with all contributors involved
<johnny9dev>
When I get closer I think I will create an issue in bitcoin/bitcoin with the plan and include tracking all of the steps we need to complete and look to start the PR for the first chunk.
<johnny9dev>
thats all for this week
Murch[m] has quit [Changing host]
Murch[m] has joined #bitcoin-core-dev
<fjahr>
#topic QA WG Update (brunoerg)
<brunoerg>
Hi, published at https://bitcoincore.space the latest analysis for src/psbt.cpp and src/private_broadcast.cpp. Also, spent some time filtering the survived mutants for src/script/interpreter.cpp, so the surviving ones may be most of interesting ones to be addressed. That's all, thanks.
<fjahr>
That's it for the WGs
<fjahr>
#topic Compiler diversity: to drop MSVC or keep it? (hebasto)
<hebasto>
hi
<hebasto>
On Windows, as on most other systems, there is more than one compiler that can be used to build Bitcoin Core.
<hebasto>
Clang provides the clang-cl.exe tool, which is compatible with MSVC's cl.exe. The latter point is important when it comes to a shared libbitcoinkernel.dll.
<hebasto>
While it's possible to use clang-cl.exe now, #31507 improves the build experience and makes Clang support first-class on Windows.
<hebasto>
At some point, reviewers suggested that support for MSVC, which produces inferior binaries, could be dropped entirely.
<hebasto>
Dropping MSVC support has many benefits, but the drawback is that it reduces the diversity of compilers testing the Bitcoin Core codebase, which was noted by cfields during the last CoreDev.
<hebasto>
Here is the question for today's meeting:
<hebasto>
Do we want to keep MSVC as a supported compiler?
<purpleKarrot>
Should this be a vote?
<cfields>
I think that depends on the meaning of "support".
<emzy>
hi
<fanquake>
I think this also came up because #31507 (which drops it) was tagged for 32, but there are other PRs like #24773 open, which add more MSVC specific code
<purpleKarrot>
By support I understand having a requirement that the code builds and tests run successfully when using MSVC as the compiler. Everything else (workaround for bugs, etc) are downstream from that requirement.
<cfields>
I think it'd be a shame to stop building/testing against non-(gcc|clang). I think "should we avoid pessimizing because MSVC doesn't support X" is a different question.
<hebasto>
note that clang-cl still uses MS's standard library
<sedited>
hi
<fanquake>
We also don't want to end up in any one of these "nightly" support loops, where no real CI is run, and we have to continue to re-factor/change code to support something after the fact
<fanquake>
(similar to what we've seen with all the BSDs lately)
<hebasto>
fanquake: we can keep a MSVC ci job in the main repo though
<dzxzg>
if a MSVC ci job was kept in the main repo what would be changing about our support for MSVC
<cfields>
hebasto: could you describe exactly what you mean by dropping support, then? Explicitly allowing MSVC builds to fail? Ripping out the MSVC ifdefs?
<cfields>
Asking because as-of-now, release builds are mingw. So strictly as far as users are concerned, MSVC is "unsupported".
<hebasto>
yes, it's not related to release binaries
<hebasto>
but we support building from source on Windows
<cfields>
I still think it'd be a shame to lose that diversit. But that's easy to say as someone who doesn't do any work to keep msvc compiling.
<cfields>
*diversity
<hebasto>
fanquake: do you agree to keep the current msvc support?
<cfields>
Perhaps there's a middle-ground keeping some subset of builds working? kernel? bitcoind?
<fanquake>
I don't mind that much. As mentioned, this doesn't meaningfully change our release binaries, but that was also a reason to push back, because 31507 is adding support for clang, awhich dds *another* way to compile for windows (new ci jobs, more build complexity etc), without actually improving anything we ship
<hebasto>
well, clang-cl produces much better binaries for people who prefer build from source on Windows
<sedited>
it would be the only platform where we support targeting it with three different toolchains.
<fanquake>
basically, if the motivation to use clang, was to avoid all the MSVC compiler bugs/ICE, then we are we continuing to keep supporting/testing it, with all the baggage
<fanquake>
*why are we
<fanquake>
Especially given off all the compilers we use, it's the only one we can't actually fix
<fanquake>
(can't submit patches upstream, microsoft forum for supporting bugs close to useless etc)
sr_gi has joined #bitcoin-core-dev
<purpleKarrot>
We should not mix two different topic. We want to build release binaries with the compiler that produces the best binaries. And we want a diverse test setup to find issues in the code.
<cfields>
sedited: good point. And with the fewest eyeballs.
<fanquake>
purpleKarrot: the only issues we've found with MSVC so far, as bugs in the compiler, as far as I'm aware
<fanquake>
Not sure what the "best" compiler is for building releases, but it needs to be an open source one
<cfields>
fanquake: yeah, ok, I withdraw my objection. I suppose it's philosophical without much grounding in reality these days. It may be diverse, but it's also shitty :p
<dzxzg>
+1, although having compiler diversity is nice, MSVC is by far the most opaque when issues arise, it is hard to weigh an uncertain but possible benefit that MSVC might catch something that otherwise would have gone unnoticed against the real and constant maintenance cost
<sipa>
(only half following, am travelling) I think it makes sense to have two different levels of "support", (1) whatever our published release binaries use and (2) systems/platforms where we think people should ve able to build for, but without testing guarantees. For example, I think some BSDs fall in the second category.
Guest86 has joined #bitcoin-core-dev
Guest86 has quit [Client Quit]
<sipa>
And (2) is great to help for testing diversity too, but doesn't need specifically optimizing for
<fanquake>
sipa: sure, but that maintains the loop of merging, and having to continually re-factor/fix code
<fanquake>
where breakage is reported after the fact
<fanquake>
wasting reviewer time, and creating churn
<fanquake>
Maybe that is fine, and the build can just remain broken on those platforms/in the cis, until people want to circle back to it
<jonatack>
hi
<janb84>
If it does not provide new code issue/insight abd only compiler issues/bugs that need workarounds, i do not see what it brings us
<hebasto>
cfields: did I get it correctly that you are no longer against dropping msvc support?
<fanquake>
(maybe we should just have more jobs in the CI in the repo)
<sipa>
fanquake: or we can choose to treat MSVC as not even falling under (2) ?
<sipa>
there can even more fine-grained levels i guess, e.g. a "no CI for this config, but we accept patches to fix for"
<hebasto>
^^ this seems reasonable
<cfields>
hebasto: not on the grounds of benefiting from diversity, at least.
<lightlike>
do we know if we have users/devs who build with msvc (and tend complain if something breaks), or is it just CI?
<stickies-v>
accepting patches but not running in ci seems like the worst of both worlds to me tbh
<dzxzg>
lightlike: we have some since it's currently the only supported windows build system, but I imagine we would have close to 0 after clang-cl support is merged and is used in the build instructions
<hebasto>
lightlike: I build from source on Windows, but prefer clang-cl
<sedited>
yeah, msvc patches are already getting close to no review. Not having it in CI will probably drop that to zero.
<cfields>
dzxzg: hmm? Not the only one for Windows.
<dzxzg>
*native windows not WSL or cross-compiling
<sipa>
stickies-v: i think that is the reality for e.g. FreeBSD, or has been in the past at leasr; i'm more trying classifying thr current reality than suggesting a policy
<fjahr>
Let's tie this topic up in the next 2-3 minutes and possibly continue after the meeting
<stickies-v>
if it's not helping us catch a lot of bugs, it's not used much, and it's a closed source and painful toolchain to use, fully dropping support seems sensible to me, but i'm not really involved with it so happy either way if ppl want to support it
<hebasto>
could end up keep support for both msvc and clnag-cl for a single release cycle and decide later?
<hebasto>
* clang-cl
<sipa>
m
<cfields>
stickies-v: +1. I think I'm onboard with that opinion now. It'd be different if it were open and we could improve it. But thinking towards a future where we (for ex) migrate to c++26, it's hard to imagine supporting MSVC doing anything for us but slowing us down.
<fjahr>
sedited: Did you still want to give a kernel update?
<sedited>
not today
<hebasto>
so let's drop msvc support
<sedited>
ack
<janb84>
ack
<bitcoin-git>
[bitcoin] laxmanacharya8 opened pull request #35964: fuzz: add coverage for GetQueryParameterFromUri (master...fuzz-query-parameter) https://github.com/bitcoin/bitcoin/pull/35964
<stickies-v>
maybe open an issue for it?
<cfields>
hebasto: how about opening an issue with a concrete proposal and we can resume discussing there?
<hebasto>
will do
<cfields>
It's still unclear to me exactly how much you propose we drop. For ex, ripping out everything from CMake would mean that no one could even _try_ to build it anymore.
<fjahr>
Sorry, let me squeeze in my lil topic and continue discussion in the issue :)
<fjahr>
#topic Kartograf 0.5.0 (fjahr)
<fjahr>
Hi, we have a new release for kartograf, v0.5.0. The big headline is that there are two bugfixes that are breaking reproducible results so with this new version you are not able reproduce the maps that were created with an older version of kartograf and included in the asmap-data repository. For this reason I am proposing to add a note on that in the asmap-data repo to make users aware of this:
<fjahr>
Some more info for people to understand the impact: The two bugfixes are 1. https://github.com/asmap/kartograf/pull/145 A bug in the merge code prevented shorter prefixes from being merged when longer prefixes where already present in the higher priority input of the map. This means the results after the fix with the same inputs have more entries and larger coverage but the new coverage appears to be mostly unutilised address space
<fjahr>
included in IRR DBs, so the real impact is for our purpose appears to be small. On the last 5 historical maps, the impact to the bitcoin network is that 3-4 peers which previously did not have a mapping do have one with the new map. See a more detailed analysis by Joris here: https://gist.github.com/jorisstrakeljahn/30235e943db90f78fecb9e397ffee9c5
<fjahr>
2. https://github.com/asmap/kartograf/pull/148 The IRR DBs we were downloading have inconsistent formatting and since we expected them to always end with an empty line, sometimes the very last entry was skipped when that was not the case. This only resulted in in a single additional prefix mapping (if any) in the final file in the recent runs and bitcoin nodes mappings were not affected by it.
<fjahr>
Also, I previously stated that I don’t think releases make sense for us because participants usually just use master anyway but in this case it makes communication a lot easier so I guess we aren’t moving away from it for now.
<fjahr>
Happy to hear feedback on this. Of course we did some additional (AI assisted) review of the code base to ensure we aren’t leaving any other breaking changes we would want on the table that we could bundle with this. But we couldn’t find anything else.
<fjahr>
And sorry for dumping a wall of text but the kartograf repo doesn't get so many eyes so I rather put it here directly.
<sipa>
do we expect more agreement on the kartograf output with these changes?
<sipa>
(among participants all running 0.5.0)
<fjahr>
Afaict that should be unrelated, the disagreement typically come from rpki which these changes don't have impact on
<sipa>
ok
<fjahr>
We still don't know where the recent rise in mismatches comes from exactly but the last one was better so the smaller changes in the downloading steps we made might have helped
<fjahr>
Last one was 7/10 matches
<sipa>
nice
<fjahr>
"My code doesn't work, I have no idea why; My code works, I have no idea why"
<fanquake>
Next asmap run likely to be the one included in 32.0 ?
___nick___ has quit [Ping timeout: 264 seconds]
<fjahr>
Yeah, good queue I guess: feature freeze is in 1 week. Any last minute comments on that?
<sipa>
does new asmap data count as a feature? :)
<fanquake>
I think new asmap data is more like chainparams and similar
<fanquake>
So just pre branch off
<fjahr>
Yeah, no, but I forgot about making room for that topic :)
<sipa>
also fyi i'll be back from vacation tomorrow, i hooe to do some reviews for 32 where valuable still
<fjahr>
#endmeeting
<corebot>
fjahr: Meeting ended at 2026-08-13T17:00+0000
<bitcoindev1337>
l0rinc: did you get a chance to benchmark it
jonatack has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
<pinheadmz>
dergoegge that QML GUI fuzzer is sick <3
<l0rinc>
bitcoindev1337: yes, please see a few lines above.
<l0rinc>
I can reproduce the speedup on SSD: good news is you were right and my 5% estimation was wrong - it's almost 30% faster now that the other optimizations have landed. Do you want to push a PR for this or do you want us to take it from here?
rustaceanrob has quit [Quit: rustaceanrob]
<bitcoindev1337>
l0rinc: if you'd like to take it from here that's good with me
<bitcoindev1337>
the ai code is obviously... kinda weird
<l0rinc>
thank you for the suggestion, it's the perfect time after the parallel fetcher landed - can you please give me your github name to add you as coauthor (unless you don't want that, of course, in which case I'll just refer to you as bitcoindev1337)
<bitcoindev1337>
i'd rather just be bitcoindev1337 thank you though
sliv3r__ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
sliv3r__- has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] rustaceanrob opened pull request #35965: refactor: test: Add debug output for Coin in coins_tests (master...coins-tests-eq) https://github.com/bitcoin/bitcoin/pull/35965
purpleKarrot has quit [Quit: purpleKarrot]
<bitcoindev1337>
i was inspired to look by the prevout fetcher
<bitcoindev1337>
l0rinc good luck and goodbye
bitcoindev1337 has quit [Quit: Client closed]
satsfy has joined #bitcoin-core-dev
enochazariah_ has quit [Quit: Connection closed for inactivity]
<_aj_>
darosior: it appears that i've claimed a couple of testnet4 blocks via my bitaxe and your pool fwiw; all at difficulty 1. (and a whole bunch of other blocks that didn't make it into the chain)
bugs_ has quit [Quit: Leaving]
janb84 has quit [Read error: Connection reset by peer]