Guyver2 has left #bitcoin-core-dev [Closing Window]
purpleKarrot has quit [Quit: purpleKarrot]
jerryf_ has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
jerryf_ has joined #bitcoin-core-dev
jerryf has quit [Ping timeout: 249 seconds]
jerryf_ has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
purpleKarrot has joined #bitcoin-core-dev
mercie-ux has joined #bitcoin-core-dev
memset_ has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
memset_ has quit [Remote host closed the connection]
mercie-ux has quit [Quit: Client closed]
sliv3r__ has joined #bitcoin-core-dev
sliv3r__- has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
_andrewtoth_ has joined #bitcoin-core-dev
memset_ has joined #bitcoin-core-dev
BlueMatt has joined #bitcoin-core-dev
BlueMatt_ has quit [Ping timeout: 240 seconds]
andrewtoth_ has quit [Ping timeout: 257 seconds]
memset has quit [Remote host closed the connection]
<darosior>
Sadiq W
flooded has quit [Read error: Connection reset by peer]
<willcl-ark>
that's nice
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
<darosior>
Received the CVE ids for the accelerated disclosures, and i've got a quick website technicality Q
<darosior>
Should i rename the post filename to use the CVE id as we've almost always done in the past, and add a "redirect-from" from the previous name in the Markdown header? Or would that break something?
<darosior>
I can also just change the post title
<fanquake>
If we've been doing that previously, should be fine?
<fanquake>
Although just changing the post name sounds simpler
<darosior>
And redirect from the filename that would have been had we had the CVE ids earlier
<darosior>
Yeah ok i'll do the latter then
<darosior>
I'll change the post title and throw a redirect in the dark. If it works, good, if it doesn't it's not a huge deal since all other links will use the pre-existing filename
purpleKarrot has quit [Quit: purpleKarrot]
pinheadmz[m] has quit [Ping timeout: 240 seconds]
BlueMattMtrxBot has quit [Ping timeout: 240 seconds]
Sjors[m] has quit [Ping timeout: 253 seconds]
BlueMatt[m] has quit [Ping timeout: 243 seconds]
bitcoin-git has quit [Ping timeout: 243 seconds]
stratospher[m]1 has quit [Ping timeout: 243 seconds]
Murch[m] has quit [Ping timeout: 246 seconds]
bugs_ has joined #bitcoin-core-dev
laanwj has quit [Ping timeout: 265 seconds]
b10c[m] has quit [Ping timeout: 272 seconds]
<darosior>
Are we going to have the bot back at some point?
bitcoinninjatest has quit [Ping timeout: 266 seconds]
Murch[m] has joined #bitcoin-core-dev
<lightlike>
pinheadmz: what what the name again of the channel with your alternative bot? I always join when the bot is down and leave/forget the name once it is back...
<pinheadmz>
#bitcoin-core-github
<lightlike>
thanks!
<darosior>
Thanks
purpleKarrot has joined #bitcoin-core-dev
pinheadmz[m] has joined #bitcoin-core-dev
Sjors[m] has joined #bitcoin-core-dev
BlueMattMtrxBot has joined #bitcoin-core-dev
b10c[m] has joined #bitcoin-core-dev
stratospher[m]1 has joined #bitcoin-core-dev
BlueMatt[m] has joined #bitcoin-core-dev
laanwj has joined #bitcoin-core-dev
bitcoinninjatest has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
janb84 has quit [Remote host closed the connection]
janb84 has joined #bitcoin-core-dev
Guest23 has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
Guest23 has quit [Ping timeout: 261 seconds]
nymius has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
eugenesiegel4 has joined #bitcoin-core-dev
nymius has quit [Quit: nymius]
viniciuscestarii has joined #bitcoin-core-dev
memset has joined #bitcoin-core-dev
memset_ has quit [Remote host closed the connection]
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
durandal__ has quit [Quit: Leaving]
durandal_ has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
eugenesiegel4 has quit [Ping timeout: 247 seconds]
pseudoramdom has joined #bitcoin-core-dev
bitcoin-git has quit [Ping timeout: 245 seconds]
laanwj has quit [Ping timeout: 245 seconds]
stratospher[m]1 has quit [Ping timeout: 253 seconds]
BlueMattMtrxBot has quit [Ping timeout: 253 seconds]
Sjors[m] has quit [Ping timeout: 253 seconds]
bitcoinninjatest has quit [Ping timeout: 257 seconds]
Murch[m] has quit [Ping timeout: 253 seconds]
<stickies-v>
#startmeeting
<corebot>
stickies-v: Meeting started at 2026-10-29T16:00+0000
<yancy>
I've submitted some small patches over the years, but never really been clear on that
<instagibbs>
stickies-v +1, good work to everyone including builders for being available to get it done
<yancy>
and the user docs on contributing doesn't really say anything of use
smartin has quit [Ping timeout: 240 seconds]
smartin2 is now known as smartin
<stickies-v>
afaic it's not documented explicitly no, it's also really hard to quantify that in exact non-gameable criteria
<stickies-v>
*afaik
<yancy>
got it
l0rinc_ has joined #bitcoin-core-dev
<yancy>
in othere projects, there's sort of a two maintaner ack policy sometimes
l0rinc has quit [Read error: Connection reset by peer]
<stickies-v>
despite how quickly and seemingly smooth this release went, i wonder if there are things we can do to make it easier / more automated, so we can continue to quickly publish releases when necessary
<yancy>
wasn't sure what it might be in core since I've never observed any pattern
bitcoin-git has joined #bitcoin-core-dev
<vasild>
yancy: there is _some_ reasoning in CONTRIBUTING.md, under "Decision Making" Process
<yancy>
brunoerg these are some interesting mutations. I feel like this might actully be something an LLM might be good at writing fixes for.
<stickies-v>
e.g. i think one unnecessary point of friction is that release notes are reviewed in the PR, and then again during a release. the release is often months after a PR was merged, so almost no one still has good context on that change. i feel like it makes more sense to just only review release notes in the first PR, and then the final release notes is a purely mechanistic aggregation of all those excerpts
laanwj has joined #bitcoin-core-dev
bitcoinninjatest has joined #bitcoin-core-dev
<stickies-v>
this might require some more (llm-lintable) rules on release notes in PRs, e.g. make sure they are assigned to an appropriate category, are complete, etc
<vasild>
stickies-v: +1
pseudoramdom has quit [Remote host closed the connection]
b10c[m] has joined #bitcoin-core-dev
<yancy>
vasild yeah, I've read that. I was just looking for feedback on if there was or wasn't a ACK merge policy, and it doesn't sound like there is.
BlueMatt[m] has joined #bitcoin-core-dev
pinheadmz[m] has joined #bitcoin-core-dev
<instagibbs>
PRs can sit around for a long time for various reasons
<instagibbs>
including lack of attention by reviewers
<yancy>
for sure. Shame reviewers :P
<stickies-v>
can't remember the last time i saw a pr that was RFM and then not merged reasonably quickly; it's always lack of review/consensus in my experience
BlueMattMtrxBot has joined #bitcoin-core-dev
Murch[m] has joined #bitcoin-core-dev
stratospher[m]1 has joined #bitcoin-core-dev
Sjors[m] has joined #bitcoin-core-dev
nymius has joined #bitcoin-core-dev
<stickies-v>
alright, looks like that's it for this week. thanks everyone
<stickies-v>
#endmeeting
<corebot>
stickies-v: Meeting ended at 2026-10-29T16:19+0000
winterrdog has quit [Remote host closed the connection]
<jonatack>
hi
<eugenesiegel>
instagibbs: might not have time to review soon (trying to add a feature to fuzzamoto), but after that's done I can
jonatack has quit [Quit: WeeChat 4.10.1]
<instagibbs>
cool, v33 is target for follow up which fixes the most egregious issues with few loc
mercie-ux has joined #bitcoin-core-dev
<ghost43>
Hey. I have just upgraded a server from bitcoind 31.1 to 32.1, and seeing some weird hangs with RPC calls. I guess due to the http server rewrite (?).
<ghost43>
First I suspected it is due to higher "rpcthreads" and "rpcworkqueue" conf settings I have but now I can reproduce even without that. I have an ElectrumX hammering the bitcoin core rpc via json-rpc, and that seemingly works well, but if I run "$ bitcoin-cli help" or any other command via the cli, that hangs forever.
<ghost43>
I have the same setup on different testnets but the issue only manifests on mainnet, presumably due to higher load on the RPC server there.
<ghost43>
I have debug logs for "rpc" and "http" enabled and based on that my "bitcoin-cli" invocations do not even seem to reach bitcoind. If I restart bitcoind, for the first minute or so, "bitcoin-cli" responds, but I guess when ElectrumX starts hammering the RPC again, "bitcoin-cli" hangs. I have never seen this in older versions of bitcoind.
smartin has quit [Ping timeout: 250 seconds]
smartin has joined #bitcoin-core-dev
<pinheadmz>
ghost43 try higher -rpcmaxconnections
<pinheadmz>
does ElectrumX reuse HTTP conenctions (i.e. a single keep-alive connection for all requests over the lifetime?)
<pinheadmz>
or does hammering mean, many indepenedant, ephemeral, connections from different local ports
<darosior>
ghost43: but the hammering ElectrumX does make progress right? So your issue is the additional connection through bitcoin-cli is never prioritized?
<ghost43>
ElectrumX seems to be happy. my local "bitcoin-cli" call hangs for 10+ minutes (haven't tried waiting longer)
<pinheadmz>
DEFAULT_MAX_HTTP_CONNECTIONS is 16. so if electrumX fills all those slots with long lasting connections, additional clients will not connect
deadmanoz has joined #bitcoin-core-dev
deadmano- has quit [Ping timeout: 244 seconds]
<ghost43>
pinheadmz: hmm, just set "rpcmaxconnections=256" and that makes the issue go away indeed
<pinheadmz>
great. well maybe we picked too low a deafult
<pinheadmz>
the impact is requesting higher file descriptor limit from the system
<ghost43>
it has that "workqueue_semaphore" that is set to 10, so I would have expected 10 concurrent ephemeral sessions then? not sure
<ghost43>
well actually it only has a single aiohttp.ClientSession, it is supposed to be multiplexing 10 concurrent RPC calls onto that single sessions... hmm. anyway, thanks for the workaround! I will investigate
<pinheadmz>
thanks for reporting, im gonna look into it as well
eugenesiegel has quit [Quit: Client closed]
smartin2 has joined #bitcoin-core-dev
smartin has quit [Ping timeout: 241 seconds]
smartin2 is now known as smartin
jurraca has joined #bitcoin-core-dev
jurraca has quit [Client Quit]
<ghost43>
pinheadmz: ah ok it's that aiohttp.ClientSession is actually managing a pool of connections, it's not a single session :D
<darosior>
The issue of requesting too high file descriptors goes away once we finally ditch select()..
<pinheadmz>
but just 10 connections right?
<ghost43>
"limit (int) – total number simultaneous connections. If limit is 0 the connector has no limit (default: 100)."
<pinheadmz>
oh
<ghost43>
(electrumx is using the defaults. this limit of 100 comes from the aiohttp lib)
<pinheadmz>
when you were hammering, electrumx max_workqueue was still just the default 10? were you running more than one electrumx process?
purpleKarrot has quit [Quit: purpleKarrot]
<ghost43>
pinheadmz: ahhhh, I forgot I have a second private electrumx running next to the prod one, that I use to test things xD that one has no traffic but it must have also soaked up some slots indeed
<ghost43>
with that shut down, actually even the default 16 slots seem to be enough
<pinheadmz>
ok! things making sense!
<ghost43>
sorry
<pinheadmz>
no no, alllll good.
<ghost43>
that also explains why I was not seeing the issue on any of the testnets. mainnet is the only network where I don't directly test on the production instance (so there is this second one running in parallel) :D
<pinheadmz>
darosior select/poll both still need fds to connect, that amount is still capped by the platform but since #35730 we can actually prevent the user from crashing bitcoin by opening too many http connections