16:00:01 <fjahr> #startmeeting 
16:00:01 <corebot> fjahr: Meeting started at 2026-03-26T16:00+0000
16:00:02 <corebot> fjahr: Current chairs: fjahr
16:00:03 <corebot> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:04 <corebot> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:05 <corebot> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:08 <janb84_> hi
16:00:10 <johnny9dev> hi
16:00:10 <fjahr> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack TheCharlatan vasild
16:00:10 <fjahr> willcl-ark
16:00:12 <pinheadmz> yo
16:00:14 <vasild> hi
16:00:15 <cfields> hi
16:00:20 <brunoerg> hi
16:00:20 <dzxzgthree> hi hi hi
16:00:25 <lightlike> hi
16:00:30 <marcofleon> hi
16:00:33 <andrewtoth_> hi
16:00:37 <Murch[m]> Hi
16:00:39 <sedited> hi
16:00:40 <fjahr> There is one pre-proposed meeting topic this week. Any last minute ones to add?
16:00:42 <abubakarsadiq> hi
16:00:45 <epicleafies> hi
16:01:30 <fjahr> Let's start with the Working Groups
16:01:34 <fjahr> #topic Kernel WG Update (sedited)
16:01:39 <sipa> hi
16:02:09 <furszy> hi
16:02:11 <sedited> no updates from me this week, and am going afk for the next three weeks.
16:02:39 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:02:53 <andrewtoth_> nothing from me this week
16:03:19 <kanzure> hi
16:03:22 <fjahr> #topic Net Split WG Update (cfields)
16:03:37 <cfields> Finally some progress! I have a branch which cleans up all of the local address handling which is currently just a bunch of global functions used all over the place (GetLocal(), AddLocal(), etc). Ultimately they are all used for GetLocalAddrForPeer().
16:03:44 <cfields> My first step has been just to remove the dependencies on CNode and move all of the functions into a new LocalAddressManager. For now, it's instantiated as a static global. Functionally there's no change but it's now 10x easier to understand how it all works and test. The next step will be to actually instantiate it and store it in node.
16:03:50 <cfields> While working on it, I discovered a few nasty leaks that should potentially be fixed. I'm working on testing and documenting so that I can propose some fixes and behavioral changes.
16:03:54 <cfields> Both streams (refactor and fixes) could potentially happen in parallel, but imo it's _much_ easier to understand what's going on and test after refactoring to a sane manager class. So I'll probably PR that work first.
16:05:38 <fjahr> Cool, anything else on net split?
16:06:08 <cfields> Nope, that's it for now.
16:06:18 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:07:14 <johnny9dev> The decoupling of qml from the qt widgets gui is done. A part of that also included the last piece of automated test tools for the project. Specifically gmock for mocking the wallet and node interfaces
16:07:27 <eugenesiegel> hi
16:07:37 <johnny9dev> so the project now has comprehensive testing. unittests, qml tests, and end to end gui tests
16:08:33 <johnny9dev> Feature wise wallet import/restore was merged and a pr for wallet migration is up and this week i did all of the features for fee setting. Those will be PR'd the next couple of days
16:09:19 <johnny9dev> epicleafies has a bunch of PRs lingering for features he completed so my top priority is to finish reviews of all of those now that the test frameworks are settled and they all no longer have conflicts
16:09:36 <johnny9dev> epicleafies: can you share your status?
16:10:05 <fanquake> gmock as in Google Test / Mock?
16:10:09 <epicleafies> Yeah, this past week I've created PRs for adding desktop tray icon/functionality and the rpc console page
16:10:27 <johnny9dev> yeah thats what I know for mocking. open to swapping it out later but I've always liked it.
16:10:50 <johnny9dev> only using gmock, nothing from gtest
16:11:39 <darosior> hi
16:11:41 <fjahr> seems like that's it for gui?
16:12:14 <johnny9dev> yeah thats it. we'll be PRing a few more features and then i will likely do another assestment to see what the remaining gap is and I will share that
16:12:22 <fjahr> #topic Libevent removal (pinheadmz, fjahr)
16:12:31 <pinheadmz> #32061 has been rebased following great reviews on code style and deeper http protocol. I am running fuzzers on the branch this week and will re-run my integration tests with lnd, electrs, etc as well. The first 7 commits add tests and utilities, and are split off in to two small PRs which are in review, and I'm pushing updates today: #34772 and #34905
16:12:36 <corebot> https://github.com/bitcoin/bitcoin/issues/32061 | Replace libevent with our own HTTP and socket-handling implementation by pinheadmz · Pull Request #32061 · bitcoin/bitcoin · GitHub
16:12:39 <corebot> https://github.com/bitcoin/bitcoin/issues/34772 | test: modernize interface_http and cover more libevent behavior by pinheadmz · Pull Request #34772 · bitcoin/bitcoin · GitHub
16:12:41 <corebot> https://github.com/bitcoin/bitcoin/issues/34905 | Update string and net utils for future HTTP operations by pinheadmz · Pull Request #34905 · bitcoin/bitcoin · GitHub
16:12:51 <fjahr> From my side, I am still getting some good on the torcontrol PR (#34158) and respond to that as quickly as possible. I think it looks to be in pretty good shape by now.
16:12:54 <corebot> https://github.com/bitcoin/bitcoin/issues/34158 | torcontrol: Remove libevent usage by fjahr · Pull Request #34158 · bitcoin/bitcoin · GitHub
16:13:03 <fjahr> *good review
16:13:35 <fjahr> That concludes the WGs unless I missed someone
16:13:42 <fjahr> #topic asmap file format & tooling (sipa)
16:13:45 <sipa> Hi!
16:14:05 <sipa> With the asmap data now built-in to the bitcoin core binary, i had a look at the tooling around it
16:14:37 <sipa> and it's not entirely satisfying i think that the only actual encoder/decoder for the format is a largely untested (and probably barely reviewed) python script
16:15:18 <sipa> we do have a well-tested interpreter inside bitcoin core that can lookup ASNs, but there is no end-to-end testing that the logic we use for creating the files (in python) actually matches what the interpreter reads
16:15:44 <sipa> so what do people think about adding a bitcoin-asmap binary, with a c++ implementation of what is currently in the python script?
16:16:08 <sipa> the code would be able to be covered by testing, but still only the interpreter would end up in bitcoind
16:16:12 <sedited> sgtm
16:16:36 <fanquake> Probably depends where the rest of the tooling ends up?
16:16:53 <fjahr> sounds good to me
16:17:08 <sipa> so this is just about the "ASN mapping to binary" part, and possibly the diffing/etc, it's not about the actual sourcing of the mapping, which is the kartograf project
16:17:13 <fjahr> FWIW, there seemed to be diverse opinions about what should go where so I planned to have that part of the discussion in person
16:17:15 <fanquake> (some discussion in #34842)
16:17:17 <corebot> https://github.com/bitcoin/bitcoin/issues/34842 | contrib: add ASmap attestation scripts by jurraca · Pull Request #34842 · bitcoin/bitcoin · GitHub
16:17:52 <Murch[m]> sipa: Would that be something that you hack up in a few days or a bigger project?
16:17:54 <fjahr> Replacing the encoder/decoder doesn't change the status quo so should be uncontroversial in that regard?
16:18:02 <fanquake> There doesn't seem to be a good split on what should live where, or if asmap = core or not, and who's responsible for maintainig various things
16:18:24 <fanquake> (especially since this is all becomming (potentially) release blocking)
16:18:44 <sipa> Murch[m]: Opus 4.6 converted the python code in one go to C++, produces bit-identical files, and is 10x faster... i'd obviously clean it up myself, but having something that already works is nice
16:19:40 <sipa> with that, another thing i want to bring up... i've been experimenting with replacing the binary file format with some new insights and better compression
16:20:14 <sipa> and have something that can realistically be 20% smaller, while still being interpretable on-the-fly, though the format does get more complex
16:20:48 <sipa> does that sound like a trade-off that's worth looking into?
16:20:57 <cfields> +1
16:20:57 <sipa> i expect it to be equally fast or faster
16:21:19 <fjahr> how much more complex? But 20% sounds great
16:21:48 <sipa> fjahr: the interpreter is probably not that much worse, the encoder is pretty nontrivial
16:21:49 <Murch[m]> Isn’t it pretty small already?
16:22:07 <cfields> sipa: I suppose the format changes could be done in python too? So they don't depend on figuring out the c++ tool first?
16:22:31 <fjahr> yeah, I was going to say the order of these is worth thinking about
16:22:44 <sipa> cfields: i already have it working in c++... this was the actual motivation for me to start looking into it, because the new encoding scheme is significantly more computationally costly, so didn't want to keep doing that in python
16:22:52 <Murch[m]> Or to put it differently, how big is the file?
16:23:06 <cfields> ok, makes sense
16:23:13 <sipa> the current code i have is not nearly production ready... but it's good enough to give me an idea of how much smaller it can get
16:23:25 <sipa> Murch[m]: around 1.6 MiB, and shipped inside our binaries
16:23:48 <fjahr> 1.4 with filling
16:24:00 <sipa> so we might cut down on some 250 KiB in binary size
16:24:04 <fanquake> So about 10% of our releasebinary, maybe more
16:24:37 <Murch[m]> Then I don’t think it makes sense to spend a lot of engineering on making it smaller unless there are other benefits
16:25:11 <sipa> there is the possibility of shipped the data in a separate file that needs to be installed in some discoverable location, rather than inside the binary
16:25:49 <sipa> i think there are convenience arguments against that, but if installer size is a concern, that's a much more significant improvement
16:25:50 <Murch[m]> Right, but anyone running it will immediately download hundreds of gigabytes of data and store at least several. In that context, does it matter much?
16:25:55 <Murch[m]> Maybe I’m missing something here
16:26:16 <furszy> Murch[m]: math is fun
16:26:54 <Murch[m]> Yeah, sure. Just trying to understand the cost-benefit heer
16:26:54 <sipa> Murch[m]: that's a good point yes - i feel our binaries are big, but looking at the blockchain size does put it all in perspective
16:26:58 <Murch[m]> s/heer/here/
16:27:43 <sipa> well i think i'll start with c++ifying with the current format
16:27:58 <sipa> based on the discussion here
16:28:05 <fjahr> Murch: valid point, but i am still very interested in seeing what we can get
16:28:16 <Murch[m]> Not trying to tell sipa what to do, but I’m not sure spending several weeks to optim
16:28:23 <sipa> Murch[m]: too late
16:28:35 <fjahr> sipa: better testing is a very good argument for that
16:28:38 <Murch[m]> s/optim/shave a MB off of that file is the biggest bang for the buck ^^/
16:29:44 <darosior> I'm not sure how relevant is the comparison between binary size and block chain size. But the point probably holds for our RAM usage defaults anyways.
16:30:18 <sipa> it's 3 weeks worth of block headers worth of RAM that this may save :)
16:30:30 <sipa> which is probably not relevant
16:30:31 <darosior> Unless we start having one dbcache defaults per piece of hardware ever manufactured :p
16:30:36 <darosior> hids
16:30:37 <cfields> which in 2026 is $10k...
16:30:40 <darosior> sipa: right
16:30:40 <sipa> cfields: :D
16:31:05 <Murch[m]> Also, I think we’re getting a bit lost in details here
16:31:12 <sipa> agreed
16:31:28 <sipa> that's it for me, unless people want to discuss other asmap related things
16:31:31 <cfields> sipa: presumably it's irrelevant for runtime ram once loaded though? Or is this representation persistent in memory?
16:31:58 <sipa> cfields: the cool thing about this format is that it's interpretable without decompression
16:32:14 <sipa> so it's literally just a blob built-in to the binary, and directly interpreted there
16:32:38 <cfields> oh, neat.
16:33:18 <fjahr> Anything else to discuss?
16:33:30 <hodlinator> hi
16:34:09 <fjahr> Quick shill for #34636 since optimizing RAM was mentioned. A lot of room for improving the index allocation there.
16:34:10 <corebot> https://github.com/bitcoin/bitcoin/issues/34636 | node: allocate index caches proportional to usage patterns by svanstaa · Pull Request #34636 · bitcoin/bitcoin · GitHub
16:34:22 <fjahr> (IMO)
16:35:11 <dzxzgthree> I also want to shill for input on this question from last week's irc meeting: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-03-19#1204579;
16:35:12 <corebot> dzxzgthree: Error: That URL raised <HTTP Error 404: Not Found>
16:35:38 <dzxzgthree> "As a -blocksonly node, should we immediately drop the compact block (since we did not send sendcmpct to our peer) or should we process the header if we receive the compact block?"
16:35:49 <dzxzgthree> more discussion here: https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2886012883
16:36:38 <sipa> darosior: hmm, good question
16:36:53 <sipa> eh, dzxzgthree
16:38:10 <fjahr> Ok, I guess please follow up at the discussion linked
16:38:14 <fjahr> #endmeeting