16:00:01 <fjahr> #startmeeting 
16:00:01 <corebot> fjahr: Meeting started at 2026-01-08T16: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:09 <stickies-v> hi
16:00:11 <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 sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
16:00:14 <janb84> hi
16:00:15 <pinheadmz> yo
16:00:16 <achow101> hi
16:00:18 <sedited> hi
16:00:22 <hebasto> hi
16:00:23 <lightlike> hi
16:00:23 <vasild> hi
16:00:24 <stringintech> hi
16:00:31 <yancy> hi
16:00:32 <fjahr> There are two pre-proposed meeting topics this week. Any last minute ones to add?
16:00:32 <glozow> hi
16:00:35 <kevkevin> hi
16:00:37 <brunoerg> hi
16:00:37 <enochazariah> hi
16:00:39 <abubakarsadiq> hi
16:00:40 <andrewtoth> hi
16:00:41 <hodlinator> hi
16:00:46 <_aj_> hi
16:00:53 <furszy> hi
16:00:55 <l0rinc> hi
16:01:27 <sipa> hi
16:01:48 <ryanofsky> hi
16:01:49 <fjahr> Ok, starting with the working groups
16:01:49 <marcofleon> hi
16:01:52 <fjahr> #topic Kernel WG Update (sedited)
16:02:18 <sedited> A bunch of PRs waiting for review on the project board: https://github.com/orgs/bitcoin/projects/3
16:03:00 <sedited> Some progress is being made on experimenting with copy-on-write datastructures, janb84 has been running some preliminary benchmarks for replacing the current CChain with such a structure.
16:03:20 <sedited> that's all
16:03:40 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:03:47 <l0rinc> #33866 was merged, so we rebased the related PRs:
16:03:49 <corebot> https://github.com/bitcoin/bitcoin/issues/33866 | refactor: Let CCoinsViewCache::BatchWrite return void by sedited · Pull Request #33866 · bitcoin/bitcoin · GitHub
16:03:52 <l0rinc> #34132 - the extra error catcher cache layer was inlined to simple call-site try/catch
16:03:54 <corebot> https://github.com/bitcoin/bitcoin/issues/34132 | refactor: inline `CCoinsViewErrorCatcher` into `CCoinsViewDB` by l0rinc · Pull Request #34132 · bitcoin/bitcoin · GitHub
16:04:01 <l0rinc> #34124 - CCoinsView acted as part-interface, part empty implementation - split it into a pure interface and an empty implementation.
16:04:04 <cfields_> hi
16:04:05 <corebot> https://github.com/bitcoin/bitcoin/issues/34124 | refactor: make `CCoinsView` a purely virtual abstract base class by l0rinc · Pull Request #34124 · bitcoin/bitcoin · GitHub
16:04:09 <l0rinc> And a PR was split off from #33018:
16:04:13 <corebot> https://github.com/bitcoin/bitcoin/issues/33018 | coins: remove SetFresh method from CCoinsCacheEntry by andrewtoth · Pull Request #33018 · bitcoin/bitcoin · GitHub
16:04:15 <l0rinc> #34207 - GetCoin() is an interface for querying the UTXO set, so production implementations should only ever return unspent coins - adjusted tests to make them more realistic and exercise cases that can actually happen.
16:04:17 <corebot> https://github.com/bitcoin/bitcoin/issues/34207 | coins/refactor: enforce `GetCoin()` returns only unspent coins by l0rinc · Pull Request #34207 · bitcoin/bitcoin · GitHub
16:04:23 <l0rinc> There's also PR now for untimed setup phase for nanobench: #34208
16:04:24 <corebot> https://github.com/bitcoin/bitcoin/issues/34208 | bench: add fluent API for untimed `setup` steps in nanobench by l0rinc · Pull Request #34208 · bitcoin/bitcoin · GitHub
16:04:31 <l0rinc> Two PRs were split off from #31132 since they can be reviewed and merged independently - I'll let andrewtoth expand on those.
16:04:34 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:04:40 <andrewtoth> We measured #31132 in a cloud environment with network connected storage, and it is >3x faster reindex-chainstate https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3678847806.
16:04:41 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:04:47 <andrewtoth> It is also faster connecting blocks at tip during steady state. It has been thoroughly fuzzed, and we split out two other PRs #34164, #34165 from it that could have small benefit on their own (and would help make #31132 easier to review).
16:04:49 <corebot> https://github.com/bitcoin/bitcoin/issues/34164 | validation: add reusable coins view for ConnectBlock by andrewtoth · Pull Request #34164 · bitcoin/bitcoin · GitHub
16:04:52 <corebot> https://github.com/bitcoin/bitcoin/issues/34165 | coins: don't mutate main cache when connecting block by andrewtoth · Pull Request #34165 · bitcoin/bitcoin · GitHub
16:04:54 <andrewtoth> We're in the process of measuring windows but having some inconsistent results.
16:04:55 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:04:59 <andrewtoth> Review on the split out or main PRs are welcome. That's it from me, thanks.
16:05:13 <sipa> i plan to dive into these PRs soon!
16:05:31 <l0rinc> Thanks sipa - Q: given how much effort is put into cleaning up the coins cache, would it help if we made a tracking issue/PR/project for it?
16:05:32 <andrewtoth> sipa: thank you!
16:05:52 <sipa> i think a tracking issue makes sense for all coins cache related improvements
16:06:15 <l0rinc> Will do that, thanks
16:06:20 <l0rinc> that's it from us
16:06:25 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:06:53 <sipa> hi
16:07:31 <sipa> main PR to review is #34023, which optimizing the cluster linearization algorithm, after it was replaced by SFL in 32545
16:07:33 <corebot> https://github.com/bitcoin/bitcoin/issues/34023 | Optimized SFL cluster linearization by sipa · Pull Request #34023 · bitcoin/bitcoin · GitHub
16:08:04 <sipa> there is some ongoing discussion that may use some conceptual input on #33335
16:08:07 <corebot> https://github.com/bitcoin/bitcoin/issues/33335 | txgraph: randomize order of same-feerate distinct-cluster transactions by sipa · Pull Request #33335 · bitcoin/bitcoin · GitHub
16:08:35 <sipa> the PR there proposes introducing more randomness for sorting equal-feerate transactions and chunks, to fix a privacy leak (reveal information about the order transactions were received)
16:09:03 <sipa> but randomness also has downsides in terms of non-predictability, worse block propagation, and ability to monitor behavior on the network
16:09:21 <sipa> so i'm considering (and implementation) and alternative that makes the ordering deterministic; PR forthcoming
16:09:43 <sipa> that's it for me
16:09:43 <l0rinc> would it be configurable?
16:10:03 <sipa> i don't think it makes sense to make this configurable
16:10:19 <dergoegge> hi
16:10:37 <fjahr> #topic Net Split WG Update (cfields)
16:10:45 <instagibbs> thanks sipa
16:11:04 <darosior> hi
16:11:11 <cfields> I've spent this week profiling and benchmarking a few assumptions (send/receive buffer sizes, corking behavior, etc) in our net code after the chacha20 speedups to ensure that the net split doesn't bake in any bad assumptions. Thankfully things look quite balanced, so I'm setting that aside and continuing with the manual code movement. Not much to see yet.
16:12:19 <l0rinc> cfields: I have experimented a bit more with your ChaCha20 branch: do we understand why clang is ~2x faster than gcc? At least it is for me on every platform I tried
16:13:46 <cfields> l0rinc: I mostly tested with clang, so I suppose that makes sense. I didn't realize there was _that_ much difference though. I can spend a little time looking at the generated code to see what the main differences are.
16:14:25 <sipa> 2x is remarkable - it sounds like some vectorization step that one compiler does and the other doesn't
16:14:27 <l0rinc> I think I found a config that speeds up GCC - and even clang a bit, but it's still a lot slower
16:15:32 <fjahr> Moving on, this is probably best discussed after the meeting :)
16:15:34 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:15:35 <cfields> It's very sensitive to register allocation. Perhaps gcc misses out somewhere. l0rinc: let's chat after the meeting and compare notes.
16:15:42 <cfields> fjahr: 👍
16:16:00 <dergoegge> I think I mentioned last meeting that I'm writing a blog post series on fuzzamoto
16:16:10 <dergoegge> The first part of that is out now: https://brink.dev/blog/2026/01/07/fuzzamoto-introduction/
16:16:29 <dergoegge> That's all for this week from my side
16:17:13 <furszy> cool stuff
16:17:19 <eugenesiegel> nice
16:17:28 <glozow> nice
16:17:39 <fjahr> Ok, I am skipping Silent Payments because I didn't see Novo__ unless someone wants to add something. I can at least say there is quite a bit of action in secp currently.
16:18:05 <furszy> can briefly update the state
16:18:31 <furszy> theStack pushed another PR with the new scanning approach: https://github.com/bitcoin-core/secp256k1/pull/1792
16:18:43 <furszy> focus is now there
16:19:35 <fjahr> Yeah, I think conceptual feedback on the APIs and worst scanning concerns would great from anyone interested in using SP!
16:19:51 <fjahr> Thanks everyone for the updates!
16:19:54 <fjahr> #topic maintainer nomination (glozow)
16:20:07 <glozow> I’m nominating TheCharlatan aka sedited to be a maintainer. He is a reliable reviewer who has worked extensively in critical areas of the codebase, thinks carefully about what we ship to users and developers, and understands the technical consensus process well.
16:20:14 <glozow> I’ve spoken with him and the other maintainers already, and hope that the rest of you agree he is well-suited for the role. Please speak freely with your concerns and/or support.
16:20:19 <achow101> ack
16:20:27 <dergoegge> ack
16:20:32 <marcofleon> ack
16:20:33 <hebasto> ack
16:20:37 <brunoerg> ack
16:20:39 <sliv3r__-> ack
16:20:39 <pinheadmz> ack
16:20:42 <sipa> ack
16:20:43 <instagibbs> ack
16:21:00 <l0rinc> ACK
16:21:07 <furszy> ack TheCharlatan, I don't know sedited enough yet.
16:21:10 <fjahr> ack, but I guess there will be an issue as well like last time?
16:21:14 <lightlike> ack
16:21:17 <andrewtoth> ack
16:21:22 <hodlinator> ack
16:21:25 <janb84> ack
16:21:30 <yancy> ack
16:21:32 <stickies-v> ack
16:21:40 <glozow> The next step would be for him to open a PR to add his key to trusted-keys
16:21:42 <darosior> Ack. To add to that i agree especially with the part of him having a project-wide view and his care for what we ship to users.
16:22:31 <maxedw> ack
16:23:15 <glozow> sedited: do you want to add anything? :)
16:23:20 <sedited> ty, fjahr do you have that issue number?
16:23:37 <abubakarsadiq> ACK
16:24:00 <fjahr> no, I meant that I think we opened an issue for discussion last time if I remember correctly and I asked if this is happening again.
16:24:07 <fjahr> But maybe that was also the PR already
16:24:16 <glozow> I don't think we did an issue, just a PR
16:24:19 <achow101> just the pr
16:24:20 <darosior> Maybe you are referring to the thread of the PR where the last person added their key?
16:25:22 <fjahr> It's not so relevant, I need to go back and look at it
16:25:43 <fjahr> It's been a while
16:26:35 <fjahr> Anything else to add on this topic?
16:26:41 <maflcko> ack, sedited seems a great fit for the role
16:26:54 <glozow> I think that's it. The rest can be on the PR
16:27:13 <fjahr> #topic incremental mutation testing (brunoerg)
16:27:20 <brunoerg> Hi, I've been doing incremental mutation testing (basically mutaiton testing on PRs) for a month or more. I wrote a summary on delving about the results I had so far: https://delvingbitcoin.org/t/incremental-mutation-testing-in-the-bitcoin-core/2197
16:27:31 <brunoerg> Right now, I'm working on making the analysis more efficient, so your feedback is important. There is a section "Final notes" with some actions so I'd appreciate some feedback on that points.
16:27:43 <brunoerg> Also, if you want a mutation testing run on any PR, please ping me in the PR.
16:28:01 <kevkevin> ack
16:28:03 <brunoerg> That's all
16:29:01 <fjahr> Anything else to discuss?
16:29:05 <abubakarsadiq> #proposedmeetingtopic fee estimation improvement
16:29:05 <corebot> abubakarsadiq: Unknown command: #proposedmeetingtopic
16:29:17 <cfields> walked away for a few min. ACK sedited :)
16:29:50 <fjahr> #topic fee estimation improvement
16:29:57 <fjahr> go ahead :)
16:30:13 <abubakarsadiq> I opened a #34075, which attempts to fix the ancient #27995 issue with a mempool-based fee estimator that only lowers the Block Policy Estimator.
16:30:13 <abubakarsadiq> Empirically, I observed a 73% success rate with 0% overestimation, and 26% underestimation with this approach. I did some refactors to enable these. See PR op for more details.
16:30:13 <abubakarsadiq> Bringing this here to request feedback on the approach and the assumption there.
16:30:15 <corebot> https://github.com/bitcoin/bitcoin/issues/34075 | fees: Introduce Mempool Based Fee Estimation to reduce overestimation by ismaelsadeeq · Pull Request #34075 · bitcoin/bitcoin · GitHub
16:30:16 <corebot> https://github.com/bitcoin/bitcoin/issues/27995 | Improving fee estimation accuracy · Issue #27995 · bitcoin/bitcoin · GitHub
16:30:49 <abubakarsadiq> thats it, thanks :)
16:31:15 <sipa> How do you define overestimation/underestimation here?
16:33:00 <abubakarsadiq> overestimation is when you estimate a feerate for target x as y.
16:33:00 <abubakarsadiq> but all the blocks since from current height to current height + x the estimated fee rate is above their 95th percentile fee rate
16:33:24 <abubakarsadiq> that imply that you overshoot
16:34:00 <abubakarsadiq> underestimation is when y is below the 5th percentile fee rate of all blocks from current height to current height + x
16:34:14 <sipa> got it
16:34:16 <sipa> cool
16:35:05 <l0rinc> #topic (ATT)ACKs
16:35:46 <l0rinc> please let me know when the previous topic is finished
16:36:04 <fjahr> I guess it is now ;)
16:36:07 <l0rinc> I would also like your feedback on a different topic, since we saw fake ACKs being spread around - we could adjust the DrahtBot ACK summary with avatars and maybe italics for members to avoid impersonations. And while we're touching this, ryanofsky suggested we add links to all acks, not just the last one. Your feedback is welcome in https://github.com/maflcko/DrahtBot/pull/72
16:36:07 <abubakarsadiq> yes go ahead
16:36:46 <l0rinc> that's it, thanks
16:36:56 <achow101> i don't like it, too much visual clutter
16:37:07 <achow101> usernames is fine for me
16:37:17 <abubakarsadiq> I think this is relevant to maintenance and how they weigh ACK, i doubt if avatar would improve their process
16:37:40 <instagibbs> right, I think maintainers should speak up if anything can make their job easier
16:37:54 <l0rinc> it would look something like: https://gist.github.com/l0rinc/6e92f6ac500a7ab9cc91d0b19a009392
16:37:59 <sipa> yeah, this seems to be something that mostly needs maintainer opinions
16:37:59 <fanquake> ~0 leaning the same way. I don't think avatars add anything (~20% of contribs use the GH default anyways), and org membership doesn't really matter?
16:38:01 <kevkevin> can you instead sort them by when the account was first made?
16:38:16 <kevkevin> not sure if there is any sorting done right now
16:38:29 <sliv3r__> or sort by members, contributors, etc.
16:38:49 <brunoerg> I don't like it as well, kinda polluted
16:38:54 <pinheadmz> have there been ACK from actual homograph users? (like "s1pa" or soemthing)
16:39:06 <glozow> avatars are copiable too
16:39:31 <l0rinc> yes, of course, that's why members would be shown in italics
16:39:38 <sipa> pinheadmz: on twitter, yes...
16:39:43 <achow101> pinheadmz: i don't think we've had any yet
16:39:44 <sipa> ah, ACKs, no
16:40:37 <l0rinc> The new maintainer could do the funniest thing: TheCharltan -> sedited -> s1pa
16:40:47 <_aj_> for PRs with a large number of acks, could consider breaking out the members/non-members into separate tables, as well as the bold distinction. the avatars don't seem that useful to me. links to prior acks would be handy sometimes though
16:41:04 <ryanofsky> if impersonation is a problem i think we should find a way to remove impersoniated nicks from the table, not just display them differently
16:41:26 <glozow> I don't think we are tricked so easily. The most harm these ack tables do is on social media. Any chance github allows comments that are only viewable by members?
16:41:28 <sipa> i don't think impersonation is a problem - and it's something that can be dealt with if it ever becomes one
16:41:34 <fanquake> We seem to have started with the assumption that this is actually a common issue. It isn't for 99.99% of PRs, and on the occasional PR it could be, I'm sure maintainers would be paying more attention. (the drahtbot comment sholdn't be a subsittute for checking anything)
16:41:37 <pinheadmz> could add # of commits to repo after each username
16:41:57 <_aj_> (marcofleon and maflcko have the homograph approach covered already as far as i'm concerned)
16:42:00 <instagibbs> recently I've seen some "farming" but it you just weight those acks at ~0 unless proven competence otherwise
16:42:20 <l0rinc> ok, thanks for the feedbacks
16:42:24 <achow101> i think the table is fine as-is
16:42:41 <achow101> low effort accounts and new contributors are already being filtered out in people's heads
16:42:57 <pinheadmz> I had a draht bot PR that hid the table if the PR was labeled "controversial" but it was nacked and closed
16:44:22 <maflcko> _aj_: pinheadmz: I think there were some attempts to deal with "controversial"/"verbose" pulls, but I think it went nowhere conclusive. Also, it only happens every year or two, so an automatated approach for a rare anomaly seems overkill
16:44:37 <fjahr> ok, any more last minute topics?
16:45:05 <furszy> happy to answer questions related to the recent bug via DM if needed.
16:45:15 <achow101> same
16:45:30 <pinheadmz> _aj_ I sign my ACKs too! Isn't everyone... verifying... those ?
16:46:15 <fjahr> #endmeeting