<bitcoin-git>
[leveldb-subtree] fanquake merged pull request #52: Revert "Increase maximum read-only mmap()s used from 1000 to 4096 on 64-bit systems" (bitcoin-fork...2025-05-revert-mmap-increase) https://github.com/bitcoin-core/leveldb-subtree/pull/52
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] rkrux opened pull request #35404: wallet: allow anti-fee-sniping in sendall RPC while not relying of RBF default (master...antifeesniping) https://github.com/bitcoin/bitcoin/pull/35404
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
<darosior>
Regarding the compaction trigger at the end of IBD, i think a neat heuristic could be to use the chain work. The first time we are done connecting a chain that has at least nMinimumChainWork, run the compaction.
<darosior>
That way it gets updated every release. This is not perfect, but loosely tracks where we expect IBD to end. People performing IBD with older versions would compact too early, but that's not the end of the world. If somebody really needs to run compaction for whatever reason, there is always the startup option to force it.
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<andrewtoth_>
So, the first time we cross over from a block that is > minimum chain work we trigger it? That way we don't have to store anything new in the db?
<andrewtoth_>
*from a block the is < minimum to > minimum
nervana21 has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Changing host]
pseudoramdom has joined #bitcoin-core-dev
ViniciusCestarii has joined #bitcoin-core-dev
<stickies-v>
#startmeeting
<corebot>
stickies-v: Meeting started at 2026-05-28T16:00+0000
<sedited>
Still not happy with the code for the split though, the interface for accesing back into the mempool and grabing its locks is very clunky.
<maxedw>
hi
<kanzure>
hi
<johnny9dev>
hi
<stickies-v>
nice, will get back to reviewing 32427 asap, would be a nice improvement for kernel
<sedited>
not sure how interested people are in this split in the first place. The code-organizational benefits are kind of nice, but beyond that the utility for the Bitcoin Core software are a bit questionable.
<sliv3r__>
hi
<darosior>
"Mempool eviction? -Yes but the one you are thinking about"
<darosior>
not*
<sedited>
indeed :)
<darosior>
If it's a win for the Kernel library, and Bitcoin Core is no worse off, that seems fine?
epicleafies has joined #bitcoin-core-dev
nervana21 has quit [Quit: Client closed]
<stickies-v>
yeah i think it's a pretty big improvement for kernel users
<sedited>
I might open it as a RFC PR , keeping it rebased is a challenge, but it's also kind of nice to ensure on a regular basis that such a split is possible in the first place.
<stickies-v>
an RFC issue might make more sense?
<sedited>
not sure, I think most would agree that it is a good thing on the face of it, so I more think it's the refactoring price that needs to be gauged here.
<sipa>
hi
<stickies-v>
linking a branch from an issue seems fine, but then at least you're not wasting time rebasing / addressing nits
<stickies-v>
anyway
<stickies-v>
anything else here?
<sedited>
that's all
<stickies-v>
#topic Benchmarking WG Update (l0rinc, andrewtoth)
<andrewtoth_>
l0rinc is out but he said he is working on an automated compaction PR
<andrewtoth_>
I relayed darosior's idea to use minimum chain work as a trigger
<andrewtoth_>
I also have come around to thinking a ~weekly automated compaction would be good
<sedited>
what would be wrong with just repeatedly checking isibd?
<andrewtoth_>
that would trigger every startup too, which would not be ideal
<sipa>
andrewtoth_: 1 week worth of blocks is mayhe 2 GB of block data, a full rewrite every week would add a multiple of that
<sipa>
or do we necessarily already have much morr
<andrewtoth_>
sipa: the chainstate adds < 200MB a week to the db if uncompacted
nervana21 has joined #bitcoin-core-dev
<andrewtoth_>
err I'm not sure how you mean block data to be relevant here?
<sipa>
yeah, i'm just trying to gauge how much a weekly full rewrite of the chainstate would add in terms of disk activity
<darosior>
For disk IO i think?
<andrewtoth_>
I think today it will be like 10-15 GB of write IO per full compaction
<sipa>
yes, which is a multiple of what i expect we'd do without
<Murch[m]>
Why once per week rather than say, once per month?
<andrewtoth_>
we can definitely bikeshed on how often to do it. could be monthly
<stickies-v>
what about thriweekly
<sipa>
rewrite at the end of IBD, once, is more impactful i think
<darosior>
stickies-v: hah
<sipa>
stickies-v: whenever the last block hash ends in 12 zero bits
<sedited>
^^
<andrewtoth_>
yes agreed end of IBD is important. but, saving users an extra 11% for a full compaction every so often seems worth it?
<Murch[m]>
sipa: Probably better if not everyone does it at the same height
<b10c>
murch: agree
<darosior>
Once a month seems fine, and then no need to do it at the end of IBD
<sipa>
yeah, sorry, i didn't mean to start a bikeshed here... i'm just not very convinced doing it regularly adds much, and probably adds a relatively large amount of disk activity still
<sipa>
Murch[m]: absolutely, it was a joke :)
<andrewtoth_>
i think post-IBD alone is important, since a user might shut off and never keep it running for a whole month after that
<Murch[m]>
E.g., do it once after IBD finishes, then schedule it for a random height 3500–5000 blocks later again
<Murch[m]>
Would probably be bad if all nodes did it at the same height
<andrewtoth_>
Murch: I think that's nearly the approach l0rinc is taking now
<darosior>
andrewtoth_: you would advise doing both? I was hoping for either or
<Murch[m]>
From reading the topic last week, my impression was that the db is bloated by several GB at the end of a full IBD
<Murch[m]>
So, tracking that you started a new IBD and doing it once when you have caught up to the chaintip sounds pretty useful?
<andrewtoth_>
i was thinking both, yes...
<darosior>
If we do it once at the end of IBD, how much do you expect it would help to do it regularly on top? Like if it's done once around block 950k, how much disk space would doing it around block 1M would really save?
<andrewtoth_>
if I had to choose one, it would be post-IBD
<andrewtoth_>
11% of disk space
<andrewtoth_>
we save ~30% doing it immediately after IBD, then it's a slow creep up to 11% total
<andrewtoth_>
a periodic compaction will trim that 11%
<Murch[m]>
and then ~200 MB per week, roughly?
<andrewtoth_>
Murch: up until 11%, it gets capped
<darosior>
Ok. No opinion here. I don't think it matters much either way.
<andrewtoth_>
I feel like post-IBD can be the initial change, then we can bikeshed more on periodic compaction.
<Murch[m]>
Well, every week seems a bit aggressive, but either way it would be a huge improvement over doing it every hour
<andrewtoth_>
ok, thanks for the feedback everyone
<andrewtoth_>
otherwise, got some great review on #35295, thanks! will address that soon
<pinheadmz>
#35182 is real close. addresed some nits yesterday and restarted integration testing. already have a few small follow-ups in the queue.
<corebot>
https://github.com/bitcoin/bitcoin/issues/35182 | Replace libevent with our own HTTP and socket-handling implementation by pinheadmz · Pull Request #35182 · bitcoin/bitcoin · GitHub
<pinheadmz>
And libevent removal from client was merged yay
<pinheadmz>
Hoping to merge with enough time before release to find anything wrong
<pinheadmz>
All from me
<stickies-v>
#topic QML GUI WG Update (johnny9dev)
<johnny9dev>
We continue to be on track for our "Preview" unsigned builds in June . The related work for that can be found at https://github.com/orgs/bitcoin-core/projects/1/views/2 and I updated it this morning so it is accurate. We have wallet updates from pseudoramdom and epicleafies and node error dialogs and block status updates from me in review. Afterwards the high runners are updating the project to v31 and validating the settings and
<johnny9dev>
onboarding is compatible with bitcoin-qt installs.
<johnny9dev>
That's all from me
<stickies-v>
alright, thanks for the updates everyone
<stickies-v>
anything else to discuss?
pseudoramdom has quit [Quit: pseudoramdom]
<abubakarsadiq>
novo asked me to relay silent payments update
<instagibbs>
IIUC point release for 31.x is held up on #35319, so let's try and get that done?
<Murch[m]>
One follow-up to the compaction: if the mechanism is to schedule it for specific heights, you could schedule the first compaction for a height slightly after the chaintip of the best header chain once the node has acquired one, but delay the compaction until we are no longer in IBD.
<Murch[m]>
Or maybe just scheduling it for the regular ~x thousand block interval but waiting until you are no longer in IBD would be enough to do one after IBD
<eugenesiegel>
I tried making a functional test that built on top of p2p_private_broadcast.py, but it did not go well. I had issues with the Socks5 proxy and reconnection code, hopefully vasild has a better approach
<instagibbs>
vasild any ETA on your version of the test, even with cleanups TODO
<andrewtoth_>
Murch: we need to make sure we only trigger it one time, so using a gauge like previous work was < minimum now work is > minimum could work for that
<andrewtoth_>
otherwise it will trigger every startup
<stickies-v>
will wrap up the meeting here, but conversations can of course continue
<stickies-v>
#endmeeting
<corebot>
stickies-v: Meeting ended at 2026-05-28T16:33+0000
<Murch[m]>
If it doesn’t run while we are in IBD and is scheduled for ~x thousand blocks later every time it runs, I don’t see why it would run every time we start up?