SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
<bitcoin-git>
[gui] 1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw opened pull request #879: New SVG, Icons, PNGs and X PixMaps (master...master) https://github.com/bitcoin-core/gui/pull/879
hacker4web3bitco has quit [Ping timeout: 272 seconds]
OYENRAZOR369 has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #32940: cmake: Use newer signature of `qt6_add_lrelease` when available (master...250710-lrelease) https://github.com/bitcoin/bitcoin/pull/32940
OYENRAZOR369 has quit [Quit: Client closed]
l0rinc has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
Emc99 has joined #bitcoin-core-dev
<achow101>
#startmeeting
<corebot>
achow101: Meeting started at 2025-07-10T16:00+0000
<achow101>
There are no pre-proposed meeting topics this week. Any last minute ones to add?
<b10c>
hi
<kanzure>
hi
<jonatack>
hi
<l0rinc>
hi
<TheCharlatan>
hi
<darosior>
hi
<laanwj>
hi
<achow101>
#topic Erlay WG Update (sr_gi, gleb)
<sr_gi[m]1>
Ok, I have some data to report. I've been running sims in networks up to 200 nodes on Warnet, and what I’ve observed is that, for these sizes, we can achieve ~24% savings in INV messages for ~35% more latency. This is slightly better than what I saw when simulating in the actual network event simulator (the prospected was 40% more time for 21% savings), but pretty much in line.
<pinheadmz>
hi
<sr_gi[m]1>
Something I've noticed, however, is that the bigger the networks, the better this ratio seems to get. I haven’t been able to run reliable simulations for bigger networks, since I have been struggling with limitation in the current approach for capturing results. The biggest I've tried so far is 500 nodes, but the sims crash more often than not (or end up returning only partial data).
<sipa>
hi
<sr_gi[m]1>
This week I decided to change the approach for this, instead of collecting data from the node’s logs, I've implemented a small patch in Core that keeps track of when a node first hers about a transaction (first INV received) and when it first sees it, and I added it to getrawtransaction, so the Warnet scenario can just query that information as it goes. I think this would allow for bigger network to be tested.
Christoph_ has joined #bitcoin-core-dev
<sr_gi[m]1>
One thing I'm missing is running sims with more than 8 outbounds per node, to see if the expected decrease in bandwidth (with respect to the current approach) when making the network more tightly connected can be seen.
<sr_gi[m]1>
I think this should be good as a concept to start moving forward with #30116.
<sr_gi[m]1>
I'll be working on making the simulations easily reproducible (they are a bit clunky atm given the issues I was mentioning before) and test the new approach to gather results for bigger networks. Happy to walk through both concept and approach to anyone who’s interested in reviewing it.
<theStack>
hi
<dzxzg>
hi
<cfields>
sr_gi[m]1: as I
<sr_gi[m]1>
:tada:
<cfields>
as I've been poking at the p2p code lately, I've noticed a likely bottlenecks wrt scaling and number of nodes being processed. I'd be interested in discussing some of that with you and looking at some data, maybe not directly related to erlay itself.
<jonatack>
cfields: nice -- interested to hear where the bottlenecks appear to be
<sipa>
cfields: i have thoughts too, will reach out
<TheCharlatan>
We've had the debate for over a year now, and I implemented both variants, but people either stopped weighing in, or still seem undecided.
<TheCharlatan>
would be good to get this rolling again, especially since more people seem to be getting interested
<TheCharlatan>
that's all
<achow101>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<abubakarsadiq>
hi
<sipa>
hi, 31553 got merged, so the next PR in the TxGraph Series(tm) is #32263
<sipa>
while 32263 isn't all that critical as it doesn't change APIs much, i think it's the best thing to look at now
<johnny9dev>
hi
<sipa>
the bigger plan is getting sdaftuar to rebase #28676 on top of the now-merged TxGraph stuff, and perhaps seeing if some parts of that can be split off
<johnny9dev>
gradually working on getting my work from the last month upstreamed.
<johnny9dev>
pinheadmz completed a really nice proposal for using bitcoin/bitcoin as a submodule to the project. https://github.com/pinheadmz/bitcoin-core-app. I took that approach and used a git filter-branch to try and extract out all of the history for the qml folder while not burdening the repo with the entire history of bitcoin/bitcoin at https://github.com/johnny9/bitcoin-core-app. I really like this approach and it would get my vote for
<johnny9dev>
how to move forward with the project. I think rebasing with upstream and managing the two has become too overwhelming.
f321x_ has quit [Quit: f321x_]
<glozow>
hi
<johnny9dev>
I think we're interested in some opinions on moving forward on a submodule approach for the project
<darosior>
neat
Guest20 has quit [Ping timeout: 272 seconds]
<johnny9dev>
Possibly creating a new repo and archiving the old one.
l0rinc has quit [Quit: l0rinc]
<achow101>
johnny9dev: would this approch result in the gui being permanently separated from the rest of the project?
<Murch[m]>
What would you use as the steps for the submodule? Would you update it to tagged releases or just update to upstream occasionally?
<pinheadmz>
i think thats a practical longer term goal
<fanquake>
Would that mean you'd ultimately delete everything gui related on the bitcoin/bitcoin side, and move it into the app repo? and going forward we'd ship a gui from the app repo?
<pinheadmz>
we still need to figure out "who" manages depends for qt
<fanquake>
Would you make your own copies of the depends system, guix etc in that repo?
<pinheadmz>
and right now even the qml source depends on the qt/ code in bitcoin core cirrently
<fanquake>
same for copies of the CI system?
<johnny9dev>
We can always collapse back I think and this is just for gui-qml
<pinheadmz>
presumably with core as a submodule we wouldnt need to copy all the bitcoin core CI either
<johnny9dev>
We certainly have a lot of figure out in terms of CI and deployment but at least for now it seems like it will give us more flexibility
<fanquake>
pinheadz: that assume's that core keeps everything gui related around though?
<pinheadmz>
no i meant like, right now qml-gui runs everything bitcoin runs
<pinheadmz>
no need for that
<pinheadmz>
gui repo can just test gui
<pinheadmz>
but then yeah depends/qt, and src/qt we could eventually move to the GUI repo
<pinheadmz>
and yes i assume ship from the gui repo
<pinheadmz>
but also this is the QML gui only, its not the legacy gui
<pinheadmz>
however i guess the same kind of structure might be possible hm...
<achow101>
pinheadmz: I guess the question is whether this is the long term organizational plan, or just temporary to avoid having to constantly rebase gui-qml
<achow101>
I assume that's all still up in the air
<pinheadmz>
yeah
<fanquake>
Yea, it's not really clear if this is just useful for development, or what we actually want to do long term
<achow101>
this might be a good topic to discuss at coredev
<fanquake>
Longer term, I don't think submoduling makes sense
<johnny9dev>
I'd like to at least try this as soon as possible because it gets me to cmake and qt6
<pinheadmz>
not to mention, there are changes to bitcoin core source code in the gui-qml repo and a sumbodule just makes that not psossible
<johnny9dev>
Anything there should be upstreamed properly, though
<pinheadmz>
well one conflict i found was for example adding back a get-block-time interface that had been *removed* in core !
<achow101>
johnny9dev: I think we can setup a new repo in bitcoin-core for this if you think it would be helpful with developing the new gui
<fanquake>
is there an issue with the current repo?
<johnny9dev>
Thank you. Might need a bit to decide what the initial instance should be.
<achow101>
fanquake: I assume blowing away the commit history is not desirable?
<johnny9dev>
But will let you know what is decided for sure
<fanquake>
achow101: then just make a new branch?
<fanquake>
Why does that need a new repo
sbddesign has joined #bitcoin-core-dev
<hebasto>
a new branch might me default one
<johnny9dev>
Good point. Just new default branch might do it.
<pinheadmz>
blow away the entire history of main?
<achow101>
fanquake: for issue and pr organzation, since the codebase is essentially entirely different
<pinheadmz>
and johnny9dev and i can work on a PR to the new empty branch
<achow101>
repos are cheap anyways, and we can delete/archive them when they're not needed
<fanquake>
achow101: Isn't that already the QML repo?
<hebasto>
pinheadmz: "main" remains; new branch, say "qt6" or " dev" will be the default one
<pinheadmz>
yeah with no history :+1:
<achow101>
fanquake: which currently has issues and prs that refer to code in already in the repo that has a completely different layout than what was proposed
<johnny9dev>
I work on sorting out the PRs and migrate them to the new branch.
<achow101>
i don't think it matters that much either way, and we can accomodate what they want/need. either way, it doesn't really effect the main project
jonatack has quit [Read error: Connection reset by peer]
<johnny9dev>
Ok I think a branch makes sense and will work with hebasto and pinhead to sort it out.
<achow101>
alright
<johnny9dev>
That is all I think.
<achow101>
#topic orphan resolution WG Update (glozow)