16:00:01 <stickies-v> #startmeeting 
16:00:01 <corebot> stickies-v: Meeting started at 2025-11-06T16:00+0000
16:00:02 <corebot> stickies-v: Current chairs: stickies-v
16:00:03 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:04 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:05 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:07 <purpleKarrot> hi
16:00:11 <janb84> hi
16:00:14 <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:15 <stickies-v> willcl-ark
16:00:16 <hebasto> hi
16:00:18 <TheCharlatan> hi
16:00:26 <laanwj> hi!
16:00:29 <l0rinc> hi
16:00:37 <kevkevin> hi
16:00:48 <glozow> hi
16:00:58 <cfields> hi
16:01:06 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:01:13 <fjahr> hi
16:01:14 <sipa> hi ish
16:01:20 <stringintech> hi
16:01:25 <b10c> hi
16:01:28 <marcofleon> hi
16:01:57 <shiza> hi
16:02:05 <fjahr> all hail the new chair stickies-v ;)
16:02:19 <abubakarsadiq> hi
16:02:33 <cfields> I second the motion to hail stickies-v.
16:02:34 <stickies-v> let's start with the WG updates. i'll be moving on quickly, so please make sure to have your update (or acknowledgement that you're writing something) ready
16:02:51 <stickies-v> #topic Erlay WG Update (sr_gi)
16:02:56 <yancy> hi
16:03:26 <kevkevin> (ﾉ◕ヮ◕)ﾉ hail stickies-v
16:03:37 <stickies-v> #topic Fuzzing WG Update (dergoegge)
16:03:40 <dzxzg> hi
16:04:17 <stickies-v> #topic Kernel WG Update (TheCharlatan)
16:04:19 <dergoegge> no update
16:04:27 <TheCharlatan> #30595 was merged :)
16:04:29 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:04:34 <dzxzg> Woo!
16:04:39 <cfields> 🎉🎉🎉
16:05:00 <dergoegge> 🚀🚀🚀
16:05:03 <stringintech> 🥳
16:05:08 <kevkevin> 🥳
16:05:09 <glozow> 🚀
16:05:23 <stickies-v> feels nice being able to open small pull requests
16:05:33 <fjahr> 👏
16:05:39 <TheCharlatan> feels weird no longer having to checkout that branch anymore :P
16:05:45 <TheCharlatan> There will be a bunch of follow-up PRs as more people start developing against it and find some things either overlooked during the review cycles, or still not sufficiently polished.
16:06:01 <l0rinc> congrats
16:06:06 <TheCharlatan> In the meantime, we should figure out how best to surface documentation for it
16:06:30 <TheCharlatan> Similarly we also had a discussion on where the host the various language bindings. If I am counting correctly, there are now rust, go, java, python, zig, and js bindings in various stages of completion and long-term commitment.
16:06:34 <TheCharlatan> I.e. should these live in bitcoin-core/bindings, bitcoin/bindings, or somewhere else.
16:07:25 <TheCharlatan> didn't really reach a conclusion on that yet, does anybody here have a suggestion?
16:08:44 <laanwj> yes that was awesome. good to get tha tin, congrats!!!
16:09:18 <laanwj> would make sense to make a repository for that under bitcoin-core
16:09:51 <stickies-v> i'll just quickly rehash my point that i think it might be helpful to provide documentation / guidance on how to implement language bindings, but not centralize the actual implementation/distribution to keep the kernel development pace high until we're much more stable
16:10:11 <laanwj> and agree that one repository with all the bindings would be preferable to seperate ones per language
16:11:04 <laanwj> stickies-v: that's a good point too. but people aren't forced to use the central repository, it'll be for the more mature ones at first
16:11:28 <TheCharlatan> I think I agree with stickies-v here, maybe a repo hosting some basic bindings guidance and examples would be a good place to start off of.
16:12:09 <TheCharlatan> Could add a little readme in src/kernel that links to it and can then further link to other bindings under development.
16:12:18 <TheCharlatan> I talked to a few people working on language-specific bitcoin tooling (bitcoinj, rust-bitcoin, btcsuite) and some have voiced support for hosting bindings under their org umbrella. A project even offered nice domain names :P
16:12:21 <laanwj> yes
16:13:28 <TheCharlatan> We also still need to settle on a particular versioning scheme. A suggestion was to treat our internal version as a "product name" and then have a specific versioning scheme for the header.
16:13:36 <laanwj> i'd guess that works for languages that have a very active bitcoin community, like rust, yes
16:13:49 <l0rinc> and java
16:14:20 <TheCharlatan> This versioning approach seemed a bit confusing to some, and would still practically tie bitcoin core versioning with the kernel library.
16:15:09 <TheCharlatan> Maybe for now the best action is to just not bother with it for a while still
16:15:21 <laanwj> there's two seperate versionings here: the interface, and the kernel itself (e.g. what consensus rules). that complicates it a bit
16:15:45 <laanwj> right. it's experimental for now. it wouldn't help to set things in stone too early
16:16:45 <abubakarsadiq> @theCharlatan it will be nice if this ideas are opened in an issue somewhere contributors and users will chime in on which approach is best
16:16:52 <stickies-v> laanwj do we need separate versions for interface and consensus?
16:17:31 <laanwj> stickies-v: not sure. i was only talking conceptually. maybe these can be unified somehow
16:17:34 <TheCharlatan> yes, people might also eventually have other unforeseeable opinions on implementation details, e.g. performance trade offs, and select specific versions outside of the interface.
16:17:55 <TheCharlatan> abubakarsadiq yes, I think an issue for this topic would be good.
16:17:58 <laanwj> but the former would be more stable, the latter would be really "product version"
16:18:25 <stickies-v> TheCharlatan: will you open the issue to discuss this further?
16:18:38 <TheCharlatan> will do.
16:19:05 <TheCharlatan> Another area that will still need work are the tests.
16:19:16 <TheCharlatan> The PR introduced a new test_kernel binary.
16:19:30 <laanwj> i was surprised the tests for the kernel aren't enabled by default when the library is
16:19:44 <TheCharlatan> Currently the tests, header, and implementation glue code are all in one big files. It would be nice to find a better topology for these. Especially the tests should get some more work in that regard.
16:19:53 <TheCharlatan> The tests were initially meant to exercise the API without using our internal code. Some of the test utilities required to do this can now be removed and replaced with our usual test framework code.
16:20:10 <laanwj> agree, that would make sense
16:20:32 <TheCharlatan> People working on the bindings have also been asking for test vectors to test their APIs with.
16:21:13 <purpleKarrot> One topic we may also want to discuss is the naming convention. I find it extremely hard to reason about the all lowercase function names. It is unclear what separates the type from the method name.
16:21:15 <TheCharlatan> We can probably create a separate test data json file, similar to the ones we already use in the unit tests.
16:21:20 <laanwj> yes it's a very critical API, so focus on testing, also cross-language would be good
16:21:46 <laanwj> yes!
16:22:41 <TheCharlatan> yes, purpleKarrot had suggested a naming in his own experimental api. I think it makes sense, but it does break convention with other C APIs under the bitcoin-core umbrella, e.g. minisketch and libsecp256k1.
16:22:47 <laanwj> purpleKarrot: naming is important but also has a tendency to distract, because people tend to have strong differing opinions on it. but sure, creating an issue to discuss that makes sense
16:22:59 <vasild> hi
16:23:36 <purpleKarrot> If a convention makes code hard to reason about, it is time to rethink the convention.
16:24:14 <laanwj> sure
16:25:04 <TheCharlatan> At the current stage I think it would even be fairly straight forward to do a rename in a single big scripted-diff. Maybe prepare a PR for the change you had in mind, and we discuss it on there purpleKarrot?
16:25:29 <purpleKarrot> sounds good.
16:25:38 <TheCharlatan> We've also been working towards doing a beta release of the rust bindings. Among other things, we've started our own qa_assets repo for our own fuzz tests.
16:26:36 <TheCharlatan> fuzzing the interface has proved fruitful early on - it revealed some constraints deeper in our consensus code that we probably would have not detected without them.
16:26:51 <stickies-v> https://github.com/alexanderwiederin/qa-assets
16:26:55 <hodlinator> hi, and congrats TheCharlatan
16:27:01 <TheCharlatan> thanks stickies-v :)
16:28:10 <stickies-v> want to make sure we leave enough time for other WG's - i suggest we move on, lmk if you have more to discuss TheCharlatan and then we can come back to it at then end
16:28:28 <stickies-v> #topic Benchmarking WG Update (l0rinc)
16:28:38 <l0rinc> For #31132 we've simplified the multithreaded `InputFetcher` to collect directly to the temporary cache to avoid modifying the main dbcache in case of an invalid block.
16:28:39 <TheCharlatan> I'm at the end anyway, thanks :)
16:28:42 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads >20% faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:28:50 <l0rinc> Since we don't fail on missing entries anymore (it's not the cache-warmer's job to validate), we can safely filter intra-block spends based on short-ids instead of full txids - we don't even need to use `SipHash` this way since we're just relying on sorted vector binary search for presence checks which the benchmarks indicate are several times faster.
16:28:59 <l0rinc> All of these resulted in a nice speedups, on some systems up to 30% faster reindex-chainstate (see https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3479640421 for details)
16:29:03 <laanwj> "fuzzing the interface has proved fruitful early on - it revealed some constraints deeper in our consensus code that we probably would have not detected without them."  glad to see this is already finding bugs that aren't in the API code itself :)
16:29:05 <l0rinc> Local benchmarks also revealed that we may have some memory leaks in the code, see: #33806 (will investigate)
16:29:06 <corebot> https://github.com/bitcoin/bitcoin/issues/33806 | malloc: Failed to allocate segment from range group - out of space · Issue #33806 · bitcoin/bitcoin · GitHub
16:29:53 <l0rinc> and we're writing an article for Bitcoin magazine about our benchmarking and optimization efforts
16:29:57 <laanwj> nice!
16:30:55 <l0rinc> thanks, that's it
16:30:56 <laanwj> 30% speed-up on reindex is very impressive
16:30:58 <stickies-v> more speedups ahead in v31 it seems, thank you l0rinc. looking forward to reading the article, keep us posted?
16:31:08 <l0rinc> sure
16:31:14 <stickies-v> #topic Silent Payments WG Update (Novo__)
16:31:17 <abubakarsadiq> From novo__: Hi I won't be available for the irc meeting. This is the update for SIlent Payments; josibake is off for now, so I and theStack will be taking over the PRs. A new silentpayments secp module PR has been opened by theStack https://github.com/bitcoin-core/secp256k1/pull/1765 (limited to full-node scanning to make it easier to merge). We will update https://github.com/bitcoin/bitcoin/pull/28122
16:31:17 <abubakarsadiq> https://github.com/bitcoin/bitcoin/pull/28201 and https://github.com/bitcoin/bitcoin/pull/32966 as needed.
16:32:14 <stickies-v> thanks for passing it on abubakarsadiq
16:32:18 <stickies-v> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:32:44 <glozow> Just in case sipa is offline - #33629 is the PR to review. We're hoping to do a review "sprint" next week and would love to recruit anybody who has spare hands
16:32:48 <corebot> https://github.com/bitcoin/bitcoin/issues/33629 | Cluster mempool by sdaftuar · Pull Request #33629 · bitcoin/bitcoin · GitHub
16:33:08 <glozow> I put together a list of ideas for reviewing, particularly for those who are less familiar with all the code areas: https://github.com/glozow/bitcoin/issues/13
16:33:28 <abubakarsadiq> nice count me in 👍
16:33:39 <glozow> Perhaps we can use this channel or #bitcoin-core-pr-reviews as a helpdesk for it next week. Please please do join in :)
16:33:43 <sipa> hi, what glozow said
16:34:24 <stickies-v> will there be pizza for the sprint?
16:34:33 <glozow> As the PR gets to a stage where all pushes are minor edits, we can take the approach of getting it in master early in the release cycle, with the expectation that it will get more testing this way, and there will be followups
16:34:58 <glozow> I am very happy to get a pizza delivered to you if you participate
16:35:29 <glozow> Especially if you pay 10,000 BTC. Then you can have 2 pizzas
16:36:03 <sipa> :D
16:36:47 <stickies-v> i thought core devs don't have bitcoin
16:36:52 <laanwj> hehe
16:37:09 <glozow> I didn't say I have bitcoin, I have pizzas
16:37:26 <stickies-v> where do people sign up for the sprint?
16:37:59 <fanquake> "early in the release cycle," I guess this is should be pretty soon? Given we are 2 months in already
16:38:40 <fanquake> Also taking into account upcoming christmas / holiday breaks etc
16:38:57 <glozow> You can just do things! But if you're interested and don't know where to start, maybe a comment in #bitcoin-core-pr-reviews? I'm very happy to help people ramp up / look for things to do
16:39:39 <stickies-v> cool - thanks! anything else?
16:39:45 <glozow> fanquake: yes I mean merge in the next couple of weeks, unless we find problems
16:39:53 <glozow> Nothing else from me
16:40:16 <stickies-v> #topic Stratum v2 WG Update (sjors)
16:41:28 <stickies-v> #topic Multiprocess WG Update (ryanofsky)
16:41:30 <abubakarsadiq> There is a new issue tracking issue https://github.com/bitcoin/bitcoin/issues/33777 by @sjors with PR's to review and new ideas
16:41:47 <stickies-v> #topic Stratum v2 WG Update (sjors)
16:42:41 <abubakarsadiq> #33676 seems to be rfm I think
16:42:44 <corebot> https://github.com/bitcoin/bitcoin/issues/33676 | interfaces: enable cancelling running `waitNext` calls by ismaelsadeeq · Pull Request #33676 · bitcoin/bitcoin · GitHub
16:43:16 <abubakarsadiq> plebhash is testing it, he has not report back yet
16:44:39 <stickies-v> thanks for another stand-in update abubakarsadiq . at this rate, you should be press secretary. anything else for sv2?
16:45:00 <abubakarsadiq> haha aye aye captain
16:45:19 <abubakarsadiq> #33745 is also up for review, thats it
16:45:20 <stickies-v> i don't think ryanofsky is here, so i'll go straight to the next one, lmk if updates on multiprocess and we'll revisit at the end
16:45:23 <corebot> https://github.com/bitcoin/bitcoin/issues/33745 | mining: check witness commitment in submitBlock by Sjors · Pull Request #33745 · bitcoin/bitcoin · GitHub
16:45:29 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:46:35 <TheCharlatan> abubakarsadiq are the concerns that ryanofsky raised about the race condition here https://github.com/bitcoin/bitcoin/pull/33676#pullrequestreview-3384352720 addressed in the PR? (sorry didn't type fast enough)
16:47:33 <abubakarsadiq> yes, the push after the comment fixed it.
16:47:56 <TheCharlatan> nice
16:48:53 <stickies-v> #topic Net Split WG Update (cfields)
16:49:33 <cfields> Sorry, I've been away for the past few weeks and haven't gotten rolling yet, so still nothing to report. I hope to have an issue opened by next-week with a logical grouping of subprojects and proposed high-level plan for discussion/review.
16:50:24 <stickies-v> #proposedmeetingtopic dormant WGs
16:50:24 <corebot> stickies-v: Unknown command: #proposedmeetingtopic
16:51:15 <stickies-v> thanks cfields , looking forward to it
16:51:18 <l0rinc> stickies-v: can you please add Andrew Toth to the benchmarking working group?
16:51:31 <stickies-v> #topic dormant WGs
16:52:11 <stickies-v> we haven't had updates from erlay and multiprocess wgs here on the meeting for a while. i suggest i'll remove the from the rotation for now, until champions reach out to reactivate it. don't want to waste ppl's time. any objections?
16:52:58 <stickies-v> l0rinc: what's his irc handle?
16:53:46 <l0rinc> dunno, will ping you later
16:54:25 <stickies-v> Anything else to discuss?
16:54:34 <l0rinc> left this at the end: it's been in review for more than a year now, but I think #30442 is also finally rfm
16:54:37 <l0rinc> same for #33042 and #33443 and #33768 and #33786
16:54:38 <corebot> https://github.com/bitcoin/bitcoin/issues/30442 | precalculate SipHash constant salt XORs by l0rinc · Pull Request #30442 · bitcoin/bitcoin · GitHub
16:54:39 <corebot> https://github.com/bitcoin/bitcoin/issues/33042 | refactor: inline constant return values from `dbwrapper` write methods by l0rinc · Pull Request #33042 · bitcoin/bitcoin · GitHub
16:54:42 <corebot> https://github.com/bitcoin/bitcoin/issues/33443 | log: reduce excessive "rolling back/forward" messages during block replay by l0rinc · Pull Request #33443 · bitcoin/bitcoin · GitHub
16:54:43 <corebot> https://github.com/bitcoin/bitcoin/issues/33768 | refactor: remove dead branches in `SingletonClusterImpl` by l0rinc · Pull Request #33768 · bitcoin/bitcoin · GitHub
16:54:44 <corebot> https://github.com/bitcoin/bitcoin/issues/33786 | script: remove dead code in `CountWitnessSigOps` by l0rinc · Pull Request #33786 · bitcoin/bitcoin · GitHub
16:55:17 <TheCharlatan> One last thing I wanted to add before is kudos to all reviewers and especially stickies-v and purpleKarrot who really helped getting the API into shape :)
16:57:12 <stickies-v> feels like tooting my own horn, but yeah, celebrating is important, thanks for the shoutout TheCharlatan. And obviously this is all possible thanks to your brilliant work
16:57:16 <stickies-v> and with that, let's
16:57:20 <stickies-v> #endmeeting