afiore has quit [Remote host closed the connection]
afiore has joined #bitcoin-core-dev
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
smartin has joined #bitcoin-core-dev
enochazariah__ has joined #bitcoin-core-dev
smartin2 has joined #bitcoin-core-dev
luke-jr_ is now known as luke-jr
smartin has quit [Ping timeout: 257 seconds]
smartin2 is now known as smartin
vicjuma has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
<sedited>
there is zero substance in that comment.
vicjuma has quit [Quit: Client closed]
phungus815352086 has quit [Ping timeout: 248 seconds]
<stevenroose>
yeah lol
<maflcko>
Assuming willcl-ark is fine with that too: Would there be any objection of bringing the Ralph LLM review into a hidden/collapsed repo comment? The benefit would be to save one click and external tab for those that want to use it. For those that want to ignore the LLM-speak, the comment remains collapsed and can easily be ignored, just like the external link?
mercie-ux has joined #bitcoin-core-dev
memset has joined #bitcoin-core-dev
vicjuma has joined #bitcoin-core-dev
memset_ has quit [Remote host closed the connection]
JTL has quit [Quit: WeeChat 4.10.2]
JTL has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
<sedited>
I'd still prefer the link for now.
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
<sliv3r__>
+1 on the link, I am using ralph a lot lately but I find it easier to find with a link as I know where it is, maybe looking for a comment in a long threat is not as good... unless we change the external repo link for a comment link :)
<maflcko>
I was thinking it would be one of the earlier comments (like the Drahtbot one), so it would be easy to find, but still collapsed to be hidden by default. But no strong opinion. Making it an internal link is also possible, but seems fine to keep an external link for now. No rush to change it.
<willcl-ark>
(of I am quite biased here but) I also feel like an inline comment would be nice at this point in time, seeing as ralph seems to now report few LLM hallucinations. This is already being trialled over in gui-qml for anyone who'd like to see how it looks, minus the collapsible comment part.
<willcl-ark>
I think one reason for posting directly in the PRs is that it cuts out a reviewer having to post the (spammy?) "please check the ralph review" comment on PRs, and might also reduce reviewers re-posting findings ralph has already flagged.
<willcl-ark>
sedited: might i ask for what reason you'd prefer not to see a direct comment on the PR? Whilst I get us not wanting tonnes of pure AI-written review comments, IMO having a single one per-PR wouldn't be _too_ bad...
<maflcko>
My hope is also that having it collapsed, but inline would discourage all the other (duplicate) LLM re-hash reviews, but this is just a hope and could also backfire?
<sliv3r__>
willcl-ark: that's a fair point tbh, I feel that a hidden comment + link to comment would be the best approach.
<sliv3r__>
maflcko: a bunch of LLM posting suggested changes to fix ralph comments? lol
PaperSword1 has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 269 seconds]
PaperSword1 is now known as PaperSword
<maflcko>
heh, it could also make it easier to detect and block the other re-hashing LLMs
nymius has joined #bitcoin-core-dev
vicjuma has quit [Ping timeout: 242 seconds]
<sedited>
willcl-ark I think I just prefer a single comment for all our automated tools. It just seems easier to consume and less noisy to me. Plus might still be annoying to get to on a PR with many comments once github collapses them, even with a link to it.
mercie-ux has quit [Quit: Client closed]
<sedited>
how about them in a collapsed section in the drahtbot comment?
<willcl-ark>
That's fair, and there'd certainly be a "transition period" where with existing PRs, with many comments, ralphs comment would be at the bottom. whereas on new PRs it would be right under drahtbot (most likely). I'd still favour having them on the PR at this stage myself for the reasons outlined previously, but happy to go with rough consensus on the matter.
<willcl-ark>
I think hooking up two two bots would be a bit janky. And would likely require something like ralph emitting webhooks for drahtbot so drahtbot knew when to update the collapsed section in it's own comment. I think I'd stick with the status quo vs that :)
adil has joined #bitcoin-core-dev
<maflcko>
DrahtBot should be back up today, so if there are any missing updates, lmk
adil has quit [Quit: adil]
<vasild>
That is another story, but it would be nice if the PR author can somehow show to the others that he has read and acknowledged ralf's comments. Because now other reviewers have no idea if the author paid attention and dismissed, did not pay attention.
<vasild>
_or_ did not pay attention
<maflcko>
vasild: When the feedback is valid, I ususally say "thx ralph" or so. When it is ai slop, I ignore it as a test for other reviewers to see if the fall for the ai slop.
<vasild>
:)
adil has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
adil has quit [Quit: adil]
vicjuma has joined #bitcoin-core-dev
vicjuma has quit [Quit: Client closed]
bitcoindev1337 has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
nanotube has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 254 seconds]
nanotube has quit [Ping timeout: 263 seconds]
bugs_ has joined #bitcoin-core-dev
frankomosh has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
frankomosh has quit [Ping timeout: 265 seconds]
abubakarsadiq has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
frankomosh has joined #bitcoin-core-dev
<darosior>
"might also reduce reviewers re-posting findings ralph has already flagged" -> i'm in this picture and i don't like it
<bitcoindev1337>
darosior iono if you banned me from 36761 but my comment is real, there's a balance between correctness and availability that has to be considered when changing anything about the networking logic otherwise a network partition could be made possible
<darosior>
Ralph exceeded my expectations, but i agree with sedited. I still prefer an external link (or a collapsible comment) on the Drahtbot comment at this time
<darosior>
bitcoindev1337: i can't ban people on this repo (for better or for worse heh)
<darosior>
Unsure if it's worth a ban, but the comment you left is a platitude
vasild has joined #bitcoin-core-dev
<bitcoindev1337>
darosior i mean ok but there's a number of ways a patch here could cause a targeted network split
frankomosh has quit [Ping timeout: 242 seconds]
purpleKarrot has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
viniciuscestarii has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
vicjuma has joined #bitcoin-core-dev
l0rinc_ has joined #bitcoin-core-dev
nervana21 has joined #bitcoin-core-dev
purpleKarrot has quit [Quit: purpleKarrot]
winterrdog has joined #bitcoin-core-dev
l0rinc has quit [Ping timeout: 260 seconds]
roconnor has quit [Ping timeout: 247 seconds]
memset_ has joined #bitcoin-core-dev
vicjuma50 has joined #bitcoin-core-dev
purpleKarrot has joined #bitcoin-core-dev
<darosior>
meeting?
<dzxzg>
hi
<brunoerg>
:)
<nervana21>
hi
<darosior>
cc stickies-v
<darosior>
hi i guess
<sedited>
hi
<janb84>
hi
<brunoerg>
hi
<maxedw>
hi
<viniciuscestarii>
hi
memset has quit [Remote host closed the connection]
* darosior
impersonates stickies-v "Any last minute topic?"
<dzxzg>
(also there are no pre-proposed meeting topics this week, feel free to suggest any)
b10c has joined #bitcoin-core-dev
<b10c>
hi
<dzxzg>
#topic QML GUI WG Update (johnny9dev)
stratospher_ has joined #bitcoin-core-dev
roconnor has joined #bitcoin-core-dev
<johnny9dev>
Ralph review bot was enabled on the repo posting comme ts directly and we're trying it out. I like the idea and we'll see what works and how to improve it.
<johnny9dev>
Other than that we are working through all of the PRs we have
<johnny9dev>
That's all
<nervana21>
#startmeeting
<corebot>
nervana21: Meeting started at 2026-11-05T16:09+0000
<corebot>
nervana21: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
<dzxzg>
ah haha
<dzxzg>
#topic Benchmarking WG Update (l0rinc)
<l0rinc_>
not strictly benchmarking, but pushed another step toward narrowing AssumeUTXO: #36778 replaces the loading RPC with a startup arg, so we can at least avoid all the weird corner cases of loading a UTXO set on top of an existing chainstate
<abubakarsadiq>
time change got me, sorry. Thanks @dzxzg
<sedited>
I think this is an interesting initiative, since we've seen other implementations port our existing unit tests with LLMs.
<sedited>
most chaotic meeting ^^
<sedited>
that's all.
<dzxzg>
#topic QA WG Update (brunoerg)
<brunoerg>
no update this week
<dzxzg>
last of the WG's i believe is a new one
<dzxzg>
#topic addr-relay WG update (stratospher)
<dzxzg>
I'm not sure that stratospher is here but I can say a bit
<darosior>
Go ahead, i'll ping her IRL
<b10c>
she can read, but not type
eugenesiegel has joined #bitcoin-core-dev
<dzxzg>
There has been ongoing spam of existing addresses with fresh timestamps, this pins addresses in the new table, some discussions were had recently about how to mitigate this, and a WG has been formed to move forward with these changes
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<dzxzg>
There are also some longstanding issues in Addrman that should be addressed, like the service flags problems, and address relay problems that exist because peers control the address timestamps
<darosior>
Stratospher says "hi! we have an address relay WG now. feel free to ping me if you’d like to join. (getting my IRC ready)"
<dzxzg>
OK i think there are no further WG's (speak up if I missed you)
<darosior>
#proposedmeetingtopic CVE-2026-117349 and CVE-2026-117350 followups
vicjuma has joined #bitcoin-core-dev
<dzxzg>
#topic Disk error handling inconsistencies
<stickies-v>
(cc bitcoindev1337)
<darosior>
stickies-v monitoring the situation
<bitcoindev1337>
the way disk errors are handled is extremely inconsistent depending on the exact code path that triggers the error
purpleKarrot has quit [Quit: purpleKarrot]
<bitcoindev1337>
for example anything that triggers inside the try/catch block in process messages will be ignored unless specifically handled, but if the exact same error is triggered in rpc it might cause the node to shutdown entirely
<bitcoindev1337>
some of the things ignored in the try/catch should actually cause a wallet node to abort but a non-wallet node not to abort, etc etc
<bitcoindev1337>
my point is this needs an actual plan instead of piecemeal looking at crashes
<bitcoindev1337>
im interested in other peoples thoughts on it
vicjuma54 has quit [Ping timeout: 267 seconds]
<jonatack>
bitcoindev1337: is there an RFC issue open
<jonatack>
seems worth discussing in one
<sedited>
there's many pull requests open addressing aspects of it, with a lot of discussions on the topic over the past years.
<bitcoindev1337>
i dont think so and i'd open one but i got banned for a comment on 36761
<dzxzg>
#topic CVE-2026-117349 and CVE-2026-117350 followups (darosior)
LESTERINO has joined #bitcoin-core-dev
stratospher_ has quit []
<darosior>
So we deployed patches for CVE-2026-117349 and CVE-2026-117350 last week. Thanks everyone involved in reviewing and accelerating that process. We had binaries available within about 48h of the mitigations PRs being made public, which is not bad for a first run of this new policy
<bitcoindev1337>
i'll take a look at those and see what's already been discussed thank you
strat___ has quit []
<darosior>
Now that those were made available, i'm curious if anyone has been thinking about cleanups, as well as improving our testing / understanding there?
stratospher has joined #bitcoin-core-dev
<stratospher>
hi?
<darosior>
stratospher: pong
<darosior>
Cleanups because those were merely stopgaps, we should aim to fix those issues more fundamentally now that the dust settled down. For instance for CVE-2026-117349, the root cause is that we have unbounded growth in some p2p data structure. We fixed it with a timer to keep the growth manageable, but this is brittle, we should aim to have bounds on
<darosior>
the memory usage peers can impose on us
<darosior>
I've been working on this for CVE-2026-117350, hardening our tests in this area, and i opened #36761 to discuss longer term cleanups
<bitcoindev1337>
darosior like the select/poll thing that's a surprisingly hard thing to do without accidentally disconnecting legitimate peers
<darosior>
bitcoindev1337: i think always disconnecting on polling errors is fine, just not ideal for the http server
purpleKarrot has joined #bitcoin-core-dev
LESTERINO has quit [Client Quit]
<darosior>
But we should be consistent, and document our choices, and test our invariants, to prevent something similar to happen in the future because barely anyone remembers how it works in details, and then such a surprise happens
<eugenesiegel>
are you specifically seeking feedback about poll/select or other things also related to sockets ?
<darosior>
I am curious what everyone thinks we should do about those, and i have one more question i'm typing now
svanstaa16 has joined #bitcoin-core-dev
<darosior>
Like just deploying the stopgap and forgetting about those will come back to bite us
<darosior>
I've also been looking into post CVE-2026-117349 cleanups, and that would be some non completely trivial refactorings, but doable. However i have other things i'd like to work on that i temporarily dropped for the security releases, and these hardenings, so i'd like to know if there is any will to review such refactorings before i commit more time
<darosior>
to implementing those
<sedited>
what did roughly did you have in mind?
<darosior>
For 117349?
<jonatack>
yes
vicjuma has quit [Ping timeout: 266 seconds]
<sedited>
ja
<dzxzg>
I'd help review, I agree that leaving it mitigated and poorly understood leaves dangerous technical debt
luke-jr has quit [Read error: Connection reset by peer]
Murch[m] has quit [Changing host]
Murch[m] has joined #bitcoin-core-dev
<darosior>
sedited: 1) changing the tx INVs token bucket manager to use a single, bounded queue for all peers. Each peer keeps its cursor. 2) moving the parts of SendMessages() that actually pile up messages for peers towards the end, and early return on fPauseSend to not reach those
vicjuma has joined #bitcoin-core-dev
luke-jr has joined #bitcoin-core-dev
<darosior>
It's just incredibly surprising that fPauseSend does not pause SendMessages(), but there are good reasons for doing so currently
<darosior>
3) some minor cleanups for other less frequent announcements
<eugenesiegel>
I could review as a backup if I'm able to clear some of my backlog. I think fundamentally fixing these issues is the right idea. I also think the socket code deserves more scrutiny
tfl0pz has joined #bitcoin-core-dev
<jonatack>
darosior: feel free to ping me to review the PR
<darosior>
sedited: but it's just one half-baked idea, which is why i ask here, my thoughts have mostly been on #36761 the past couple weeks.