16:00:12 <stickies-v> #startmeeting 
16:00:12 <corebot> stickies-v: Meeting started at 2026-08-20T16:00+0000
16:00:14 <corebot> stickies-v: Current chairs: stickies-v
16:00:15 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:17 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:18 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:19 <cfields> hi
16:00:20 <l0rinc> hi
16:00:24 <brunoerg> hi
16:00:27 <dzxzg> hi
16:00:27 <lightlike> hi
16:00:27 <sr_gi> hi
16:00:30 <hebasto> hi
16:00:32 <danielabrozzoni> hi
16:00:46 <stickies-v> #bitcoin -core-dev Meeting: _aj_ abubakarsadiq achow101 andrewtoth b10c brunoerg cfields danielabrozzoni darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy hebasto hodlinator instagibbs janb84 jarolrod johnny9dev jonatack josie jurraca kanzure kevkevin laanwj lightlike l0rinc maflcko marcofleon maxedw Murch pinheadmz provoostenator pseudoramdom ryanofsky sdaftuar sedited sipa sliv3r__ sr_gi stickies-v
16:00:46 <stickies-v> stringintech theStack vasild willcl-ark
16:00:50 <dergoegge> hi
16:00:52 <janb84> hi
16:00:57 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:01:03 <enochazariah> hi
16:01:30 <jonatack> hi
16:02:16 <johnny9dev> hi
16:02:28 <stickies-v> #topic Fuzzing WG Update (dergoegge, marcofleon)
16:02:44 <dergoegge> no update
16:02:46 <hodlinator> hi
16:02:58 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:03:10 <l0rinc> #35889 was merged, is a similar follow-up #36032
16:03:13 <corebot> https://github.com/bitcoin/bitcoin/issues/35889 | rpc: avoid quadratic `gettxspendingprevout` work and preserve order by l0rinc · Pull Request #35889 · bitcoin/bitcoin · GitHub
16:03:14 <corebot> https://github.com/bitcoin/bitcoin/issues/36032 | rpc: avoid quadratic output lookups by l0rinc · Pull Request #36032 · bitcoin/bitcoin · GitHub
16:03:20 <l0rinc> #35531 was also merged, #36002 is a follow-up to make it work for pruned nodes
16:03:24 <corebot> https://github.com/bitcoin/bitcoin/issues/35531 | txindex: hash keys and pack positions to reduce disk usage by andrewtoth · Pull Request #35531 · bitcoin/bitcoin · GitHub
16:03:25 <corebot> https://github.com/bitcoin/bitcoin/issues/36002 | txindex: allow running in pruned mode by andrewtoth · Pull Request #36002 · bitcoin/bitcoin · GitHub
16:03:47 <Murch[m]> hi
16:04:07 <l0rinc> and as mentioned before here, #36000 was opened since
16:04:09 <corebot> https://github.com/bitcoin/bitcoin/issues/36000 | validation: prefetch blocks while connecting by l0rinc · Pull Request #36000 · bitcoin/bitcoin · GitHub
16:04:26 <l0rinc> it shines on HDDs especially
16:04:42 <sipa> hi
16:05:06 <hodlinator> nice!
16:05:23 <l0rinc> as mentioned here before, I'm investigating if we can extend it in a future PR with different thread context-independent `CheckBlock` validations
16:06:18 <l0rinc> sipa: you mentioned you were thinking of redesigning validation to be multitreaded, does this interfere with that?
16:06:57 <stickies-v> wdym with "different thread context-independent `CheckBlock` validations"?
16:07:04 <sipa> l0rinc: not pursuing that right now
16:07:47 <l0rinc> #36000 loads the blocks on different threads, so we can do some of the check (the ones that don't require extra connection context) there basically for free
16:07:49 <corebot> https://github.com/bitcoin/bitcoin/issues/36000 | validation: prefetch blocks while connecting by l0rinc · Pull Request #36000 · bitcoin/bitcoin · GitHub
16:08:46 <l0rinc> that's it from me, thanks
16:08:47 <stickies-v> i see, just CheckBlock on multiple threads
16:08:51 <l0rinc> yes
16:09:38 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:10:03 <johnny9dev> Started the first PR into the gui-qml "staging" branch at https://github.com/bitcoin-core/gui-qml/pull/871
16:11:08 <johnny9dev> The idea is to reconstruct the project with clean, mergable history using everything we've learned building the project. I need to work on the description still
16:12:12 <johnny9dev> The first 2 or 3 PR will likely be the most interesting as it will establish the core pieces (build, test, app lifecycle, and basic models)
16:14:02 <johnny9dev> so I think that is the plan to move towards getting this upstreamed. I will give these PRs plenty of time to get review from anyone that would potentially be interested in them
16:14:21 <johnny9dev> and i think now is a good time to get started
16:14:50 <johnny9dev> thats all for now
16:16:39 <stickies-v> #topic QA WG Update (brunoerg)
16:16:48 <brunoerg> no update
16:16:49 <cfields> proposed topic: potential feature-freeze exception for vectorized-chacha20
16:17:07 <stickies-v> #topic potential feature-freeze exception for vectorized-chacha20 (cfields)
16:17:28 <cfields> Very sorry for coming down to the wire here, but I'm curious if there's any appetite for an exception to the feature freeze for the vectorized chacha20 impl. It speeds up chacha20 by 1.5-3x (depending on platform/compiler), which is currently one of the most obvious pain points that shows up in flame graphs. I opened the PR months ago but I've been waiting to see what happened with upstream GCC (they're working on a substantial vectorization
16:17:28 <cfields> improvement that I assumed existed there while working on the PR. They've responded to my bug reports and I'm confident that the improvements will land, but haven't yet so I've decided to pivot). I'm working on a 128bit version (with l0rinc's help) that should perform better everywhere (though can be replaced with a better 256bit version once GCC gets its act together).
16:18:01 <cfields> I can commit to spending the next week working on it if there's interest in doing some focused review for v32.
16:18:08 <cfields> #34083 
16:18:12 <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:19:10 <sipa> next week is a bad time for me, i don't think i can commit to reviewing
16:19:24 <cfields> Nothing about it is urgent, it'd just be a nice speedup to ship for 32.
16:19:25 <l0rinc> It's not technically a feature, optimizations can be considered bugfixes - I can continue reviewing
16:19:53 <stickies-v> this looks like a cool improvement but i think it'd be equally cool to ship in 33?
16:21:12 <cfields> Ok, wfm.
16:21:17 <l0rinc> I'm fine with both, we have a few other optimizations lined up anyway
16:22:16 <cfields> my fault for letting it sit there for so long.
16:22:30 <cfields> thanks. next topic :)
16:22:41 <stickies-v> so yeah, PSA: today is feature freeze
16:23:57 <stickies-v> should we talk a bit more about the co-authorship thing? i don't really care much about/for it but it seems to have come up a few times
16:24:45 <stickies-v> i think one group sees it as a tool to figure out who knows the most about a piece of code/is a person to talk to, another sees it as a way to give credit / say thank you
16:25:50 <stickies-v> oh and also it was mentioned as a way to express copyright
16:26:20 <sr_gi> Context?
16:26:57 <sipa> stickies-v: i was just comparing it with copyright as a bar
16:27:23 <stickies-v> sr_gi: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-08-18#1247067 (and following days)
16:27:24 <corebot> stickies-v: Error: That URL raised <HTTP Error 404: Not Found>
16:27:36 <sr_gi> :tumbsup:
16:27:38 <stickies-v> sipa: oh sorry, thanks for correcting
16:27:45 <sipa> i see it as a way of giving credit, and the bar that sounds reasonable for that seems to roughly match the point where someome could claim cooyright
16:27:55 <l0rinc> copyright is a bad example here: https://github.com/bitcoin/bitcoin/pull/35794#issuecomment-5072615311: Relevant U.S. Copyright Office guidance page 5
16:27:55 <l0rinc> > Applicants should not list an AI technology or the company that provided it as an author or co-author simply because they used it.
16:29:22 <stickies-v> i use it when someone has contributed significant amounts of code, or in rare cases even when there was no/little code but a significant amount of architectural/design ideas that made me change course
16:29:23 <l0rinc> I also see it as giving credit to thank people who helped in shaping the outcome. A good recent example is https://x.com/Rob1Ham/status/2090271687090520435, Rob spent a lot of time and money on finding these, the least we can do is acknowledge his work by adding him as coauthor.
16:29:44 <sr_gi> I've been using it myself to give credit, specially if someone else has started the work and I've picked it up later, but the base is still theirs (e.g. Gleb with Erlay)
16:29:52 <sipa> How so? AI tools don't have copyright, and we don't add them as co-author.
16:30:06 <sipa> So the analogy seems to work.
16:30:38 <l0rinc> AI is tool, we don't add clang-tidy as coauthor either
16:30:55 <l0rinc> we don't need to thank the AIs (yet)
16:31:00 <sipa> I'm not sure if you're agreeing or disagreeing with me.
16:31:16 <l0rinc> I think I'm mostly agreeing
16:31:34 <dzxzg> I don't know if it's something that needs to have well-defined meaning, everyone probably uses it a little bit differently, but all use it to mean some variation of "this person helped make this change." anything more detailed would probably need to be resolved case-by-case between the author and (alleged) coauthor
16:31:37 <sipa> My position is that you should add someone as co-author if they could reasonably claim copyright.
16:31:59 <stickies-v> sipa: that sounds like a good heuristic to me
16:32:00 <sipa> It's a way of giving credit, but for actually contributed code, not.ideas.
16:32:13 <sipa> It does not imply the co-author understands the entire commit.
16:32:23 <l0rinc> I am very much against copyright, so the analogy gives me the creeps
16:32:44 <johnny9dev> just an fyi, I'll be making heavy use of co-authored-by in the gui-qml staging commits as I will be compressing the large history into something digestible. The co-authors will all have been involved with constructing the relevant piece in some significant way. I will make sure I only co-author the person if I believe they can speak on the functionality introduced.
16:33:15 <l0rinc> is there a drawback to thanking people this way? What's the reason for the pushback exactly, that it's interpreted as distributing blame?
16:33:36 <shiza> hi
16:33:45 <shiza> I read it was something about grants
16:33:51 <sipa> l0rinc: ok, read it as "contributed a nontrivial piece of code of at least 5-10 lines" then
16:34:53 <l0rinc> what the reason for avoiding it for 1-5 lines? Is it a grant-thing as mentioned?
16:34:58 <sipa> l0rinc: i think it is weird to credit anyone who contributed ideas or helped with benchmarks or whatever, it's a collaborative project where everyone builds on one another. Authorship is a higher bar than that.
16:35:31 <sipa> Or suggested a few single line changes.
16:35:33 <fanquake> Yea. My pushback to https://github.com/bitcoin/bitcoin/pull/36000#discussion_r3806893819, was that I'd barely looked at the code, so I didn't see why I'd be a co-author
16:35:48 <shiza> 2026-08-14 21:28:42     _aj_    are we using co-author to mean "wrote some of the code in this commit" or "contributed to the design" these days? i thought the former, but i've seen a few cases where the latter seems to be more in play? does the distinction matter for some people's grant KPIs?
16:35:52 <fanquake> I guess AJ was similarly confused here, https://github.com/bitcoin/bitcoin/pull/35920#issuecomment-5273356225, about the request to be added as co-author
16:35:54 <sr_gi> l0rinc: reading the piece that stickies-v shared I see the issue as *not giving credit* instead of doing so, but I haven't read the whole history
16:35:56 <lightlike> different policies becomes a problem when people expect others to add them as coauthors (in the way they would do it to them), but the other person has a stricter policy and declines the request.
16:36:23 <fanquake> *about the request for someone else to be added as co-author
16:36:24 <l0rinc> "Authorship is a higher bar than that" - if someone contributed meaningfully I just add them as main author in that case, like: https://github.com/bitcoin/bitcoin/pull/35752/commits
16:37:09 <sipa> you can contribute a meaningful amount of code without being the main author of a commit
16:38:32 <stickies-v> alright, i think we can wrap up on this
16:38:34 <stickies-v> anything else to discuss?
16:39:10 <l0rinc> thanks for the feedback
16:40:32 <stickies-v> #endmeeting