16:00:12 <stickies-v> #startmeeting 
16:00:12 <corebot> stickies-v: Meeting started at 2025-12-18T16:00+0000
16:00:13 <corebot> stickies-v: Current chairs: stickies-v
16:00:14 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:15 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:15 <Novo> hi
16:00:16 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:22 <dzxzg> hi
16:00:24 <hebasto> hi
16:00:27 <sedited> hi
16:00:27 <eugenesiegel> hi
16:00:28 <fjahr> hi
16:00:31 <Novo> #here 
16:00:31 <brunoerg> hi
16:00:34 <dergoegge> hi
16:00:34 <stringintech> hi
16:00:34 <hodlinator> hi
16:00:36 <yancy> #here 
16:00:37 <stickies-v> #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 sr_gi tdb3 theStack TheCharlatan vasild
16:00:37 <stickies-v> willcl-ark
16:00:38 <pinheadmz> hi
16:00:47 <janb84> hi
16:01:01 <lightlike> hi
16:01:05 <stickies-v> There are two pre-proposed meeting topics this week. Any last minute ones to add?
16:01:08 <marcofleon> hi
16:01:29 <furszy> hi
16:01:46 <stickies-v> let's get started with the working group updates
16:01:48 <kevkevin> hi
16:01:49 <stickies-v> #topic Fuzzing WG Update (dergoegge)
16:01:57 <abubakarsadiq> hi
16:02:25 <dergoegge> There are a bunch of updates on fuzzamoto, I made some notes here: https://gist.github.com/dergoegge/056f94f9bbff726993ee376872547ecb
16:02:25 <dergoegge> Maybe the most relevant to you all, is that hopefully soon you can write fuzzamoto tests using the functional test framework
16:02:55 <dergoegge> That's probably it, unless someone else also has updates on something fuzzing related
16:03:15 <cfields> hi
16:03:18 <l0rinc_> hi
16:03:27 <instagibbs> v nice
16:03:42 <stickies-v> "will enbale fuzzing pretty much anything " :rocket
16:05:04 <stickies-v> #topic Kernel WG Update (sedited)
16:05:10 <jonatack> hi
16:05:12 <sedited> stickies-v has been working on a spec for a kernel logger: https://github.com/bitcoin/bitcoin/issues/34062 .
16:05:38 <sedited> His most recent approach for that splits the existing logger into a new util::log that implements string formatting and the existing higher level functions for buffering, writing to file, etc.
16:05:53 <sedited> We've also been discussing a new non-locking chain data structure as a replacement/extension of CChain that uses copy-on-write. The end goal is to have a chain that does not require locking to read.
16:06:04 <sedited> A similar approach could be taken for the block tree map too.
16:06:55 <sedited> Also been experimenting a bit with introducing more kernel header api-based utilities to better dog food it.
16:07:05 <l0rinc_> is it a logarithmic COW?
16:07:13 <l0rinc_> (never thought I'll write this sentence)
16:07:20 <b10c> hi
16:07:29 <sedited> l0rinc_ something like that is the aim
16:07:44 <l0rinc_> Let me know if I can help with that
16:08:14 <sedited> that's all :)
16:08:21 <stickies-v> sedited: are any of those utilities public already?
16:09:50 <vasild> hi
16:10:04 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:10:08 <l0rinc_> I'm mentioning PRs that are tangentially related to benchmarking and IBD performance to help with their visibility (not necessarily because I was involved).
16:10:09 <sedited> stickies-v, they are, but not quite in a state where I want to PR them yet.
16:10:19 <l0rinc_> Raimo pushed #34044 which was meant to speed up `-reindex` a bit, but based on the usage it turned out to be a dead end.
16:10:21 <corebot> https://github.com/bitcoin/bitcoin/issues/34044 | streams: replace `std::find` with `memchr` (5x improvement) by Raimo33 · Pull Request #34044 · bitcoin/bitcoin · GitHub
16:10:30 <l0rinc_> Cory opened #34083 - a vectorized ChaCha implementation, resulting in 2-3x speedup - no IBD benchmarks yet.
16:10:33 <corebot> https://github.com/bitcoin/bitcoin/issues/34083 | Add initial vectorized chacha20 implementation for 2-3x speedup by theuni · Pull Request #34083 · bitcoin/bitcoin · GitHub
16:10:42 <l0rinc_> Rob experimented with different ways to store the hints for #34004 and addressed a few review concerns.
16:10:45 <corebot> https://github.com/bitcoin/bitcoin/issues/34004 | Implementation of SwiftSync by rustaceanrob · Pull Request #34004 · bitcoin/bitcoin · GitHub
16:10:55 <l0rinc_> (corebot is working today :D)
16:11:00 <l0rinc_> #32414 was merged recently, so reindex-chainstate benchmarks will behave slightly different now - especially for bigger dbcaches.
16:11:04 <corebot> https://github.com/bitcoin/bitcoin/issues/32414 | validation: periodically flush dbcache during reindex-chainstate by andrewtoth · Pull Request #32414 · bitcoin/bitcoin · GitHub
16:11:13 <l0rinc_> Most of our low-end benchmarking servers were offline this week for maintenance, but on the remaining ones we have experimented with:
16:11:20 <l0rinc_> * benchmarking #31132 in a cloud environment with network-connected storage;
16:11:24 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads >40% faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:11:30 <l0rinc_> * since we need a lot less memory now for the same performance after #31132, we tried to see how a sorted map would perform instead of SipHashed std::unordered_map - it would be 26-60% slower;
16:11:35 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads >40% faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:11:39 <l0rinc_> * we tried turning off cache reallocation during IBD flushes - seems to result in ~4% speedup;
16:11:47 <l0rinc_> * wanted to see whether the speedup introduced by pooled allocation is still relevant - removing it would still slow validation by 8-12%; next step is to see if we can fine-tune it instead;
16:11:55 <l0rinc_> * currently measuring how much difference a SipHash-1-3 would make compared to the current SipHash-2-4;
16:12:01 <l0rinc_> * I have finally rented a Windows benchmarking server, so we might soon see how well it performs there.
16:12:15 <l0rinc_> A few related PRs where reviews would help: #33018, #33680, #33866, #33512
16:12:18 <corebot> https://github.com/bitcoin/bitcoin/issues/33018 | coins: remove SetFresh method from CCoinsCacheEntry by andrewtoth · Pull Request #33018 · bitcoin/bitcoin · GitHub
16:12:19 <corebot> https://github.com/bitcoin/bitcoin/issues/33680 | validation: do not wipe utxo cache for stats/scans/snapshots by l0rinc · Pull Request #33680 · bitcoin/bitcoin · GitHub
16:12:22 <corebot> https://github.com/bitcoin/bitcoin/issues/33866 | refactor: Let CCoinsViewCache::BatchWrite return void by sedited · Pull Request #33866 · bitcoin/bitcoin · GitHub
16:12:24 <corebot> https://github.com/bitcoin/bitcoin/issues/33512 | coins: use number of dirty cache entries in flush warnings/logs by l0rinc · Pull Request #33512 · bitcoin/bitcoin · GitHub
16:12:34 <l0rinc_> Thanks, that's it
16:12:57 <hebasto> Windows benchmarking server is promising
16:13:10 <l0rinc_> we'll see, it started with 1 week of maintenace :p
16:13:19 <l0rinc_> after renting it, couldn't even set it up
16:13:29 <sedited> -_-
16:14:41 <stickies-v> #topic Silent Payments WG Update (Novo)
16:14:49 <Novo> The LabelSet scanning approach for https://github.com/bitcoin-core/secp256k1/pull/1765 is still being tested, theStack has implemented both scanning approaches in python https://github.com/theStack/secp256k1lab/blob/775f74373b30390932e10ab6f9d31db606339987/src/secp256k1lab/bip352.py#L234 to ease review and will publish an alternative branch with
16:14:50 <Novo> the LabelSet scanning approach in the next few days.
16:14:50 <Novo> https://github.com/bitcoin/bips/pull/2055 was opened to limit the number of SP recipients to scan for to `(2^32) - 1` to allow devs set appropriate datatypes in their implementation.
16:14:51 <Novo> I ran some tests on Signet using https://github.com/bitcoin/bitcoin/pull/32966 and an SP light client that runs on mobile. Haven't found any issues yet.
16:14:51 <Novo> There is a proposed sp descriptor in https://groups.google.com/g/bitcoindev/c/bP6ktUyCOJI that introduces two new key types for silent payments ("spscan1q..." and "spspend1q") and looks something like "sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10)".
16:14:52 <Novo> Nymius started https://groups.google.com/g/bitcoindev/c/Kap7NMwzl2k to discuss adding a new field to store SP_TWEAKs for spending SP outputs in PSBTs.
16:16:48 <stickies-v> a lot to dig into, thanks for the overview Novo. I'll give it another minute for people to comment
16:17:11 <Novo> I'll break it up in the future
16:17:24 <furszy> :thumbs_up:
16:17:38 <stickies-v> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:18:54 <stickies-v> #topic Stratum v2 WG Update (sjors)
16:19:02 <instagibbs> (#32545 is the one to review)
16:19:04 <corebot> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
16:20:07 <stickies-v> #topic Net Split WG Update (cfields)
16:20:19 <cfields> I've been distracted by other work, so no update this week. I intend to get back to this full-time in the new year.
16:21:00 <sipa> hi
16:21:30 <stickies-v> alright, that concludes the WG updates. haven't had stratum v2 updates for 3 weeks so I'll archive that for now, Sjors[m]1 let me know when you'd like to start giving updates again
16:21:50 <stickies-v> #topic libevent organization members team needs update (https://github.com/libevent/libevent/issues/1812) (pinheadmz)
16:21:54 <pinheadmz> hi
16:22:02 <stickies-v> (this topic was brought forward from last week's meeting)
16:22:18 <pinheadmz> this libevent issue brought to my attention by darosior
16:22:26 <fjahr> To me this doesn’t really change much. I didn’t expect we would be seeing a 2.2 release before we remove it no matter how long the process takes. Now we might see a 2.2 but won’t want to upgrade to it anyway :p
16:22:27 <darosior> hi
16:22:48 <pinheadmz> they are looking for a new maintainer, which makes sense since the lib hasnt cut a release this decade
16:22:48 <fjahr> Not sure if it had even been worth the effort trying to leverage 2.2 if it came out today even without the new concerns, given the work already going into the httpserver.
16:23:39 <pinheadmz> fjahr agreed just wanted to bring to attention, the risk this deependency poses is ticking up slightly
16:23:47 <pinheadmz> reminder to all there is tracking issue https://github.com/bitcoin/bitcoin/issues/31194
16:24:02 <pinheadmz> and next pr for review is #32061
16:24:04 <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:24:16 <pinheadmz> which i recently refactored to address concerns broughtup at coredev by cfields
16:24:33 <pinheadmz> so now, there is no sockman "lite" or otherwise, httpserver does its own sockets
16:24:42 <cfields> 🙏
16:24:49 <pinheadmz> im rebasing again today to fix conflicts with master then ill run some more benchmarks
16:25:03 <pinheadmz> as well as the integration tests with various RPC consuming libraries like electrs
16:25:17 <pinheadmz> if no Qs, thats all  for me
16:26:32 <darosior> pinheadmz: feel free to hit me up to run the Liana functional test suite on a PR, can give some more assurance re RPC interface
16:27:09 <stickies-v> pinheadmz: might also be worth bringing this up in optech so people are nudged to test this out?
16:27:25 <instagibbs> I'd hit up major LN impls, for instance
16:27:34 <pinheadmz> thanks will do - what ive been doing is forking repos like electrs, forcing my branch into its own functional tests and running that
16:27:49 <darosior> Yeah. Core-Lightning also has a functional test suite we should be able to run with minimal efforts
16:27:59 <pinheadmz> ok!
16:28:03 <darosior> (That consumes a lot of the RPC interface)
16:28:04 <pinheadmz> yeah i have lnd integration test
16:28:07 <darosior> Nice
16:28:34 <pinheadmz> i thought cln just wrapped bitcoin-cli actually?
16:28:44 <darosior> Right
16:28:58 <darosior> But the functional tests also speak to the interface directly :)
16:29:14 <pinheadmz> ok ill check that.
16:29:23 <pinheadmz> example lnd integration test from stale branch: https://github.com/pinheadmz/lnd/pull/1
16:30:03 <darosior> I wonder how Sparrow does its testing
16:30:53 <pinheadmz> +1 another good one to check
16:31:14 <stickies-v> going to move on now to keep meeting momentum but feel free to continue conversation after?
16:31:16 <stickies-v> #topic skip meeting next two weeks (stickies-v)
16:31:42 <Novo> +1 on skipping the next two weeks
16:31:53 <sedited> sgtm
16:31:54 <stickies-v> the next 2 scheduled IRC meetings are on 25th dec (christmas) and 1st jan (new year)
16:31:58 <sipa> sgtm to skip
16:32:04 <dergoegge> +1
16:32:07 <stickies-v> all in favour of skipping both meetings and resume 8th jan?
16:32:07 <hebasto> agreed
16:32:11 <marcofleon> yes
16:32:16 <hodlinator> agreed
16:33:01 <darosior> sgtm
16:33:07 <kevkevin> agreed
16:33:10 <yancy> ack
16:33:13 <furszy> +1
16:33:28 <pinheadmz> 🍾🍾🍾
16:33:30 <Novo> Try not to sound too excited guys
16:33:35 <janb84> ack
16:33:52 <stickies-v> alright, that seems unanimous. see you all again on jan 8th, enjoy the holidays and  looking forward to seeing the progress in 2026!
16:34:01 <stickies-v> #endmeeting