Guyver2 has left #bitcoin-core-dev [Closing Window]
winterrdog has quit [Ping timeout: 256 seconds]
jadi has quit [Read error: error:0A000139:SSL routines::record layer failure]
jadi has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
smartin has joined #bitcoin-core-dev
jadi has quit [Read error: Connection reset by peer]
jadi has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
bomb-on has quit [Read error: Connection reset by peer]
bomb-on has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] vasild opened pull request #35510: test: SOCKS5 proxy: expect that connection may be reset when forwarding (master...socks5_forward_sockets_handle_reset) https://github.com/bitcoin/bitcoin/pull/35510
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
Yoshikage has joined #bitcoin-core-dev
Yoshikage has quit [Remote host closed the connection]
Yoshikage has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hodlinator opened pull request #35511: RFC: consensus: Make `CAmount` a class (master...2026/06/safer_camount.take2) https://github.com/bitcoin/bitcoin/pull/35511
Cory5 has quit [Quit: Client closed]
Cory5 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] polespinasa opened pull request #35512: wallet: move fAbortRescan reset into WalletRescanReserver reserve function (master...2026-06-11-movefAbortRescan) https://github.com/bitcoin/bitcoin/pull/35512
hulxv_ has left #bitcoin-core-dev [#bitcoin-core-dev]
hulxv has quit [Quit: hulxv]
sliv3r__- has quit [Ping timeout: 245 seconds]
sliv3r__ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 248 seconds]
l0rinc has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
smartin has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
GoldenGoose has joined #bitcoin-core-dev
l0rinc has quit [Client Quit]
uqlidi has joined #bitcoin-core-dev
<sipa>
FYI, Chaincode is currrntly on an offsite, si several of us won't be able to attend the mweting
GoldenGoose has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] hebasto opened pull request #35515: cmake: Use target file name for manpage installation (master...260611-cmake-install) https://github.com/bitcoin/bitcoin/pull/35515
GoldenGoose has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
ViniciusCestarii has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
<stickies-v>
ty for the heads-up sipa!
<stickies-v>
#startmeeting
<corebot>
stickies-v: Meeting started at 2026-06-11T16:00+0000
<andrewtoth>
Got some good review on #35295. We are also now continuously fuzzing leveldb along with concurrent reads, which is used for chainstate reads in that PR. More review welcome.
<corebot>
https://github.com/bitcoin/bitcoin/issues/35295 | validation: fetch block input prevouts in parallel during ConnectBlock by andrewtoth · Pull Request #35295 · bitcoin/bitcoin · GitHub
<andrewtoth>
that's it
<kanzure>
hi
<dergoegge>
hi
<stickies-v>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
no update
<eugenesiegel>
hi
<stickies-v>
I don't see any other WG leaders here, so that concludes the WG section unless anyone pops in last-minute
<sedited>
not sure if that makes sense without a release.
<andrewtoth>
Do we want to let users know about workarounds before a release?
<stickies-v>
alerting earlier seems useful to me too, especially since the vulnerability is public already anyway
<sliv3r__>
I think it makes sense anouncing before a release
<andrewtoth>
I don't think that blog post would make sense as is with a release, since the best workaround would be to upgrade
<sliv3r__>
agree, didn't read in detail the post but it basically gives workarounds until a fix is released, makes sense to publish it as soon as it is ready
<stickies-v>
i think it would be useful if more contributors at least concept ack'd blog posts, not that this one seems controversial
<sedited>
ok
<eugenesiegel>
should this not have been public? afaict the security mailing list isn't for privacy issues. anybody have an idea on the preferred way to handle this?
<andrewtoth>
all things considered it would be better IMO if this were not yet public
<andrewtoth>
but, not sure how we would have made a fix without revealing it
<instagibbs>
there are ways of doign so, but horse is out of the barn long ago
<andrewtoth>
since it is public, it would be good to get info about it out
<stickies-v>
alright, looks like we're done here. thanks for bringing it up andrewtoth
<andrewtoth>
what is holding up a 31.1 release?
<Murch[m]>
31.1 should be out soon, right?
<stickies-v>
(okay not done)
<Murch[m]>
I just took a look at the milestone, all the todos seem to be checked off
<dergoegge>
eugenesiegel: This was fine to be public imo
uqlidi9 has joined #bitcoin-core-dev
<sedited>
I think we were waiting on #35465
<Murch[m]>
Ah sorry, the list of backports refers to merged PRs, but the PR is still draft
<Murch[m]>
While it seems reasonable to judge code contributions on their own merit, it also seems reasonable that extremely uncharitable behavior in other avenues should at some point be addressed.
<Murch[m]>
Anyway, if people haven’t seen that conversation yet, maybe take a look
<Murch[m]>
:s/though/thought/
<instagibbs>
thanks for bringing it up
<Murch[m]>
Like, more concretely, if someone has been accusing us (without evidence) of crimes and shitting on our project in public for years, why should we continue to platform them in our repository?
<Murch[m]>
I can’t think of any other situation in life where this sort of behavior would be acceptable