16:00:03 <fjahr> #startmeeting 
16:00:03 <corebot> fjahr: Meeting started at 2026-02-19T16:00+0000
16:00:04 <corebot> fjahr: Current chairs: fjahr
16:00:05 <corebot> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:06 <corebot> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:07 <corebot> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:13 <dzxzg> hi
16:00:14 <maxedw> hi
16:00:17 <sr_gi> hi
16:00:17 <fjahr> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack TheCharlatan vasild
16:00:17 <fjahr> willcl-ark
16:00:19 <sipa> hi
16:00:21 <brunoerg> hi
16:00:21 <dergoegge> hi
16:00:22 <eugenesiegel> hi
16:00:23 <theStack> hi
16:00:26 <marcofleon> hi
16:00:28 <jurraca> hi
16:00:31 <fjahr> There are two pre-proposed meeting topics this week. Any last minute ones to add?
16:00:31 <andrewtoth_> hi
16:00:32 <hebasto> hi
16:00:33 <furszy> hi
16:00:41 <fjahr> And I guess we will talk about feature freeze tomorrow briefly.
16:00:42 <stringintech> hi
16:00:47 <hodlinator> hi
16:01:12 <Novo> hi
16:01:31 <fjahr> Kicking off the WGs...
16:01:33 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:01:58 <l0rinc> hi
16:02:04 <darosior> hi
16:02:04 <dergoegge> no update
16:02:05 <kanzure> hi
16:02:10 <yancy> hi
16:02:17 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:02:23 <l0rinc> Benchmarked the costmodel for #34138 on several different platforms
16:02:25 <corebot> https://github.com/bitcoin/bitcoin/issues/34138 | Cluster mempool: more accurate cost model for SFL by sipa · Pull Request #34138 · bitcoin/bitcoin · GitHub
16:02:43 <sipa> Hi!
16:02:52 <l0rinc> Had lots of reviews on the #34280 - thanks, keep them coming
16:02:53 <corebot> https://github.com/bitcoin/bitcoin/issues/34280 | Coins Cache Cleanup checklist · Issue #34280 · bitcoin/bitcoin · GitHub
16:02:57 <l0rinc> that's it from me - andrewtoth?
16:03:07 <andrewtoth_> Lots of great review on #34165, thank you! Had others do more benchmarking on #31132. Thanks!
16:03:09 <rkrux> hi
16:03:11 <corebot> https://github.com/bitcoin/bitcoin/issues/34165 | coins: don't mutate main cache when connecting block by andrewtoth · Pull Request #34165 · bitcoin/bitcoin · GitHub
16:03:14 <janb84> hi
16:03:14 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:03:29 <pinheadmz> yo!
16:04:02 <fjahr> andrewtoth: anything else to add?
16:04:24 <andrewtoth_> that was it
16:04:28 <fjahr> #topic Silent Payments WG Update (Novo)
16:04:52 <Novo> It's decided now that we will be limiting the max number of sp outputs in a tx
16:05:18 <Novo> The current value is 1000. It is not part of the BIP yet and still being debated
16:05:32 <Novo> With this, we can solve the worst case scanning problem
16:05:48 <Novo> I also experimented with a parallel scanning approach https://github.com/bitcoin-core/secp256k1/pull/1765#issuecomment-3907225436
16:06:17 <Novo> Works pretty well, but might require changes to the API
16:06:59 <Novo> In practice, users should not need to do this since worst case scanning time with a maximum of 1000  outputs is in seconds
16:07:29 <Novo> Hence, there's not a lot of support to modify the API to support parallel scanning but we will see
16:07:42 <theStack> for the proposed K_max protocol change, I'm planning to open a BIP-352 PR today or tomorrow, with proper test vectors; no one has opposed the K_max=1000 suggestion, but different suggestions could still be made in that PR
16:07:56 <Novo> Nice theStack
16:08:17 <Novo> Nothing else to add
16:08:31 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:08:37 <sipa> We're getting very close with cluster mempool. #34023 was merged, and my last remaining PR is #34616 which I'd like to see in. There are a few more follow-ups like extra tests, RPC output, optimizations, and possible interaction with mining (to decide when to wake a waiting miners / cache blocks), but I think those aren't essential for feature freeze.
16:08:40 <corebot> https://github.com/bitcoin/bitcoin/issues/34023 | Optimized SFL cluster linearization by sipa · Pull Request #34023 · bitcoin/bitcoin · GitHub
16:08:41 <corebot> https://github.com/bitcoin/bitcoin/issues/34616 | Cluster mempool: SFL cost model (take 2) by sipa · Pull Request #34616 · bitcoin/bitcoin · GitHub
16:09:13 <sipa> That's it for me.
16:09:56 <fjahr> Thanks, I didn't see kernel or net split...
16:10:24 <fjahr> #topic v31 feature freeze
16:10:56 <fjahr> Anything to be suggested to be added or removed? Anything making a push back necessary?
16:11:39 <andrewtoth_> https://github.com/bitcoin/bitcoin/milestone/74
16:12:03 <fjahr> andrewtoth: Thanks, I was just looking for it :)
16:13:30 <fjahr> It's still a pretty long list, I didn't have time to go through it yet. Any comments?
16:13:39 <fjahr> Otherwise, please review!
16:13:49 <fanquake> I don't think there's anything that would require pushing back. Things just need review. Plenty of double-ups where it's the bug report + PR both tagged.
16:14:00 <fanquake> Mostly bug reports for bugs introduced in this cycle.
16:15:02 <fjahr> #topic Bump default -dbcache setting? (sipa)
16:16:02 <sipa> Hi, I've been thinking about this for a while, and it seems to me that the default dbcache setting (450 MiB) is a bit outdated for most systems these days.
16:16:29 <l0rinc> let me repeat what I posted here a few hours ago: `sipa,andrewtoth: please see my measurements in https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3646563048 where I've compared dbcache 100-7000. There is some difference between dbcache=400 (03:56:25 for 900k blocks) and dbcache=2000 (03:33:51 for the same), but after that there isn't any measurable speedup - unless it's on network storage or hdd.`
16:16:33 <l0rinc> `But note that after the PR validation with 100 mb dbcache is still slightly faster than than master with 7 GB. Extracted a few other measurements from the PR to`
16:16:55 <darosior> It has been outdated, but with the current RAM prices, it's back to totally fine :p
16:16:59 <sipa> darosior: haha
16:17:04 <theStack> :D
16:17:35 <l0rinc> as andrewtoth mentioned yesterday #31132 modifies this assumption and even dbcache=100 will be faster than master
16:17:38 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:17:41 <sipa> I understand that there are users who still run on minimal hardware, for which a default bump might not be appropriate, but still - I don't think there is really any problem with e.g. if you're on a 64-bit system and have say over 8 or 16 GiB of RAM, defaulting to 2 GiB dbcache
16:17:59 <darosior> 1GiB should be totally fine in my opinion, but i defer my judgement to people that actively monitor that area (like Lorinc and Andrew who chimed in)
16:18:27 <l0rinc> I can barely run an IBD on a node with 2 GB memory
16:18:50 <andrewtoth_> Yeah I think it would be a big speedup for network connected storage, which I think is the majority of nodes being run
16:18:54 <l0rinc> and after Andrew's parallelization change the difference won't be that big - can we postpone this decision after it lands?
16:18:56 <andrewtoth_> I'm more concerned about steady state than IBD. We don't periodically clear the cache anymore unless it grows too big. So, today users can run it for months/years and it won't exceed 450MB. If we update this default then maybe users who run their nodes on low memory systems and just set and forget will come back to an OOM crashed node after some months.
16:19:02 <darosior> Hasn't the expectation always been that people running on minimal hardware tweak their settings anyways? We have docs for this, and specs for minimal hardware must have been a lot lower a decade ago when we had the same default.
16:19:37 <sipa> l0rinc: my (largely unsubstantiated) guess is that there are settings (super slow spinning USB-connected disk) with very slow I/O, where even with parallel fetch, a large dbcache makes a big difference
16:19:59 <darosior> 2 GiB sounds good to me as a default too, for what it's worth.
16:20:07 <fjahr> It is also notable that this may be shared with the indexes if they are active
16:20:08 <Murch[m]> It’s my impression that especially a lot of the low-powered devices are run by people that don’t configure…
16:20:16 <l0rinc> yes, as mentioned above, HDDs are definitely affected even after the parallel fetcher
16:20:35 <l0rinc> most people I talked to (including node providers) are afraid to change the defaults
16:20:55 <pinheadmz> Murch[m] i wouldnt count on that, arent there plenty of SE questions about running on a Pi? suggested confs are easy to find
16:21:57 <darosior> Maybe a more conservative bump to 1GiB then?
16:22:02 <dzxzg> It would be nice if  out-of-memory behavior was better before/along with raising the default, e.g. monitoring memory pressure / available memory and dynamically decreasing sizes of caches to avoid OOM
16:22:19 <l0rinc> it was changed a decade ago from 100 to 300: https://github.com/bitcoin/bitcoin/commit/32cab91278651d07a11132b7636dc3d21144e616#diff-d102b6032635ce90158c1e6e614f03b50e4449aa46ce23370da5387a658342fdR25-R27
16:22:37 <Murch[m]> Yeah, l0rinc, wasn’t there something that limited the `dbcache` setting on basis of the RAM we had to 75% of the RAM?
16:22:50 <andrewtoth_> dzxzg: yeah, having something like #19873 would make this an easier discussion.
16:22:52 <corebot> https://github.com/bitcoin/bitcoin/issues/19873 | Flush dbcache early if system is under memory pressure by luke-jr · Pull Request #19873 · bitcoin/bitcoin · GitHub
16:22:56 <_aj_> l0rinc's graph suggested 1GB would get most of the benefit, i thought
16:23:05 <l0rinc> yes, we have a warning now if the dbcache is too high compared to the total ram
16:23:41 <l0rinc> I could get behind that if we separated dbcache during and after IBD (which we partially do already by stealing the mempool memory)
16:24:13 <sipa> fwiw, i'm motivated by seeing people complain about days-long syncs - which usually is a sign there is more wrong than just dbcache, but it keeps reminding me that i think 450 MiB is silly today
16:24:46 <Murch[m]> Well, it is plenty in the steady state at the chaintip…
16:24:57 <sipa> yeah, this is just about IBD
16:24:57 <hodlinator> couldn't it be a sign of trying to fit the UTXO set in the -dbcache and running into swapping issues?
16:25:12 <hodlinator> ...due to running out of RAM
16:25:45 <sipa> hodlinator: not in the recent example (#34601) i think, but yes
16:25:46 <corebot> https://github.com/bitcoin/bitcoin/issues/34601 | bitcoind sync gets very, very slow on Augst 2023 in btc chain (maybe 2/3 progressed or something like that) · Issue #34601 · bitcoin/bitcoin · GitHub
16:25:49 <Murch[m]> Yeah, I heard that malarkey a few times, too, that people thought dbcache has to be bigger than the UTXO set. But we should catch that with the warning, right?
16:26:12 <l0rinc> it could, that's why we have the new warning now - and why I opened #34606
16:26:13 <corebot> https://github.com/bitcoin/bitcoin/issues/34606 | [RFC] common: warn on high swap usage by l0rinc · Pull Request #34606 · bitcoin/bitcoin · GitHub
16:26:15 <andrewtoth_> l0rinc: agreed, switching to lower dbcache after IBD would make this safer
16:26:33 <hodlinator> yes, it should warn, provided the user runs a newer version.
16:26:46 <andrewtoth_> bumping to 2GB during IBD on 64 bit systems then lowering to current default after IBD would be great
16:27:09 <jonatack> hi
16:27:19 <darosior> andrewtoth_: why safer? More optimal maybe, but i don't see how a larger dbcache makes things less safe at tip.
16:27:21 <_aj_> good grief, the utxo set via usb2?
16:27:22 <sipa> andrewtoth_: that seems weird to me, if you have enough memory for one, why not use it all the time?
16:27:24 <l0rinc> I don't mind pushing a PR that creates a 2 gb default for anything having e.g. 8 gb total memory and reverting to 450 after IBD
16:27:50 <sipa> if the concern is OOMing later, we can try a preallocation run - just fill the dbcache once at startup and wipe it
16:27:58 <l0rinc> but even 2 GB is too high for a 4 GB machine
16:28:18 <Murch[m]> sipa: People run all sorts of other stuff on their Bitcoin boxes now, but most of it only after IBD. So they might have more RAM for bitcoind before IBD is finished
16:28:40 <sipa> yeah fair
16:28:47 <andrewtoth_> what Murch said
16:28:50 <darosior> I see
16:28:56 <darosior> Would everyone be happy with a 1GiB default? That's already more than twice as better as today, and could mitigate the concerns raised here?
16:28:58 <dzxzg> It would be good to know connection times at the tip as a function of dbcache size
16:29:30 <l0rinc> I have regular OOMs on 2GB and 4GB boxes ... everything seems fine and after a while something triggers an OOM even with the safety nets. These are so close to the limit by default
16:29:32 <darosior> s/twice as better/twice better/ oui oui baguette
16:30:02 <andrewtoth_> dzxzg: I am trying to measure that for #31132. With default dbcache today the cache is not flushed for about 3 weeks. So it's a long thing to measure.
16:30:05 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:30:11 <Murch[m]> 1 GB seems like an improvement. It would be great if we could do something conditionally on how much RAM the system has
16:30:12 <darosior> l0rinc: by this token we will never be able to bump defaults ever again, because someone will still have a 4GiB box somewhere a decade from now
16:30:41 <darosior> We have configuration for a reason, defaults should represent the vast majority of users, not the lowest common denominator possible?
16:31:15 <fjahr> 1 GB sounds like a good compromise to me, again, also keep in mind this may be shared with the indexes
16:31:22 <lightlike> is the suggested bump meant to go into v31 still?
16:31:23 <sipa> i also like the idea of having presets, like are you running in a very resource-constrained system, or a giant machine? which could control things like dbcache, mempool size, network buffers, connection counts, ...
16:31:35 <_aj_> pruning
16:31:46 <sipa> which may be more interesting for config-averse people to choose than manually tweaking values
16:31:51 <Murch[m]> sipa: That sounds interesting.
16:31:54 <darosior> sipa: makes sense.
16:32:03 <l0rinc> I'm all for e/acc, it's just something I see on the lower-end devices - I would go for 100 if lower than 2 GB, 400 if lower than 4 GB and 1 GB if higher
16:32:20 <sipa> #8437 :p
16:32:21 <corebot> https://github.com/bitcoin/bitcoin/issues/8437 | Separate resource usage profiles · Issue #8437 · bitcoin/bitcoin · GitHub
16:32:52 <andrewtoth_> l0rinc: I think you need to configure to get it to run on 2GB at all, right?
16:33:04 <_aj_> would just providing example three configs be a good/easy way of doing that?
16:33:10 <l0rinc> yes, that already needs a -dbcache=100
16:33:12 <dzxzg> I think it's confusing to have to tweak the size of each of bitcoind's memory pools individually, instead of setting a single resource usage target
16:33:15 <Murch[m]> Maybe we can reconsider that in light of it’s 10th anniversary coming up ^^
16:33:25 <sipa> (its)
16:33:47 <andrewtoth_> I think 1GB would be an improvement. Put it front and center in the release notes.
16:34:04 <darosior> yay
16:34:18 <sipa> 100 / 400 / 1000 depending on ram size makes sense to me
16:34:25 <Murch[m]> In before “Bitcoin Core hates Raspberry Pi users!”
16:34:27 <Murch[m]> :p
16:34:31 <andrewtoth_> lol
16:34:32 <sipa> yes, i mean for 31.0
16:34:52 <andrewtoth_> sipa, l0rinc: yes, 100/400/1000
16:35:00 <Murch[m]> sipa: I thought that it was not available on all systems or smth
16:35:02 <l0rinc> "Put it front and center in the release notes" - clarifying that this isn't because we want more spam :p
16:35:12 <Murch[m]> As in, we don’t know in Bitcoin Core how much the system has?
16:35:32 <sipa> Murch[m]: we always know if we're on 32-bit vs 64-bit, unsure about accessing ram size on every OS
16:36:09 <jonatack> presets changing multiple config options as a user-friendly suggestion sounds good indeed
16:36:16 <_aj_> it's only going to be linux/bsd that have low memory though?
16:36:44 <sipa> _aj_: i'd guess that many people run on old windows boxes
16:36:46 <jonatack> if feasible, avoiding too much devilry in the details
16:37:03 <l0rinc> we have access to total memory, introduced in https://github.com/bitcoin/bitcoin/pull/33333/changes#diff-248c2f4789084c026a9c5a8e718cc117b9d32ffb91a09f541ae1abc0eef7e6f6R114-R123
16:37:34 <Murch[m]> well then, default based on available RAM sounds like a great idea!
16:38:19 <sipa> ok i think we can conclude this topic and discuss on a PR if someone(?) creates one
16:38:23 <darosior> Murch[m]: doesn't that contradict your previous point that it's going to make the process OOM if the user runs anything else besides bitcoind?,,
16:38:34 <yancy> availble ram or total system ram?
16:38:41 <darosior> sipa: +1
16:38:48 <fjahr> Yeah, let's continue
16:38:50 <fjahr> #topic Embedded asmap release todos (e.g. https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2826579455) (fjahr)
16:38:51 <l0rinc> I'll push a PR for that today, thanks for the feedback. To be clear, should we revert to a lower value after IBD or should we choose values that make sense regardless (excluding the barrowed mempool 300 MB)?
16:39:00 <fjahr> I didn’t have time to prepare anything for this but since it came up and might be relevant for the wider group, I thought I would make everyone aware of the ideas in the comment thread there.
16:39:08 <fjahr> tldr; the ideas are: moving the asmap-data repo into bitcoin-core org, letting participants of the collaborative runs sign their results and transcript with the necessary script and place for sharing, sharing the raw data before processing, notifying users of an older asmap data (potentially only after default).
16:39:12 <darosior> l0rinc: in my opinion this should be a separate improvement.
16:39:16 <fjahr> Note that these ideas are in addition to the suggested process already described here: https://github.com/bitcoin/bitcoin/blob/master/doc/asmap-data.md
16:39:23 <fjahr> Anything that people would like to add or comment on there? I will collect and track them in the asmap issue.
16:40:16 <sipa> moving asmap-data to bitcoin-core org makes sense, as does having some kind of attestation process for collaborative asmap creation participants, effectively signing off on "i ran kartograf with these settings at this point in time, and obtained this"
16:41:23 <Murch[m]> darosior: That was meant to be a point why 1 GB might be too big, when a box has only 4 GB
16:41:54 <Murch[m]> But if we generally pick defaults based on RAM, we’d probably do something smaller for a 4 GB box?
16:42:22 <l0rinc> I'll add a PR for that and we can discuss there, thanks for the feedback!
16:42:28 <Murch[m]> Sorry, can talk more later. Different topic now.
16:43:12 <fjahr> Ok, I guess the RAM question is still more exciting than this question. Still feel free to comment here or in the links later if you have opinion.
16:43:14 <fjahr> Anything else to discuss?
16:43:39 <andrewtoth_> fjahr congrats on getting asmap merged!
16:43:50 <darosior> Are people interested in picking back up the GUI topic from last week. I didn't attend but reading the backlog it doesn't seem like much was decided.
16:43:58 <Murch[m]> I haven’t looked much into it, but if we’re shipping the ASMAP default, putting the attestation into the Bitcoin Core org makes sense
16:43:59 <fjahr> andrewtoth: thank you :)
16:44:29 <darosior> I guess i didn't see hebasto nor achow and we'd need them to discuss GUI stuff..
16:44:47 <hebasto> darosior: hi
16:44:50 <fjahr> Murch: default on is for the future but the process should keep that in mind already I think
16:44:51 <darosior> oh hi
16:45:51 <darosior> hebasto: anything to add, following up on last week's discussion? What should be the way forward?
16:46:29 <fjahr> I think the outcome was we should wait with a final decision until we meet in person?
16:47:12 <fjahr> Seems like people are exploring options, like will's vibe code rpc experiment
16:47:12 <darosior> It does not seem like any of the discussion we've had in person have ever made this move forward.
16:47:16 <fanquake> It'd be good to know about #33684 (given the Qs there, or maybe have a dedicated issue). There doesn't seem to be an answer to where new features should be added? Seems like something we should know, to unblock progress/prevent wasted work/have any clarity.
16:47:18 <corebot> https://github.com/bitcoin/bitcoin/issues/33684 | Async Payjoin · Issue #33684 · bitcoin/bitcoin · GitHub
16:47:30 <hebasto> fanquake posted a detailed plan that allows us bring more gui-only deps into the release process -- https://github.com/bitcoin/bitcoin/issues/29914#issuecomment-3921585808
16:48:10 <johnny9dev> I did some work as well since last week to get everything for gui-qml in a PR or merged so all work from last year is in the default branch for it. I have also given hebasto a feature comparison summary
16:48:20 <hebasto> ^ this
16:48:21 <fjahr> darosior: is that a problem with the topic or meeting in person?
16:48:31 <darosior> :)
16:48:46 <fanquake> johnny9dev: so you're working on something that is going to whotely replace the current widgets gui right?
16:49:03 <fanquake> *wholely
16:49:12 <johnny9dev> I think so.
16:49:12 <sipa> wholly?
16:49:14 <darosior> So is the plan to replace the QT widget GUI with the QML GUI?
16:49:31 <darosior> Would this be IPC based?
16:49:38 <hebasto> not now
16:49:42 <fjahr> I think having some time to think about it and explore options is good, I haven't had time to look into it more because of getting stuff done for feature freeze
16:49:43 <johnny9dev> last year I wouldnt have agreed to such a think but today with the tools we have. i might
16:50:27 <fanquake> johnny9dev: great, can we get a writeup or similar, that explains the architecture, dependencies needed, how are we going to decouple it from the current code, etc
16:50:40 <sedited> darosior's delving post was also discussed here, which at least gives a taste of what gui users might think of it https://stacker.news/items/1436922
16:50:51 <fjahr> Maybe a way to encourage this would be to let people note down where they currently stand in a table similar to what we had on controversial issues in the past? Does that sound interesting?
16:50:51 <johnny9dev> yeah, I will work towards that and get some help from hebasto as well
16:50:54 <fanquake> I guess this means that currently, nothing is being added to the gui, until qml ships?
16:51:08 <hebasto> correct
16:51:17 <hebasto> once the release process is safe regarding more gui deps, we will be able to switch to qml
16:51:25 <darosior> sedited: oh, i hadn't seen that, thanks.
16:51:46 <fanquake> It's not just the release process. i.e the whole subtree thing needs to be fixed/
16:52:06 <dzxzg> given that the timeline for qml is not bounded, does it make sense to stop adding features to qtwidgets?
16:52:15 <hebasto> subtree is minor issue, I have a wip branch
16:52:35 <fanquake> and process separation?
16:52:40 <hebasto> dzxzg: it is de-facto
16:52:59 <hebasto> process separation is a next step
16:53:09 <dzxzg> hebasto: To make sure I understand, you mean that as a fact, no one is adding features to qtwidgets today?
16:53:13 <fanquake> I take it nothing is blocked on designers now either?
16:53:35 <hebasto> right
16:53:56 <Murch[m]> interesting thread, sedited
16:54:20 <hebasto> dzxzg: noone is actively reviewing already suggested features
16:54:33 <darosior> What's the status of the QML GUI, as in, in your branch johnny9dev? My understanding was that it was still under heavy development, but is it now close to feature complete?
16:54:55 <hebasto> feature comparison tables will be available shortly
16:55:06 <dzxzg> hebasto: That makes sense, I would just oppose it as a matter of policy, e.g. if people do start showing up and reviewing gui PR's, I don't think they should be rejected on the basis of the qtwidgets gui being replaced with qml,
16:55:27 <hebasto> dzxzg: sure
16:56:09 <darosior> dzxzg: Is adding new features to the GUI even a goal? My understanding was that its main purpose was backward compatibility to support existing users, but that if you wanted a neat GUI with all the new features, other projects already do it better, and are a more appropriate place for further development.
16:56:20 <johnny9dev> there is work to do for sure. working towards understanding how close at the moment.
16:56:54 <fjahr> 3 minutes left...
16:57:05 <sipa> darosior: people might not agree on what the goal is
16:57:09 <dzxzg> darosior: I mean it may not be a goal for you
16:57:40 <pinheadmz> darosior personally, if the gui had harwarde wallet support i would never need another bitcoin program, i want that for myself ;-)
16:57:53 <sipa> we could agree on explicit goals, but that doesn't align well with the notion of not telling people what they should work on
16:57:59 <darosior> it's not like it does not come with its own externalities
16:58:03 <pinheadmz> so i guess that feature should go in QML then ?
16:58:04 <fanquake> sipa: ideally we can agree on goals like, not wasting developers time, by not having any clarity around what the project is doing
16:58:28 <fanquake> i.e: someone shows up implementing a new gui feature, unaware that nothing is going to be added to the current gui, or they should have added it to qml
16:58:29 <fjahr> johnny9dev: If we continue with the qml gui as originally planned I think it would be good to make a plan for attracting new contributors in a more serious manner as well
16:58:31 <sipa> fanquake: agreed, but i think it's more a matter of setting expectations than strictly deciding what is being worked on
16:58:31 <darosior> If it was a separate program in a separate project, i agree, if people are interested in doing stuff, good for them, good for their users. But the reality is not so.
16:59:02 <fanquake> given that qml has taken 5 years, and not shipped, seems like a good time to try clarify some of these things
16:59:38 <dzxzg> it kind of seems like shooting oneself in the foot to stop all qtwidgets gui development in the hope that someday it's replaced by qml, if you dislike the gui you may not see it that way since it perpetuates the present problems with the gui
16:59:41 <hebasto> again, with https://github.com/bitcoin/bitcoin/issues/29914#issuecomment-3921585808, I can see now a straight path for switching to qml
17:00:00 <fjahr> I guess we can continue the conversation next week :)
17:00:04 <fjahr> #endmeeting