<bitcoin-git>
bitcoin/master de92208 Ava Chow: migrate: Handle HD chains that have identical seeds but different IDs
<bitcoin-git>
bitcoin/master 0e95e1a merge-script: Merge bitcoin/bitcoin#35437: migrate: Handle HD chains that have identical...
<bitcoin-git>
[bitcoin] fanquake merged pull request #35437: migrate: Handle HD chains that have identical seeds but different IDs (master...fix-dup-seeds-migration) https://github.com/bitcoin/bitcoin/pull/35437
brunoerg has joined #bitcoin-core-dev
GoldenGoose has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
brunoerg has quit [Ping timeout: 244 seconds]
cotsuka has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
rustaceanrob has quit [Ping timeout: 248 seconds]
cotsuka has joined #bitcoin-core-dev
hacker4web3bitco has quit [Ping timeout: 252 seconds]
l0rinc has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
yuvicc has joined #bitcoin-core-dev
yuvicc has quit [Changing host]
yuvicc has joined #bitcoin-core-dev
pseudoramdom has quit [Changing host]
pseudoramdom has joined #bitcoin-core-dev
ViniciusCestarii has joined #bitcoin-core-dev
nervana21 has joined #bitcoin-core-dev
musaHaruna has joined #bitcoin-core-dev
<stickies-v>
#startmeeting
<corebot>
stickies-v: Meeting started at 2026-06-18T16:00+0000
<sipa>
i'm in favor of backporting 35465, though waiting for benchmarks seems useful
<andrewtoth>
thanks for all review on #35295. 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
rustaceanrob has joined #bitcoin-core-dev
<andrewtoth>
sipa: same
<andrewtoth>
Talking with 0xb10c, he has been running with seek compaction disabled and sees performance improvements all around
<sedited>
nice
<andrewtoth>
lower disk IO, no compactions on CPU in background, and faster block connection
<andrewtoth>
that's it from me
<sipa>
l0rinc: i have a patched tree which should force leveldb into one of its 4 table cache regimes based on a macro, would you be interested in benchmarking them?
<l0rinc>
sweet. I emailed one of the LevelDB maintainers for a review - let's see if he can help us out with a review
<Murch[m]>
Awesome
<l0rinc>
of course, I just bought 3 new servers
<yancy>
hi
<sipa>
alright, i'll do some minimal testing, and explain what would be useful to look at out of band
<stickies-v>
#topic QML GUI WG Update (johnny9dev)
<johnny9dev>
We have 4 PRs in review right now and once those are finished and merged we will be ready to start sharing preview builds
<johnny9dev>
I think I've decided to sign those builds myself and do our best to have a big warning on them to make it clear of the purpose. That being to get feedback and help address UX issues early
<johnny9dev>
hebasto and I have also started work on how to construct the "staging" branch that will end up being what we PR
<Murch[m]>
Excited to see the preview!
<johnny9dev>
the rough idea for that is to pull the commits from gui-qml on top of bitcoin/bitcoin using filter-branching and ammending the commits with backport-style metadata "Rebased-From" and "Github-Pull"
<johnny9dev>
we should have more to share on that next week. I hope to be able to have python scripts available to reproduce the staging branch from the gui-qml repo. We want to do what we can to make the review process go smoothly
<johnny9dev>
the messier part will be the patching of earlier commits to make this buildable throughout. working on some ideas to make that work
<Murch[m]>
How can people not involved in the GUI code help?
<Murch[m]>
I assume spinning it up and going through their own usual workflows and noting any feedback would be a start?
<johnny9dev>
w'll have lots of things to get feedback on very soon with the preview release and our staging branch
<sipa>
johnny9dev: cool
<fanquake>
Is the idea that the staging branch has already been reviewed, and is just being merged, or is it going to be split up and re-reviewed?
<johnny9dev>
something in between. the link to what was reviewed should mean alot of the code has already has eyes on it and reviewed but there will be the integration pieces with making this line up with the rest of bitcoin/bitcoin that should get some review on too
<johnny9dev>
things like the python scripts for gui testing, the cmake files, and the build config flags
<johnny9dev>
guix buids and new depends
<fanquake>
Just wondering, because if stuff is being re-reviewed anyways, don't think you need all the metadata pointing to other commits, that haven't been merged/might not have been reviewed anyways
<johnny9dev>
every commit has had a review other than the scaffolding to get it to align with bitcoin/bitcoin's cmake and depends
<johnny9dev>
im confused by what you mean about re-review. i dont think it will be necessary to re-review most of the historical commits of the project
<johnny9dev>
and the links to the old PR reviews will be there so it can be understood how the application was built up
<johnny9dev>
the goal being to limit what exactly needs to be reviewed in the PR
<fanquake>
I'm not sure. I don't what the review quality has been on the qml repo. So I don't know if something has been "reviewed" and should just be merged into bitcoin/bitcoin if it has 1 ACK from a contributor I've never heard of, in a different repo. Not a blocker now anyways, will see what you come up with
<johnny9dev>
yes ill try to have more clarity and an example next week
<stickies-v>
#topic LevelDB block cache (sipa)
<sipa>
I spent some time trying to dig into all the ways the different LevelDB resource limits (open files, file descriptors, mmap regions) interact (see https://github.com/bitcoin-core/leveldb-subtree/pull/63#issuecomment-4735688019), and discovered something surprising: in our typical builds, the block cache is entire unused.
pseudoramdom has quit [Remote host closed the connection]
<sipa>
It looks like (though can use some more verification) that the cache is only used when either the table files are compressed on-disk (which we disable) or mmap() cannot be used (so, just on 32-bit platforms).
<sipa>
So maybe the complex cache-distribution logic (eg #34646) can be simplified/dropped in light of that.
<sipa>
That's it, just wanted to give it some attention.
<sedited>
I saw your comment and have been trying to see if there is any difference in performance, couldn't see one so far (probably should have done that when looking at the pull request :P)
<sipa>
("block" here is LevelDB table file blocks, not Bitcoin blocks)
<andrewtoth>
alternatively we can just transfer the amount reserved for table cache to the memtable?
<sipa>
andrewtoth: yeah
<andrewtoth>
(I think l0rinc has been experimenting with that)
<sipa>
though there are other interactions too, where the max_open_files limit passed to LevelDB may have a substantial impact on memory usage (depending on mmap or not) too, outside of the block cache.
<sipa>
So we may want to rethink more generally how memory usage is accounted for and distributed.
<sedited>
is there a table cache knob?
<sipa>
max_open_files is effectively the knob for how many table files the database memory structure has cached
<sipa>
and the per-file memory impact depends on whether it's opened through mmap or not, and how big the file is
<sipa>
which does mean that by increasing the table file size to 32 MiB, we may have inadvertently also increased base memory usage (though, probably not much, because it's only set high on mmap-capable platforms where the impact isn't large)
<andrewtoth>
sedited: there are knobs in GetOptions in dbwrapper.cpp
<andrewtoth>
I think block_cache is useless, is what sipa is saying, and write_buffer_size can take more of that memory?
<sedited>
yes, just wasn't caught up on the mechanics that sipa just described.
<sipa>
That's it for me. We can discuss more on the relevant PRs.
<stickies-v>
Anything else to discuss?
<b10c>
my vibe-coded https://github.com/0xb10c/bitcoind-gunix side-project is now able compile all binaries and tarballs for v31.0 byte-for-byte in Nix, without any byte-patching needed. The Nix SHA256SUMS match the Guix SHA256SUMS
<b10c>
Not sure about the future of this project yet, but pretty cool to see that this is even possible
<sipa>
b10c: woah
<sedited>
cool!
<janb84>
fun
<yuvicc>
great!
<Murch[m]>
Since there are a lot of BIP authors here. I have started looking over BIPs in Draft to see if some of them should be advanced to Complete or should be Closed. If you have Draft BIPs that you think should be advanced to a different status, you could help by opening a PR yourself :)
<fanquake>
b10c: what is left to do on the nix bootstrapping front? Or is that already solved?
<fanquake>
I did see something recently about re-using guix packages in nix, or vice-versa (cc willcl-ark)
<b10c>
fanquake: I haven't checked in a while. Will have a look at some point!
<jonatack>
Murch[m]: +1 good idea
<stickies-v>
looks like we're all done here. thanks everyone for chiming in!
<stickies-v>
#endmeeting
<corebot>
stickies-v: Meeting ended at 2026-06-18T16:41+0000
cotsuka has quit [Read error: Connection reset by peer]
yuvicc has quit [Quit: yuvicc]
<l0rinc>
sipa: I have experimented a while ago with setting the leveldb block cache and I couldn't measure any difference. I assumed it was the OS file caching.
cotsuka has joined #bitcoin-core-dev
nervana21 has quit [Quit: Client closed]
pzafonte1 has quit [Quit: leaving]
l0rinc has quit [Quit: l0rinc]
ViniciusCestarii has quit [Quit: Client closed]
<sipa>
l0rinc: does not surprise me
<sipa>
i vaguely recall experimenting with it too, very long ago, when introducing it, and not measuring much
<sipa>
so that's why they're not particularly large numbers
l0rinc has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
ShebaLamb has joined #bitcoin-core-dev
ShebaLamb has quit [Ping timeout: 264 seconds]
<bitcoin-git>
[gui] pablomartin4btc opened pull request #941: bugfix: Close transaction detail windows when switching wallets (master...gui/close-tx-windows-on-wallet-switch) https://github.com/bitcoin-core/gui/pull/941
ShebaLamb has joined #bitcoin-core-dev
ShebaLam1 has joined #bitcoin-core-dev
ShebaLamb has quit [Ping timeout: 246 seconds]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
darosior has quit [*.net *.split]
ChanServ has quit [*.net *.split]
darosior has joined #bitcoin-core-dev
ChanServ has joined #bitcoin-core-dev
maxedw_ is now known as maxedw
cotsuka has quit [Read error: Connection reset by peer]
troyam has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
troyam has quit [Client Quit]
troyam has joined #bitcoin-core-dev
ShebaLam1 has quit [Ping timeout: 246 seconds]
musaHaruna has quit [Quit: Connection closed for inactivity]
troyam has quit [Client Quit]
nanotube has joined #bitcoin-core-dev
ShebaLamb has joined #bitcoin-core-dev
purpleKarrot has quit [Quit: purpleKarrot]
purpleKarrot has joined #bitcoin-core-dev
eugenesiegel has quit [Ping timeout: 245 seconds]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
ShebaLamb has quit [Ping timeout: 252 seconds]
ShebaLamb has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]