<l0rinc>
as mentioned here before, I'm investigating if we can extend it in a future PR with different thread context-independent `CheckBlock` validations
<l0rinc>
sipa: you mentioned you were thinking of redesigning validation to be multitreaded, does this interfere with that?
kanzure has quit [Server closed connection]
<stickies-v>
wdym with "different thread context-independent `CheckBlock` validations"?
<sipa>
l0rinc: not pursuing that right now
kanzure has joined #bitcoin-core-dev
<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
winterrdog has quit [Read error: Connection reset by peer]
winterrdog has joined #bitcoin-core-dev
<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
<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)
<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
<johnny9dev>
and i think now is a good time to get started
<johnny9dev>
thats all for now
<stickies-v>
#topic QA WG Update (brunoerg)
<brunoerg>
no update
<cfields>
proposed topic: potential feature-freeze exception for vectorized-chacha20
<stickies-v>
#topic potential feature-freeze exception for vectorized-chacha20 (cfields)
<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
<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).
<cfields>
I can commit to spending the next week working on it if there's interest in doing some focused review for v32.
<sipa>
next week is a bad time for me, i don't think i can commit to reviewing
<cfields>
Nothing about it is urgent, it'd just be a nice speedup to ship for 32.
<l0rinc>
It's not technically a feature, optimizations can be considered bugfixes - I can continue reviewing
<stickies-v>
this looks like a cool improvement but i think it'd be equally cool to ship in 33?
ViniciusCestarii has joined #bitcoin-core-dev
<cfields>
Ok, wfm.
<l0rinc>
I'm fine with both, we have a few other optimizations lined up anyway
<cfields>
my fault for letting it sit there for so long.
<cfields>
thanks. next topic :)
<stickies-v>
so yeah, PSA: today is feature freeze
<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
<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
<stickies-v>
oh and also it was mentioned as a way to express copyright
<sr_gi>
Context?
<sipa>
stickies-v: i was just comparing it with copyright as a bar
<corebot>
stickies-v: Error: That URL raised <HTTP Error 404: Not Found>
<sr_gi>
:tumbsup:
<stickies-v>
sipa: oh sorry, thanks for correcting
<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
<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.
winterrdog has quit [Read error: Connection reset by peer]
<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
<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.
<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)
<sipa>
How so? AI tools don't have copyright, and we don't add them as co-author.
<sipa>
So the analogy seems to work.
winterrdog has joined #bitcoin-core-dev
<l0rinc>
AI is tool, we don't add clang-tidy as coauthor either
<l0rinc>
we don't need to thank the AIs (yet)
<sipa>
I'm not sure if you're agreeing or disagreeing with me.
<l0rinc>
I think I'm mostly agreeing
<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
<sipa>
My position is that you should add someone as co-author if they could reasonably claim copyright.
<stickies-v>
sipa: that sounds like a good heuristic to me
<sipa>
It's a way of giving credit, but for actually contributed code, not.ideas.
<sipa>
It does not imply the co-author understands the entire commit.
<l0rinc>
I am very much against copyright, so the analogy gives me the creeps
<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.
winterrdog has quit [Client Quit]
<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?
<shiza>
hi
<shiza>
I read it was something about grants
<sipa>
l0rinc: ok, read it as "contributed a nontrivial piece of code of at least 5-10 lines" then
<l0rinc>
what the reason for avoiding it for 1-5 lines? Is it a grant-thing as mentioned?
<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.
<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?
<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
<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.
<fanquake>
*about the request for someone else to be added as co-author
<jonatack>
I think co-authored-by credits are up to the PR author at their own discretion (I generally happily add anyone that contributed meaningfully), but not something that one would ask for.
nervana21 has quit [Quit: Client closed]
<tigerMafia>
jonatack: +1
<jonatack>
As for grant KPIs, I don't think those credits make any difference in the overall scheme of things. At least not when I review grant applications and reports. If you were already a reviewer of the PR in question, which would generally be the case, that's enough ;)
<lightlike>
well, at least in the gray areas. In clear cases where someone actually wrote most of the code of a commit, I think they should at least be co-author, if not first author, and I wouldn't think it rude to ask for it.
<jonatack>
I look much, more more at the quality/value of the review.
<jonatack>
lightlike: agree, fair, I would think the author should add the credit without needing to be asked.
rustaceanrob has quit [Ping timeout: 252 seconds]
<sr_gi>
jonatack: But that is a bit of a contradiction right? If it's at the author's discretion but they should do so without being asked, it bears the question of what's the criteria
<sr_gi>
To be clear, I do agree with it being the author's discretion, and I do think, by definition, that people should not expect parity
enochazariah has quit [Ping timeout: 248 seconds]
<jonatack>
sr_gi: yes. kindness and empathy, I guess. there isn't necessarily parity there either, and we all have our days :shrug:
sr_gi has quit [Quit: Client closed]
Earnestly has joined #bitcoin-core-dev
dzxzg has quit [Quit: onversation terminated!]
sr_gi has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
sr_gi has quit [Quit: Client closed]
dzxzg has quit [Client Quit]
ViniciusCestarii has quit [Quit: Client closed]
tigerMafia has quit [Quit: tigerMafia]
<Earnestly>
Would it be desirable to apply standard optimisations to miniscript such as constant folding, dead code elimination, etc?
<Earnestly>
(Including script)
<nkaretnikov>
i don’t understand why people are debating attribution. git has this built in. make people write their commits or submit patches and it’s clear which lines they added or not. if they cannot provide a patch or contributed in some other way, explicitly mention this in the commit message. seems like this solves all the concerns above.
Pasha28 has joined #bitcoin-core-dev
Pasha17 has quit [Ping timeout: 265 seconds]
Pasha97 has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
jerryf has quit [Remote host closed the connection]
Pasha28 has quit [Ping timeout: 261 seconds]
jerryf has joined #bitcoin-core-dev
musaHaruna has quit [Quit: Connection closed for inactivity]
enochazariah has joined #bitcoin-core-dev
sliv3r__ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
sliv3r__- has joined #bitcoin-core-dev
sliv3r__- has quit [Read error: Connection reset by peer]
sliv3r__ has joined #bitcoin-core-dev
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 252 seconds]
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
svanstaa has quit [Quit: Client closed]
<Sjors[m]>
<nkaretnikov> "i don’t understand why people..." <- We are quite picky about each PR having a clear commit history, from a functionally perspective, not who wrote which line.
<Sjors[m]>
So most feedback gets folded into an existing commit.
<Sjors[m]>
For grants people are probably better off asking for a reference than to max out co-authorship.
Pasha7 has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 245 seconds]
Pasha97 has quit [Ping timeout: 259 seconds]
Pasha14 has joined #bitcoin-core-dev
Pasha15 has joined #bitcoin-core-dev
Pasha7 has quit [Ping timeout: 269 seconds]
Pasha14 has quit [Ping timeout: 253 seconds]
Pasha31 has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 252 seconds]
Pasha15 has quit [Ping timeout: 240 seconds]
Pasha20 has joined #bitcoin-core-dev
Pasha97 has joined #bitcoin-core-dev
Pasha31 has quit [Ping timeout: 246 seconds]
Pasha20 has quit [Ping timeout: 248 seconds]
<achow101>
the only times I add people as co-author is if they dropped a diff/suggestion that ends up being a majority of a commit. I don't think it makes sense to be adding coauthorship for line by line suggestions left during review.
<achow101>
even when I take someone's commit wholesale into my pr, and make my own changes to it, i can't even be bothered to add myself as a co-author