<bitcoin-git>
[bitcoin] janb84 opened pull request #34570: doc: update Windows MSVC build guide to utilize winget to install build requirements (master...windows-msvc-update) https://github.com/bitcoin/bitcoin/pull/34570
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
adil has quit [Quit: adil]
<bitcoin-git>
[bitcoin] maflcko opened pull request #34571: test: Fix intermittent issues in feature_assumevalid.py (master...2602-test-av-int-fail) https://github.com/bitcoin/bitcoin/pull/34571
adil has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko closed pull request #34544: wallet: Disallow wallet names that are paths including `..` and `.` elements (master...wallet-no-relative-paths) https://github.com/bitcoin/bitcoin/pull/34544
<bitcoin-git>
[bitcoin] maflcko reopened pull request #34544: wallet: Disallow wallet names that are paths including `..` and `.` elements (master...wallet-no-relative-paths) https://github.com/bitcoin/bitcoin/pull/34544
<bitcoin-git>
[bitcoin] DrahtBot closed pull request #34075: fees: Introduce Mempool Based Fee Estimation to reduce overestimation (master...12-2025-fee-estimation-improvement) https://github.com/bitcoin/bitcoin/pull/34075
<bitcoin-git>
[bitcoin] DrahtBot closed pull request #27052: test: rpc: add last block announcement time to getpeerinfo result (master...2023-02-getpeerinfo) https://github.com/bitcoin/bitcoin/pull/27052
<bitcoin-git>
[bitcoin] DrahtBot reopened pull request #34075: fees: Introduce Mempool Based Fee Estimation to reduce overestimation (master...12-2025-fee-estimation-improvement) https://github.com/bitcoin/bitcoin/pull/34075
<bitcoin-git>
[bitcoin] DrahtBot reopened pull request #27052: test: rpc: add last block announcement time to getpeerinfo result (master...2023-02-getpeerinfo) https://github.com/bitcoin/bitcoin/pull/27052
l0rinc has quit [Quit: l0rinc]
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #34572: cmake: Fix NetBSD-specific workaround for Boost (master...260212-netbsd-boost) https://github.com/bitcoin/bitcoin/pull/34572
kevkevin has quit [Ping timeout: 264 seconds]
adil has quit [Quit: adil]
kevkevin has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
l0rinc has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
twistedline has quit [Ping timeout: 264 seconds]
twistedline has joined #bitcoin-core-dev
twistedline has quit [Ping timeout: 264 seconds]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
sr_gi[m] has quit [Quit: issued !quit command]
sr_gi has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 245 seconds]
durandal_ has quit [Read error: Connection reset by peer]
durandal_ has joined #bitcoin-core-dev
durandal_ has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] m3dwards closed pull request #32672: ci: update pwsh to use custom shell that fails-fast (master...250603-pwsh-fail-fast) https://github.com/bitcoin/bitcoin/pull/32672
twistedline has joined #bitcoin-core-dev
eugenesiegel has quit [Quit: Client closed]
twistedline has quit [Ping timeout: 255 seconds]
twistedline has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
<fjahr>
There is one pre-proposed meeting topic this week. Any last minute ones to add?
<sr_gi>
hi
<lightlike>
Hi
<johnny9dev>
hi
<stickies-v>
hi
<sipa_>
hi
sipa_ is now known as sipa
<sipa>
hi
Emc99 has joined #bitcoin-core-dev
<fjahr>
We'll get started with the WGs!
<fjahr>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
nothing from my side
<cfields_>
hi
<fjahr>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<sipa>
Hi!
<sipa>
We're getting very close to the finish line. #34257 was merged. Next to review is #34023 which would be good to get into the first release still.
<hebasto>
it's a common opinion that the GUI development stuck.
<hebasto>
but I see it a bit differently; it's in stalemate.
<hebasto>
the current monolithic approach in the codebase, build system, release process, and publishing makes it infeasible to move forward neither in the current GUI (like adding Wayland support for release binaries) nor in new QML-based GUI.
<hebasto>
this crisis stems from the natural antagonism between security (less dependencies) and functionality (more dependencies).
<hebasto>
the problem with Bitcoin Core GUI has been known for quite a long time, and this attempt to find a solution isn't the first.
<hebasto>
furthermore, the long-standing nature of this issue, combined with the separate GUI repository, led to a decline in developer focus on the GUI.
<hebasto>
I strongly believe that it is in best interest of the current and _future_ users to shift focus on developing the GUI based on a public API (IPC, RPC etc).
<hebasto>
of course, we have to pledge to develop and maintain such APIs basing on the best engineering practices.
<hebasto>
as a side effect, it opens a free market for alternative GUI implementations.
<hebasto>
the immediate action I propose is to deprecate the GUI binaries in v31.0
<hebasto>
in light of the above, I will be shifting my personal focus accordingly.
<hebasto>
that's all from me
<achow101>
The gist states that the eventual goal is to abandon the GUI, which I wholeheartedly disagree with
<achow101>
I think the project must ship an official GUI. That can still be done even if we have IPC
<johnny9dev>
I would also like to add that from someone on the edge. The gui doesnt look abandoned at all. There are PRs and issues flowing. Its certainly slow but it appears infinitely more healthy than a majority of open source projects.
<hebasto>
achow101: I hope you can propose an alternative to move away from the current stalemate?
<furszy>
I think we should monitor the GUI's downloads in some way, and see if we do have users for it.
<pinheadmz_>
furszy i suggested that before, no one wants to track bitcoin users tho
<furszy>
not even the download count?
<pinheadmz_>
also suggested we intentionally break the gui and see if anyone complains ;-)
<janb84>
I like the free market idea
<pinheadmz_>
furszy ask BlueMatt[m] hell refuse
<l0rinc>
hi
<instagibbs>
pinheadmz_ lol
<achow101>
hebasto: I don't disagree with moving towards having a stable IPC interface that the GUI can use, but that does not mean that we shouldn't ship a GUI
<pinheadmz_>
johnny9dev IIRC you have a branch of QML that is pretty good - but its like 1000 commits
<johnny9dev>
there are plenty of people that I believe would be interested in taking ownership of the old gui as well. I wouldnt use the term deprecation but maybe migrating it is an idea.
<instagibbs>
I'm a marginal GUI user, but I'd just as easily use an alterantive dashboard for the same purposes
<pinheadmz_>
so if we want a gui we need review
<furszy>
pinheadmz_: I had a few easy crash fixes in the gui open for a while, and no one complained about them.
<achow101>
furszy: all access logs on the website are disabled so we currently can't get any stats
<dergoegge>
Who ever wants us to keep shipping the gui will need to take care of it
<sliv3r__>
@pinheadmz_ lol
<pinheadmz_>
it does seem very useful to find out if anyone uses a thing before we dedicate work to it
<bitcoin-git>
[bitcoin] maflcko opened pull request #34575: test: Avoid empty errmsg in JSONRPCException (master...2602-test-proper-JSONRPCException-error) https://github.com/bitcoin/bitcoin/pull/34575
<BlueMatt[m]>
@libera_irc_pinheadmz_:bitcoin.ninja i mean, i think the gui is great to have, but also i dont really have an opinion that counts here cause I don't work on core
<fanquake>
pinheadz: the issue with the current QML (which iirc hasn't had a commit for 6 months), is that is inherits the same architectural problems as the current gui, but somewhat worse, given the subtree.
<pinheadmz_>
achow101 why do you think we must ship a gui ?
<fjahr>
I can agree with the issue stated but by hebasto/stickies but if we don't have any official GUI at all I fear a flood of vibe coded malicious GUIs that will cause us more pain than maintaining an official gui, which could be very minimal
<pinheadmz_>
BlueMatt[m] do you have an opinion about tracking downloads ?
<BlueMatt[m]>
if bitcoin core is gonna ship a wallet, it seems reasonable that it should also ship a gui to access that wallet
<achow101>
pinheadmz_: because users expect us to provide one. I think everyone severely underestimates how many people actually use the gui
<BlueMatt[m]>
pinheadmz_: yes, we shouldn't do it.
twistedline has joined #bitcoin-core-dev
<sipa>
hebasto: i don't think the dependencies problem is core to the issue here; we can move towards a more-static-linked binary for bitcoind, and simultaneously toward a more runtime-dependency rich bitcoin-qt binary... because GUI users naturally depend on more dependencies (no pun intended)
<achow101>
just for example, the default windows and macos downloads install and provide access to the gui by default. Using bitcoind on windows is a pain in the ass. and the macos app installer doesn't even provide bitcoind or the utilities
<pinheadmz_>
fanquake all the commits are, i belive, on johnny9dev branch and need lots of PRs and reviews
<fanquake>
pinheadz: is the subtreeing solved, and is it using IPC now?
<furszy>
BlueMatt[m]: not even download count? nothing else.
<hebasto>
fanquake: wdyt about sipa's suggestion?
<pinheadmz_>
fanquake not using IPC yet
<eugenesiegel>
to second fjahr comment, I also worry about malicious GUIs takings the official ones place
<fanquake>
It would be good to get some clarity around if we are implementing new features (silent payments, pay dns, privatebroadcast, assumeutxo etc) in the current gui, and who might implement those
<achow101>
something else to consider is that we already have a bunch of loud people who claim we hate users. killing the gui in the short term will add fuel to that fire
<pinheadmz_>
i just wanted to stop core codebase changes in the qml repo, so forcing bitcoin as a subtree
<johnny9dev>
I bet we could recruit people to work on those things if its a manpower issue
<dergoegge>
there's nothing stopping anyone from building malicious GUIs right now
<sipa>
hebasto, fanquake: to be clear, i'm not saying that this is a trivial thing to do - i'm saying the issue isn't dependencies, it's reviewer interest (if anything)
<hebasto>
achow101: it's not about "killing the gui"
<ryanofsky>
i'm curious about problems with the subtree. it seems like a read-only subtree could be a good way to support a group of external developers making a gui
<BlueMatt[m]>
furszy: im not aware of a way to do counts trivially without logs on a static site. i mean you can log to tmpfs and then have a script that converts that to count, but then you do have logs...
<fjahr>
dergoegge: but people are not actively looking for a replacement right now so the incentives are much lower
<pinheadmz_>
johnny9dev -- your branch -- how is it going. feature complete? enough for most users to send and receive?
<achow101>
dergoegge: the only people who would be affected by a malicious gui right now are those who seek a 3rd party gui. killing the official one requires every gui user to find one
<fanquake>
ryanofsky: it doesn't decouple the gui from our repo, and doesn't properly exercise the interface, like an external user would have to
<fanquake>
we can't clean up any code, we need to keep sharing depends in some awkward way etc
<fanquake>
basically the current situation except worse, because now you have a sync / versioning problem
<johnny9dev>
The branch is still in the demo state. I had personal things come up and other project take priority. I think conceptually your refactor works and it is a route to build the gui independantly but there is a lot of work to make qml a reality still
<fanquake>
(also unclear if the CI framework would be shared, of the gui repo would have it's own)
<ryanofsky>
fanquake, thanks. i feel like those issues might be fixable? like we could delete all gui code & depends stuff from core repo and move it to an external repo includeing core as a read-only subtree
<fanquake>
which would retain further coupling
<fanquake>
ryanofsky: how about all the settings code, util code etc?
<sipa>
ryanofsky: i like that as something we could try, but i'm not sure it'll change much
<ryanofsky>
it is includedin core. if gui developers need to change it (hopefully not frequently) they submit a pr
<johnny9dev>
I do agree that the subtree refactor pinheadz did to the qml project is a viable alternative. Release process/ownership would need to be understood
<johnny9dev>
doing that adds more process
<fanquake>
Somebody should be able to take out IPC interface, and build a GUI essentially without seeing our repo, and we aren't dogfooding that by having a subtree with tonnes of shared code
<johnny9dev>
agree there too. it would be a step in the right direction though
<ryanofsky>
sipa, yes. i think the real question is just whether external developers want to continue maintaining the gui, but developers here who are currently maintaining it do not want to
<fanquake>
and I assume would not build out the interfaces properly, because we can just cheat
eugenesiegel has quit [Quit: Client closed]
<ryanofsky>
s/but/because/
<dergoegge>
achow101 fjahr: they've managed to download and run bitcoin-qt I think they'll be fine. Seems like very paternalistic thinking. They might also (more likely) find a better alternative
<achow101>
I strongly prefer that we still have the gui in the main repo, shipped along with our normal release process. it can still use IPC and does not need to be so tightly coupled, other than in doing releases
<johnny9dev>
I'm skeptical that the gui is in such a dire state, though. I know its been a friction point, but I don't fully understand why.
<fanquake>
This just seems to create more friction, and repos to track, that non-gui devs (majority) have to deal with?
eugenesiegel has joined #bitcoin-core-dev
<BlueMatt[m]>
yea, i mean the gui works fine. just because its not super actively maintained doesn't mean that it has noticeable bugs that impact the average user
<sipa>
fanquake: that's fair - and cleaning up the interface to make it even possible to have an IPC-only GUI will probably require significant changes to the interface on the core side, so would be easier to do before such a subtree move
<ryanofsky>
fanquake, moving gui code out of core into a separate repo would seem to create more friction for (theoretical) gui developers but not core developers
<Sjors[m]1>
My hot take would be: we should keep offering a GUI, but it can a separate download. Designing a fresh IPC for this, rather than sticking to the current GUI interface, would make the most sense to me.
<fjahr>
dergoegge: It will look much better and then maybe steal their coins
<Sjors[m]1>
And I would probably feel more motivated to work on such an IPC interface than on the current GUI code.
<fjahr>
dergoegge: And the users won't know which project stole them, core or the gui
<fanquake>
ryanofsky: yea, the reason the separated repos seem to have worked so far, is because 95% of core devs aren't touching any gui code
memset has quit [Remote host closed the connection]
<fanquake>
(also why none of the GUI side of features we've shipped has been implemented)
<dergoegge>
fjahr: if your core node is a hot wallet then any piece of software you download runs that risk
<fanquake>
A non-technical user still can't use AssumeUTXO
<achow101>
I would argue that separate repos has not worked so far, and is in fact what has caused the GUI to get into this stalemate situation
memset has joined #bitcoin-core-dev
<sipa>
achow101: i agree
<furszy>
fanquake: would argue that a technical one neither.
<furszy>
but that is a different subject
<fanquake>
I think the key point here, is that hebasto has decided he's focussing on different things, so it sounds like somebody(s) need to step up here
sr_gi has quit [Quit: Client closed]
<achow101>
in fact, I would entirely propose that something we should try to unstick the gui is to remove the separate repo and bring it back into the main repo
<fanquake>
As of today there are new (non-)GUI issues that needs solving, i.e #34569
<dergoegge>
the proposal was abandonment in v34, all of you who are so in favor of having a gui have enough time until then to build an alternative we can ship that solves the current issues
<cfields_>
I built wit gcc16 this week and have some patches to PR.
<cfields_>
(I realize that's not the point you're making though.. )
<pinheadmz_>
fanquake is right the real lede here is hebasto's priorities
<sliv3r__>
achow101 I agree, it's so anoying if you try to do stuff on the gui to have another repo with a bunch of duplicated code
<fanquake>
Yea. Someone else needs to be responsible for release prep, translations, implenting new GUI features, making a decision about QML, deciding what new GUI features we might implement, make a decision about a wayland migration or not, etc
<hebasto>
fanquake: pinheadmz_: I don't think its about my personal priorities
memset has quit [Remote host closed the connection]
<achow101>
dergoegge: I am doubtful that we can do all of multiprocess in that time, which seems like a hard requirement for alternative guis
<johnny9dev>
To the point of bitcoin-core/gui being not create. I still don't actually know the relationship between bitcoin-core/gui and bitcoin/bitcoin. I've been on the edge but I think it probably be obvious to someone like me by now.
<johnny9dev>
being not great*
<dergoegge>
The RPCs work as well, there's no hard requirement on IPC afaict
<dergoegge>
Alternative decoupled GUIs exist today without IPC
<achow101>
dergoegge: there absolutely is, in order to get signals/notifications
<Sjors[m]1>
RPC is much too slow for a UI, all of the web based UI's have demonstrated that
<achow101>
dergoegge: provide an example
memset has joined #bitcoin-core-dev
<dergoegge>
liana, specter, sparrow
<achow101>
none of those are guis. those are whole ass separate wallets
<sliv3r__>
those does not allow you to control your node
<achow101>
they do very different things from what our gui does
<hebasto>
re "Yea. Someone else needs to be responsible for release prep, translations, implenting new GUI features, making a decision about QML, deciding what new GUI features we might implement, make a decision about a wayland migration or not, etc" -- okay, if you say so
<fanquake>
? Isn't that what you're proposing by focussing on other things?
<johnny9dev>
yeah if you're serious i think you need to champion a new owner and mentor
<dergoegge>
RPCs can be polled
<johnny9dev>
it will be a lot of work
<pinheadmz_>
boy it sure would be great is we knew any users wanted a bitcoin core gui
<pinheadmz_>
how can we set our agenda without that info
<BlueMatt[m]>
I mean people definitely use it
<sipa>
agreed, achow101; and importantly: there is no way to convert/import/load Bitcoin Core wallets into them - they have an entirely different idea of what a wallet is, so that's no viable migration path for current GUI wallet users
<Sjors[m]1>
I use it :-)
<BlueMatt[m]>
how man i dunno, but its very far from zero, and with a wallet its the most important part
<pinheadmz_>
good point - abandon the wallet !
<achow101>
pinheadmz_: here's data from the survey I ran 5 years ago, never really processed it to the point that something could be written up, but there were questiosn about how users use Bitcoin Core https://github.com/achow101/2021-core-survey/
<sliv3r__>
if we kill the gui we kill the posibility for non-tech users to run nodes easily without relaying on something like umbrel, etc.
<achow101>
of the 342 people who responded to the question "How do you currently use Bitcoin Core?", 176 of them said "the GUI"
<pinheadmz_>
interesting !
<sliv3r__>
people should be able to run a node only with core, and not needing other's "frontend" software
<achow101>
of the 387 people who responded to the question "how did you previously use Bitcoin Core?", 246 responded "the GUI"
<sliv3r__>
achow101 would be a lot of work to run that survey again?
<dergoegge>
So the only data we have is a 5 year old survey of ~400 users?
<sipa>
sliv3r__: i worry that the current social media climate is not conducive to getting honest answers
<achow101>
sliv3r__: kinda yeah, and also the questions need major work to get more useful info out
<sliv3r__>
true :/
<achow101>
dergoegge: the survey itself had ~3000 responses, just those ~400 who answered those specific questions
<ryanofsky>
i think it'd be good to have a more specific idea of current problems. if hebasto, fanquake others are currently spending time on the gui and want to work on other things, deleting src/qt/ may be one solution but there may be others
<pinheadmz_>
well could we start releasing a QML-beta within a year that had MVP functinality
<pinheadmz_>
along with deprecating Qt
<dergoegge>
Who will work on the qml gui?
<johnny9dev>
as the last remaining QML guy. I actually think the Qt widgets serves a really important role and I have grown to really like it.
<hebasto>
I will
<johnny9dev>
I would rather keep Qt widgets alive than try to replace it.
<pinheadmz_>
well. i can take on some of the review to get jonnys work into a beta release.
<pinheadmz_>
the qml ui looks slick and modern, i think it is something bitcoin should have
<sipa>
johnny9dev: just for someone not familiar with the terminology... does "Qt widgets" mean the current non-QML gui?
<hebasto>
^ right
<furszy>
sipa: the current widgets
<johnny9dev>
yeah qml serves a different purpose that the widgets one for sure and there is a lot of opportunity if it can be realised
<sipa>
furszy: you have not provided an answer that is useful to someone unfamiliar with technology :p
<johnny9dev>
Qt widgets is old-school desktop gui
<sipa>
*terminology
<johnny9dev>
think tables, gray buttons, and tabs
<furszy>
sipa: :)
<achow101>
sipa: QT widgets is what the current gui we ship uses
<johnny9dev>
but its still perfect for data software. Sparrow is widgets based
<sipa>
achow101: thanks
<pinheadmz_>
isnt Qt deprecating widgets? like isnt there some dependency-reason we have to migrate ?
<johnny9dev>
no they are not
<johnny9dev>
there was a misconception but it will never be deprecated
<pinheadmz_>
ah i was misconcieved
<johnny9dev>
its not getting new features but it is supported. Consider it "solved"
<hebasto>
Qt stopped developing Qt Widgets actively, but not deprecated them
<furszy>
so, hebasto, you are interested in working on the new GUI, but not in maintaining the current one anymore?
<Sjors[m]1>
If QML is easier to work with and we have a working prototype, that's still better(tm), no?
<fanquake>
ryanofsky: 1 issue is that because the QML gui was being built, no new features were added to the current GUI, but that has also stalled, so now new features are being added anywhere
<sipa>
it is not just a question of what technology is best, but also what people want to work on, sadly
Emc53 has joined #bitcoin-core-dev
<sliv3r__>
Is there any tracking issue or resource that lists the implemented and missing features for both new and old GUI?
<fjahr>
sipa: so rust gui?
<sipa>
fjahr: can you vibecode that?
<fjahr>
sipa: consider it done
<achow101>
fjahr: if it can work over ipc, i don't see why not
<cfields_>
fjahr: that becomes an actual possibility if good ipc api emerges...
<johnny9dev>
it would also be good to get an understanding of what would make developing the current gui more manageable or why it feels like its such a burden
<achow101>
as long as others are okay with us shipping it under the bitcoin core banner
<dergoegge>
is the need for IPC actually documented somewhere? don't see why that is such a hard requirement
<hebasto>
furszy: I was saying not about my intetntion but about what I believe is good for the users and developers
<hebasto>
important detail that QML-based GUI was designed by designers
<achow101>
dergoegge: I don't believe so
<dergoegge>
Can it summarized quickly here?
<Sjors[m]1>
dergoegge: IPC has the potential of actually being acceptably fast for a UI
<Sjors[m]1>
Although we probably won't get 120 frames per second on mobile :-)
<achow101>
but just as a (very) old example, armory resorted to reading the blocksdir rather than relying on rpc
<sipa>
i think the IPC relevance here is just that if we'd force our own GUI to use the IPC, we'll necessarily also make it easier for external projects to build their own GUI against the same interface
<achow101>
because rpc was slow to respond
<Sjors[m]1>
Regarding rust and IPC: that's being very actively tested for the Mining interface.
<achow101>
and rpc polling just kinda sucks
Emc99 has quit [Ping timeout: 272 seconds]
<sipa>
i don't think RPC for a GUI is all that interesting; it's not great for it - and making a good RPC GUI interface is probably harder than creating an IPC interface from scratch + GUI from scratch that uses it
<Sjors[m]1>
And with libmultiprocess using IPC for a c++ client is a piece of cake.
<dergoegge>
RPC is not slow anymore
<dergoegge>
as in the json-rpc overhead is not noticeable if you click a button
<achow101>
and rpc did not (does not?) provide all of the necessary data
<furszy>
hebasto: I think we are in a similar spot to when we were doing the projects board and voting for them. Everyone who feel this is important should sign up to work on it. Otherwise we will stall again.
<dergoegge>
what data is missing
<dergoegge>
we can add that and it'd be less work than all of IPC
<Sjors[m]1>
Adding data to RPC shouldn't be the bottleneck.
<achow101>
don't remember off the top of my head, it's been 10 years
<fjahr>
johnny9dev: Would it be fair to say that the QML project is suffering from too high expectations and that is hindering it getting towards the finish line? E.g. if you were not trying to achieve everything exactly as in the design docs would you be done quicker?
<Sjors[m]1>
But in the UI you often need push based stuff, like a notification when a transaction confirms. You can do that with multiple long poll RPC requests, but it's cleaner with IPC.
<dergoegge>
Why does polling suck? because it's not optimal from a eng perspective? I don't think users would care
<fanquake>
fjahr: I think the expectations are just to implement the features we currently have, so it'd be a drop-in replacement?
<hebasto>
fjahr: once we agreed on the including more dependencies guix scripts without sacrificing security of bitcoind, the QML-based GUI could be released in v32.0
<dergoegge>
achow101: so perhaps it's not even an issue? the wallet and node work just fine through the cli, so I don't see how RPCs wouldn't be good enough for a gui
<achow101>
but the general issue is that the gui wants to be notified/get a signal when things like a block or transaction arrive to the wallet that needs to be shown to the user. for something like transactions, there's no way to ask rpc essentially "what has changed since I last polled", but rather it has to be "give me all of the wallet transactions and then I need to diff this response with the last one"
<hebasto>
^ right
<sipa>
dergoegge: i think these are questions that need to be answered by people working on the GUI, not in this meeting
<achow101>
and then we also run into limitations like listtransactions doesn't return all tranasctions, and asking it to do that every time can actually be quite slow
<fjahr>
fanquake: but it also has this beautiful UI that was designed and I guess that adds overhead
<dergoegge>
All I'm saying is that if people want to build a nice gui today, it is possible. It's just that almost no one wants to actually do the work
<fanquake>
fjahr: sure. It has also been 4 or 5 years though?
aleggg has quit [Remote host closed the connection]
<achow101>
dergoegge: probably because there is currently a gui, so why work to create something that's worse
<fjahr>
fanquake: yeah, just looking for potential shortcuts to the finish line ;)
<sipa>
dergoegge: it's possible, but i think that's an unfair conclusion
<fjahr>
(I also don't know if the original design get's further changes, the design community is quite active)
<fanquake>
I guess if there's a heap of devs here who haven't contributed to QML in the last 4-5 years, but would like to actively work on it now, and that means we ship it in 32, and replace that current widgets based GUI, that is some clarity. Is that possible?
<achow101>
fanquake: does it need to use IPC?
<fanquake>
I think that would be best (even if that means it takes longer), otherwise we haven't improved things architectural, or started building what is needed for external applications to build the same type of applications
<hebasto>
QML GUI for 32.0 may be based on internal interfaces only
<Sjors[m]1>
What hebasto says makes sense to me. Once we have QML, we can redesign the interface and then later make it public facing.
<achow101>
fanquake: sure, but doing that requires us to actually finish doing multiprocess
<achow101>
which seems to be currently focused a lot more on supporting mining
<fanquake>
achow101: only to the extent that we have done for the mining interface right? Given that is currently shipped and useable
<fjahr>
3 minutes left...
<Sjors[m]1>
We've made quite a bit of progress on fine-tuning libmultiprocess since v30.
luke-jr has quit [Read error: Connection reset by peer]
<sipa>
i think being restricted to clean internal interfaces is 90% of the work of making it IPC-capable?
luke-jr has joined #bitcoin-core-dev
sr_gi has quit [Quit: Client closed]
<Sjors[m]1>
sipa: not necessarily, IIRC there's some stuff that doesn't perform well with the IPC overhead.
<Sjors[m]1>
So that needs to be redesigned.
<achow101>
fanquake: I think it'll be more complicated? it will have to launch bitcoind in the background and do process management stuff?
sr_gi has joined #bitcoin-core-dev
<hebasto>
Sjors[m]1: due to latency?
aleggg has joined #bitcoin-core-dev
<Sjors[m]1>
hebasto: probably due to going back and forth too much. But this hasn't been tested recently.
<sipa>
ok fair
furszy has quit [Ping timeout: 265 seconds]
<fjahr>
Anything else that needs to be shared? Feature freeze is in 2 weeks.
<Sjors[m]1>
We also left out process spawning for mining, so that's not battletested.
<achow101>
I think we should defer the action of deprecation to after we can yell at each other in person
<fjahr>
(feel free to continue the GUI discussion of course but I will finish the meeting)
<pinheadmz_>
The gui discussion will never end
<fjahr>
#endmeeting
<corebot>
fjahr: Meeting ended at 2026-02-12T17:00+0000
<Sjors[m]1>
I made a note to take QML GUI for a spin, probably after the branch-off. Keep it freshly rebased :-)
andytoshi has quit [Ping timeout: 245 seconds]
<hodlinator>
(not sure if it was a serious suggestion, but starting to mix in Rust for the GUI would risk eventually leading to a Frankenstein monster with BDK and Bitcoin Core Kernel dependencies both pulled in and duplicating functionality in incompatible ways, or building/maintaining our own Rust-Bitcoin-Core lib).
andytoshi has joined #bitcoin-core-dev
<hebasto>
cfields_: did I understand you correctly that you have a solution for #34569?
<fjahr>
hodlinator: it was tongue in cheek of course but it would attract contributors. That doesn't mean it would give up the goal of the bitcoin core project to keep dependencies to a minimum if that were to be seriously considered.
<cfields_>
hebasto: I have a few patches for qt. Can't remember if I had it totally fixed or not. Looking at them now.
furszy has joined #bitcoin-core-dev
twistedline has quit [Ping timeout: 252 seconds]
<cfields_>
hebasto: one reason I didn't PR is because a few of the patches are just backports and another reasonable solution would be to just bump qt in depends. Is there a reason we're still on such an old release?
<hebasto>
yes, I was going to push my branch for Qt 6.10
<hebasto>
the only reason was compiler requirements for Windows binaries
arejula27 has joined #bitcoin-core-dev
<cfields_>
Yeah, I think that has the fixes for gcc as well. Most of them anyway.
<hebasto>
I'll test gcc 16 with Qt 6.10 then
<cfields_>
Either way, bumping would mean carrying fewer patches. So +1 for doing that first.
<hebasto>
okay, let me brush it up and push
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
<cfields_>
hebasto: I can easily test now if you have a commit to bump. IIRC it meant fixing/dropping some of our existing patches as well.
memset has quit [Remote host closed the connection]
arejula27 has quit [Ping timeout: 272 seconds]
memset has joined #bitcoin-core-dev
sr_gi has quit [Quit: Client closed]
cotsuka has quit [Read error: Connection reset by peer]
l0rinc has quit [Quit: l0rinc]
cotsuka has joined #bitcoin-core-dev
dzxzg has quit [Ping timeout: 264 seconds]
<bitcoin-git>
[qa-assets] murchandamus opened pull request #255: Add initial corpus for bnb_finds_min_waste (main...2026-02-initial-bnb_finds_min_waste) https://github.com/bitcoin-core/qa-assets/pull/255
twistedline has quit [Remote host closed the connection]
Guest35 has joined #bitcoin-core-dev
twistedline has joined #bitcoin-core-dev
Guest35 has quit [Client Quit]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
musaHaruna has quit [Quit: Connection closed for inactivity]
neonrooks has joined #bitcoin-core-dev
neonrooks has quit [Client Quit]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
l0rinc has joined #bitcoin-core-dev
<darosior4>
For the record, i'd like to say that IPC is in no way a requirement for a decent GUI. Using RPC is just fine, despite the inconsistent and often-breaking API (and even that is easier to fix than trying to come up with yet another moonshot IPC interface). I don't know how it came to be considered as such, and it frankly shows a clear disconnect with
<darosior4>
That is not to say i am unilaterally in favour of removing the GUI, i think it's a more complicated topic, in particular with regards to interactions with the wallet and migration of existing users. I have more thoughts i will share, but just wanted to say i hope we can do better as a group at having discussions on the directions of the project
<darosior4>
than camping on pre-conceived positions and trying to uncritically accept any semblance of argument that justifies our position.
<darosior4>
how Bitcoin is actually being used today. Better, less laggy, GUIs than the Bitcoin Core GUI exist today that use RPC! This is incredibly disingenuous to try and claim otherwise.
<sipa>
darosior4: i wasn't aware that any RPC-based GUIs for the Bitcoin Core wallet existed?
<sipa>
(or any non-Bitcoin-Core GUIs at all, for that matter)
dzxzg has joined #bitcoin-core-dev
<sipa>
if you're referring to other *wallets* that use RPC to communicate with Bitcoin Core, which include their own GUI, that's not a fair comparison i think
<jarolrod>
👋
<darosior4>
Liana is an example using the Bitcoin Core wallet, Sparrow is an example using a separate wallet but a direct RPC connection, virtually any other wallet in common use today is an example using an Electrum server as middleware (sometimes even locally, see for instance BWT).
<darosior4>
sipa: what is the expectation for a Bitcoin Core GUI other than being able to use Bitcoin through a graphical user interface?
laanwj has quit [Ping timeout: 255 seconds]
b10c[m] has quit [Ping timeout: 260 seconds]
BlueMattTest1 has quit [Ping timeout: 260 seconds]
bitcoin-git has quit [Ping timeout: 260 seconds]
BlueMattMtrxBot has quit [Ping timeout: 256 seconds]
Murch[m] has quit [Ping timeout: 260 seconds]
<sipa>
darosior4: being able to use/manage a Bitcoin Core wallet
<sipa>
if not, you can just use other wallet software
<darosior4>
I think the line is blurry because common other wallet software use a Bitcoin Core watchonly wallet in the background, but i agree backward-compatibility with the Bitcoin Core wallet format is the actual torny issue here.
<_aj_>
being able to observe/control the node state? (connected to peers, how many blocks synced)
<sliv3r__>
not only wallet, node control through a gui is important
<darosior4>
sliv3r__: control of what for instance?
<darosior4>
I think changing technical configurations of the node should not be a priority for a GUI targetting non-technical users.
<darosior4>
sipa: To eliminate those cases of people merely using watchonly wallet, would you think it's fair to reduce the scope to "being able to use/manage a Bitcoin Core hot wallet"?
<sipa>
i feel like we're missing a distinction between "a GUI that is a wallet" and "a GUI to control the Bitcoin Core wallet"
<sliv3r__>
darosior4: even shutting down the node, changing the network, changing net config like ports, pruning, etc.
<sliv3r__>
we cannot ask all users to go and play with a config file
<darosior4>
sliv3r__: that falls under wallet configuration to be honest
<sliv3r__>
darosior4: pruning your node falls under wallet configuration? I fail to see how
<sipa>
darosior4: i'm not very familiar with sparrow, but from what i understand, i would call it a separatey wallet - which happens to delegate some tasks to a bitcoin core wallet which it uses in a limited manner
<sipa>
it's not something you can use to manage an existing bitcoin core wallet.dat file, i believe?
<sipa>
and it's not something a bitcoin core wallet.dat file could be converted/migrated to
<darosior4>
sliv3r__: this "we cannot" language i think is a big hindrance to having a proper discussion. Of course everybody think that good things are desirable, duh, there is just disagreement about priorities and it appears that people that do eat the cost of those decisions (not me, to be clear) aren't happy bearing those anymore
<darosior4>
sipa: that is correct, yes
<sipa>
right, so i don't think that it using RPC is relevant in this discussion
<darosior4>
Some migration paths were discussed, but i don't think there is anything that could be reasonably considered a "recommended migration path out of Bitcoin Core"
<sipa>
it's a separate wallet, not a GUI for the Bitcoin Core wallet
<darosior4>
sipa: i don't think this is irrelevant to the discussion, because one way people have discussed this topic in the past is the intention behind the Bitcoin Core GUI is to "make Bitcoin accessible to non-technical users". You go to bitcoincore.org, download bitcoin, run bitcoin and it just works without moving parts. However i don't think this
<darosior4>
position is really compelling anymore in 2026, and i think what you point to is the real important part of the discussion. But the fact that there exists other simple ways (really, superior ways) of using Bitcoin (as in having a wallet) backed by a Bitcoin Core full node is not irrelevant to this discussion.
cotsuka has quit [Read error: Connection reset by peer]
<sipa>
I really feel that's a separate discussion.
<sipa>
Not an irrelevant one, but a largely orthogonal one, because you're really talking about creating what I'd say is a new, more modern, possibly simpler, wallet - with its own GUI.
<sliv3r__>
darosior4: so to understand your position, you think that the best approach is to get rid of the gui and let non-tech users use some other software to interact with their node? I feel we are mixing wallet gui and node gui
<sipa>
My concern w.r.t. deprecating the GUI is that it leaves people who _want to use the Bitcoin Core wallet_, for whatever reason - without a migration path.
<darosior4>
It is indeed a separate discussion, because the argument of keeping the Bitcoin Core GUI as the sole accessible way of using the Bitcoin network has not much to it, and now the real remaining question is: quid of existing users of the Bitcoin Core wallet?
<sipa>
If the goal is not that, but "providing non-technical users with a GUI to manage their BTC backed by Bitcoin Core", just use Sparrow?
cotsuka has joined #bitcoin-core-dev
<sipa>
they seem to be better at it
BlueMattMtrxBot has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
BlueMattTest1 has joined #bitcoin-core-dev
Murch[m] has joined #bitcoin-core-dev
<darosior4>
sliv3r__: i have not said that. In fact i explicitly stated that i was not signaling in favour of removing the GUI in my last message.
<sliv3r__>
I missunderstood then sry
<darosior4>
No worries. I started writing down my thought in an editor to share here, but it's turning into an essay, so i think i'll open a Delving thread about this and hopefully people will chime in
eugenesiegel has quit [Quit: Client closed]
<hodlinator>
Sjors[m]1 & fjahr: I can really see the appeal to devs of doing the official GUI in Rust. Again, I'm concerned about duplicating effort with BDK or using the actual BDK / rust bitcoin and running into a bunch of inconsistencies. But it might be worth the mess in order to get real traction. Time to fork Liana. ;)
laanwj has joined #bitcoin-core-dev
b10c[m] has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
twistedline has quit [Ping timeout: 264 seconds]
furszy has quit [Changing host]
furszy has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] furszy opened pull request #34577: http: fix submission during shutdown race (master...2026_http_submission_error) https://github.com/bitcoin/bitcoin/pull/34577
twistedline has joined #bitcoin-core-dev
dodo has quit [Quit: dodo]
dodo has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
w0xlt has quit [Ping timeout: 244 seconds]
kevkevin has quit [Remote host closed the connection]
w0xlt has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
luke-jr has quit [Read error: Connection reset by peer]
luke-jr_ has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<yancy>
Just catching up on the meeting discussion. Like 20 years ago, a large C project I worked on just surfaced a REST API, so any web coders could make APIs. That was a long time ago, but I'm surprised that there isn't a discussion about how to make a webpage GUI. I think keeping an abstraction of the API vs the GUI is nice since it could potentially be agnostic to how the GUI is built, and by who.
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
<yancy>
I guess that was like 2012 or something so maybe not "20 years" :P
<_aj_>
yancy: that seems kind-of appealing
cotsuka has quit [Read error: Connection reset by peer]
<darosior4>
Given who we'd care about supporting (afaiu) are users with private key enabled Bitcoin Core wallets, on the contrary that seems to be an unnecessary increase in the attack surface compared to a standalone software?
cotsuka has joined #bitcoin-core-dev
<_aj_>
if you have a private key on the node that you're running a gui from already, i don't think so?
darosior4 is now known as darosior
<darosior>
Presumably you are doing other things than managing your money on this web browser
<_aj_>
i don't feel like shooting down an idea while it's still being brainstormed is very helpful. there are half a dozen different ways you could manage that risk.
<darosior>
Fair enough, i think it's a concern worth being raised but i didn't mean to shoot down the idea
<_aj_>
(a) don't run your wallet on a mixed-use system; (b) bundle a dedicated broweser engine with the app; (c) use a dedicated browser for interfacing with bitcoin; (d) use a dedicated wallet gui like sparrow for the wallet, and use the bitcoin gui for managing the node; (e) rely on XSS/etc protections -- if your system as a whole is compromised, you're screwed no matter what anyway
<_aj_>
"would that even work in a way that doesn't just completely suck for both devs and users"