Who is the GUI being designed for? -Continued Discussion-

[Bosch-0]

I'd like to continue the discussion from #17395 over at the bitcoin repo started by @michaelfolkson.

The two questions posed by Michael a long with summarized replies from the original thread are below. As someone who is interested in contributing to the design of the GUI I've also included some of my own opinions throughout.

1. Who are we designing the GUI for? Long term Core contributors (highly technical) that use the GUI on a regular basis? I don't know how many of these there are. Technically curious who use the GUI when they can't work out how to do something from the command line? Complete Bitcoin beginners? All of these groups? If it is the latter then we should all be under no illusions that compromises are necessary which will mean it is impossible for the design to be optimal for an individual group.

2. Design preferences are subject to the "sample size of 1" trap where those reviewing GUI changes think they are providing feedback on behalf of a group that they don't belong to. A highly technical user just does not know what is optimal for a beginner. The only way you see what is optimal for a beginner is putting alternative GUIs in the hands of a statistically significant group of beginners.

• The GUI is intended for 'power users,' not beginners, intermediate or devs. Power users being those who are technically competent to run their own node, have basic CLI skills, but are still more comfortable with a simpler UI.

I think devs also fall within the user base albeit not as frequent as the power users (say if the dev wants to do a simple task in a few clicks). Over time and with good design we can include all users (see below).

• In the future the GUI should also include beginners and intermediate users, although not at the expense of removing important features or negatively impacting security, privacy, control etc.

I don't see this as an issue as good design should be able to cater to both experienced and inexperienced users. As an example see this exchange which offers different interfaces for differing user skills - taken from crypto UX handbook. Good usability is synonymous with good security - Casa articulates this much better in their wealth security protocol.

• The GUI does not need to be flashy / modern looking.

I agree with this but this is in many ways unrelated to good design. A flashy look can increase usability is not synonymous with Aesthetics. As long as its fulfills its job thats all the matters. At this stage that job being having any level of user being able to run a node and have a wallet attached to that node (whether wallet features are used in the GUI or

• Designers need to work within the constraints of Qt.

Good point to make but I don't think the constraints are as big as made out to be in the original thread. As Christoph Ono, who worked on the designs for the Monero GUI which also uses Qt, pointed out a small team managed to revamp the UI/UX of the GUI over a few years without too many issues, see here. @GBKS

• Having a modular GUI / multiple implementations to cater to different user bases.

As I mentioned above I think good design can cater to all audiences within the same app, having a modular GUI is not an efficient way to go about things in my opinion.

• What is the main purpose of the GUI? "Note that the GUI is needed for more than just the wallet... right now, it is the only realistic way for a normal end user to run their own node at all." @luke-jr

Luke also mentions "...Bitcoin's security depends on a super-majority of the economy using their own full node." This isn't possible without including beginner and intermediate users which can only be done through well articulated design.

Although this will likely be a controversial take, is the discontinuation of the GUI once enough options exist outside of core for users to run a fully validating node an option? Projects such as Umbrel and myNode are good examples of non-GUI fully validating nodes. If these become more popular among users for running a node than the GUI, is the resources put into it worthwhile when they could be applied to making bitcoins foundations even stronger?

• Many usability improvements are being worked on on the technical side - 1 2 3

With initiatives such as Bitcoin Design and square crypto design grants on offer, many more designers are likely to start contributing to open source bitcoin projects like the GUI. It's important that discussions like this happen so that designers and devs are on the same page.

I'd encourage devs to join the bitcoin design slack and for designers to frequent this repo and join in on discussions when they can.

[michaelfolkson]

Thanks for opening this @Bosch-0 and for the summary.

It was great some long term contributors chimed in on the previous thread to get an insight into their thinking but remember the nature of this project is there is no ultimate authority to determine once and for all who the targeted user base for the GUI is. This is one frustration I am sure at least some designers coming into the project will experience that they probably haven't experienced on other projects (in addition to the emphasis on security, conservatism even if at the expense of user experience). This is one of the reasons @Sjors recommends "incremental UI changes."

This is not to dissuade designers from enthusiastically contributing to the project as there is definitely scope for improvement. Not only to improve the quality of the GUI but also to improve the quality and efficiency of review. The revamp of the Monero GUI is an interesting case study which perhaps encountered many of the same challenges as this project. Having said that I still expect the conservatism and inability to drive changes without consensus are taken to another level on this project.

Although this will likely be a controversial take, is the discontinuation of the GUI once enough options exist outside of core for users to run a fully validating node an option?

I don't expect the Bitcoin Core GUI will ever be ditched (there will be always be a use for a solid, reference GUI) but I do expect there to more innovation and more experimentation on GUIs that don't have to go through the Core review process and perhaps aren't quite as focused on security, conservatism and consensus. I suspect the designers that will be attracted to this project will be the ones that want to learn more about Core beyond design and those who want to focus entirely on design with greater autonomy will gravitate towards other projects. (I could be wrong though!)

[Rspigler]

I agree with @michaelfolkson - I know that I will always want to use the reference implementation for the node, wallet, and GUI, and I imagine other conservative users in security critical applications will want to as well.

[moneyball]

I am curious how much discussion there has been about how, and how should, Core GUI wallet users store and spend their bitcoin. For example:

• Use their daily-use laptop or desktop computer to run the Core GUI wallet? Or, own a separate dedicated-use computer?
• Use their daily-use computer to handle sensitive private key? Or, use an air-gapped dedicated-use computer? Or a hardware wallet?

Given the prevalence of malware, and that many users do not or can not or will not buy and configure separate, dedicated computer, it seems to me a common configuration would be to run the Core GUI wallet on your daily-use computer combined with a hardware wallet for handling the private key including signing transactions. If so, it seems like priority features to optimize a design around include:

1. Support in the GUI for popular hardware wallets such as Trezor, Ledger, and Coldcard
2. Support in the GUI for watch-only wallets that are based on BIP39 (as the wallet likely was generated from the hardware wallet, not the daily-use computer running Core).

Thoughts?

@gwillen @Sjors @achow101 @luke-jr @hebasto @jonatack @jonasschnelli @MarcoFalke @gbks @jamaalm

[jonasschnelli]

@moneyball

Ideally, we give users the choice. Important then would be to inform them about the up- and downsides of their choice. What I would like to see is a guided wizard when first starting bitcoin core (or when creating another wallet).

privacy / trust

• Core GUI should ask/inform about the benefits and limits of tor. Ask for enabling it
• GUI should ask if the users wants block-filters/SPV (up and ready in 3mins, reduced validation)
• GUI should ask if it should do a full validation (when SPV was enabled; if, it can validation "in the background")
• • verify all scripts or assumvalid?
• ask to enabling pruning yes/no,... if full validation was selected

wallet

Hardwarewallet integration would be awesome. I just don't know how easy it is to bundle with Core/GUI. I guess building that USB stack and proprietary transport protocols for each HWW is hard and eventually outside the scope. I still think there should be a standard how the GUI can communicate with the software each HWW manufacturer provides. I once proposed a URI scheme that could handle that. Running a python stack besides the GUI is not user friendly. I still think Core should communicate with the HWW Vendor software and not with the hardware directly. One needs the vendor software anyways.

Though, there are valid use cases to use hot keys (even on your daily use system). Say you want some 100-200$ value for tips, tests, etc.. On top, the use case of an offline air-gapped Core UI should also be supported (PSBT).

Creating a wallet should:

• As if it should use HWW
• Should create a air-gapped watch-only wallet?
• • maybe Core could check if the machine is really off-line and warn if not
• Should use hot-keys (inform users about the up-/downsides)?
• Should encrypt the keys (inform users about the up-/downsides)?

Of course its conceptually missing all the cool multisig stuff. Supporting BIP39 is pretty easy (for watch-only wallets / I guess we don't want to use it for our hot key wallets).

[GBKS]

So I'm trying to see this through the lens of how people may go about managing their finances and the risk/convenience trade-off. For daily spending of small amounts like coffee or groceries, I may want to use a seedless mobile wallet (probably Lightning). For my monthly budgeting (rent, utilities, car payment, topping up my daily spending account), the amounts are higher and I make transactions less frequently, so a desktop wallet is probably better (maybe with a hardware signing device). For an emergency budget or when saving for larger expenses, I probably want extra security and set up a desktop wallet with 2-of-3 multi sig (and a watch-only setup). For long-term savings, I might need to go even a step further based on the amounts (like Glacier Protocol in the extreme). Now this does not include any interactions with third-party financial services and it's also not realistic at the moment since the world does not run on bitcoin. And on an individual level the needs can be totally different based on country, culture, age group, etc. But I still find it a helpful perspective in the mix. From that angle, it is pretty important to have multisig, hardware wallets and watch-only wallets working seamlessly together so i can scale up my security based on my financial planning.

Another angle is the tradeoff between being a Swiss army knife and a highly focused application for very particular use cases. Right now I see Bitcoin Core (and GUI) as more of a Swiss army knife. Trusted, good quality (as in reviewed code), plenty of features, but you need to know how to use them the right way. Consumer apps a lot of times take the opposite direction where they streamline everything into very specific user flows for the most common tasks. It's not a clear-cut distinction, but maybe it's generally good to have an understanding which direction is preferred? If the software itself is more of a tool, then maybe more effort could go into external documentation on how to use it for different use cases (rather than baking it into the software).

@moneyball I am curious about the "prevalence of malware" statement. Is there any data on that? Just trying to get a sense of how severe the issue is and maybe what the most common attack vectors are.

Great to talk through this stuff.

[moneyball]

@GBKS I don't have a specific source that I know is reliable, but 10 minutes of Googling led me to numerous reports and statistics suggesting malware is a very significant problem (eg 30% penetration rate). But regardless of what it has been, we know that it is relatively easy for users to get malware on their computers, and if it becomes popular for millions of people to access their private keys on their daily-use computer, attackers will surely target that.

As a thought experiment, if we're imagining a future whereby millions or tens of millions of people are self-custodying their bitcoin, and we're encouraging them to use a wallet that accesses private keys from their daily-use computer, what % of users having all of their bitcoin stolen from malware is acceptable? Compared to the alternatives of accessing private keys on phones or on dedicated hardware wallets, a daily-use desktop computer seems a poor choice.

I'm definitely interested to hear others' thoughts on this.

[Bosch-0]

privacy / trust

Core GUI should ask/inform about the benefits and limits of tor. Ask for enabling it GUI should ask if the users wants block-filters/SPV (up and ready in 3mins, reduced validation) GUI should ask if it should do a full validation (when SPV was enabled; if, it can validation "in the background") verify all scripts or assumvalid? ask to enabling pruning yes/no,... if full validation was selected

Are the limits that significant? If so to who? Having Tor as something that is enabled by default would be a good standard to push. If the limits aren't that significant do you even need to tell the user Tor is being used and just have it always on in the background? However, advanced users should have the option to dive into the settings to play around with Tor options.

This could be a double edged sword, majority of users will likely opt for the SPV mode over fully validating. Shouldn't we lean users towards running fully validating nodes? The middle ground option of having full validation occurring behind the SPV could work. The Monero GUI currently has this option and calls it a 'bootstrap node.'

An on boarding wizard is definitely something worth having, I have discussed this with @hebasto and will be posting up an issue with some design ideas for this likely today. Looking to have it in stages with node options in V1 and then more technical changes (wallet creation, HWI intergration etc.) in later versions. Here is the frame that focuses on nodes setup.

Aiming to address some of the points you made for wallets here https://github.com/bitcoin-core/gui/issues/77

...Swiss army knife and a highly focused application for very particular use cases... > ...It's not a clear-cut distinction, but maybe it's generally good to have an understanding which direction is preferred? ...If the software itself is more of a tool, then maybe more effort could go into external documentation on how to use it for different use cases (rather than baking it into the software).

I like the swiss army knife analogy, I think the GUI should not streamline things too much but it should also not be completely out of the scope of beginner to use it (we want more nodes, don't we?). BTCPay server has lots of technical features / awkward user flows but they remedy this by having some really good documentation, I think this could also be a useful approach for the GUI whilst simultaneously improving said flows.

Agree with @moneyball that HWI should be a top priority.

So I'm trying to see this through the lens of how people may go about managing their finances and the risk/convenience trade-off. For daily spending of small amounts like coffee or groceries, I may want to use a seedless mobile wallet (probably Lightning).

I've always seen that small payments / wallet balances more suited to mobile wallets whereas the GUI would be more for medium / large payments that need that extra security / privacy guarantee a desktop application (preferably using a HW) offers.

[Bosch-0]

Hardware wallet integration would be awesome. I just don't know how easy it is to bundle with Core/GUI.

Instead of bundling it with the GUI could a workaround could be to have a bridge that could be downloaded and run separately? Trezor bridge and btcpay vault do this.

[jonatack]

Having Tor as something that is enabled by default would be a good standard to push. If the limits aren't that significant do you even need to tell the user Tor is being used and just have it always on in the background? However, advanced users should have the option to dive into the settings to play around with Tor options.

ISTM that Bitcoin Core creates an onion service by default if Tor is configured and running on the machine. All the user has to do is set up Tor on their machine and ideally have it auto-launch on startup.

See section 3, Automatically listen on Tor, in doc/tor.md.

[Bosch-0]

@jonasschnelli

GUI should ask if the users wants block-filters/SPV (up and ready in 3mins, reduced validation)

Is this technically feasible at the moment? I really like the option of a bootstrap mode with background validation (I don't think SPV only mode is a good idea however). If users use this mode would it be beneficial to only connect to Tor peers until the IBD is finished? Here is a quick on-boarding concept:

[Bosch-0]

Relevant comment to this thread https://github.com/bitcoin-core/gui/pull/96#issuecomment-705046732 from @harding

FYI, no released version of Bitcoin Core has ever created encrypted wallets by default; this PR just preserves that legacy.

As background, there's an open question between experts about whether or not the use of wallet encryption in typical user wallets saves more money than it loses. It saves money if someone gets a hold of just your wallet file (if they get direct access to your computer, they can observe your passphrase and steal your funds any way). It loses money if you forget your passphrase. Some experts believe the number of occasions where a wallet file has fallen into a attacker's hands without that attacker getting direct access to the user's computer is small compared to the large number of occasions where a user has forgotten their passphrase, so it's on average safer not to use encryption.

(I don't hold a strong opinion here myself. I assume that any bitcoins stored in my hot wallet will be stolen someday and prefer leaving my wallet unencrypted so I'm likely to learn about the theft as early as possible.)

[harding]

@Bosch-0

Is [SPV mode] technically feasible at the moment? I really like the option of a bootstrap mode with background validation

No, that's currently not possible with Bitcoin Core. I know @jonasschnelli was working on that in the past, but I'm not aware of any recent work. More recent work has been on an "assumeUTXO" mode; in that case, you wouldn't need to trust an external node as the UTXO set you downloaded would be compared to a checksum hardcoded in the software. You would be trusting the developers of Bitcoin Core, but users may already trust devs to a certain degree and auditing the correctness of a UTXO state should be very easy compared to auditing most code.

[Bosch-0]

Giving some life back to this discussion. Jamaal a UX researcher has been doing some work on this exact topic. His research will likely be published in the coming months. Here is a YouTube video that gives an overview of his preliminary findings: https://www.youtube.com/watch?v=xi2fEoXIpr8

[Rspigler]

Thanks! Will watch and looking forward to the published findings

[Bosch-0]

Update from my post above, here is a recording of Jaamal going over Project Horizon: https://www.youtube.com/watch?v=oZkBU5H2WjY

[Rspigler]

I want to thank you and the rest of the design team for the research and rest of the work you have been doing!

Here are the notes I took away from the presentation as the most requested:

1. update flashiness
2. Info on what a node is, syncing, etc. Basically - guideance for noobs.
3. SPV (https://github.com/bitcoin/bitcoin/pull/9483)
4. Non-digital backups
5. Multi-sig Coordinator (https://github.com/bitcoin/bitcoin/issues/21278) (https://github.com/bitcoin/bitcoin/issues/21071)
6. Repeat seed tests/reminders (https://github.com/bitcoin-core/gui/issues/185)
7. Better privacy (https://github.com/bitcoin/bitcoin/issues/19148) (https://github.com/bitcoin/bitcoin/issues/19035)
8. Allow for recording fiat amounts
9. Encrypt meta-data (https://github.com/bitcoin/bitcoin/issues/18085) (https://github.com/bitcoin-core/gui/issues/151 - doc fix)

(Will edit with links to existing issues/PRs) Done

I am very shocked to hear that it was hard to find GUI Core users. I definitely am one. I know there has been some discussion in the past of a possible future where Bitcoin Core drops the wallet, but I would definitely NACK that. While a bug in the wallet can't have network wide consequences like a bug in consensus code could have, a bug in the wallet could have disastrous personal consequences for users. I will always want to use the reference implementation for my node /and/ wallet. I know that currently the Core wallet is not as feature heavy, but there is no other wallet with as much peer review, and that shouldn't be taken for granted.

The goal IMO should therefore be to expand the feature set of Core's GUI, not to have users switch to another implementation. There has been great work ongoing with Core's wallet and GUI in the recent year, and there is no reason to stop this (descriptor wallets, PSBTs, HWI, etc).

Separating the GUI repo has been very successful, which has included grants, reworks of the onboarding process, etc.

I am strongly against Bitcoin Core GUI becoming a dev product only.

People largely run nodes for non-tx based reasons

This is also very shocking and unfortunate, and means we need to do much better on education

[Bosch-0]

Below is the insights gained from the research with comment:

1. BTC Core wallet is often quickly abandoned by new GUI users.

Bit confusing interchanging between the term BTC Core wallet and GUI - this is only GUI specific.

There wasn't much insight as to why this is the case. Why do people download the GUI in the first place? I would assume its that the core GUI being the most audited / secure wallet. This is a huge determining factor as to why people choose wallets as stated in insight 2.

New bitcoin users would most likely abandon the GUI due to its more technical nature / lack of tools they would be familiar with in other bitcoin wallets (such as the use of hardware wallets). More experienced users would likely abandon it due to similar reasons around tooling. Using a hardware wallet on a less secure wallet than core is probably more secure than using the GUI in a hot wallet type state of which is currently the only option. The more technical users, such as developers, would most likely be using the CLI and wouldn't necessarily abandon the GUI but would just rather use something more familiar to them / give them flexibility on the tooling available of which the GUI can not offer.

This puts the GUI in this weird limbo where it really isn't appropriate for any users in its current state.

How do we stop people abandoning the GUI? Hardware wallet integration (of which is being actively worked on despite research insight 8) would be a great way to get those more experienced users who don't mind the trade-off of lower usability for better security, but aren't technical enough to be solely on the CLI. This is a technical hurdle to overcome, not a design one.

2. The primary function of a wallet for most ardent bitcoiners, is saving and safeguarding value.

The GUI in its current state isn't suited for this as stated in the research. This is due to its lack of hardware wallet integration and easy multisig setup imo. These two schemes are the primary way to save and safeguard your bitcoin.

What to gain from this insight? This is another technical hurdle not a design issue, it is being worked on.

3. For those transacting in Bitcoin, Core doesn't fulfill accounting, mobility, convertibility or privacy needs.

I kind of agree with this but all the pieces are the their it just needs better UX/UI to make it easier to navigate.

What to gain from this insight? This is something designers could work on though there is a lot of constraints on usability using Qt Widgets (which we are sticking with for the foreseeable future) which wasn't considered in this research. Having external price feeds would be against core's ethos and isn't really necessary for the more hardcore bitcoiners of which this product is more suited for.

Switching to Qt QML would help a lot with making this easier to implement design changes due to its flexibility. On the technical side implementing database encryption would do wonders for the GUI's privacy / usability - no one wants a wallet (that may always be active if you're running your node) with hot keys sitting open on their desktop that anyone can easily view the balances of. Being able to have bitcoind running whilst the database is encrypted would be ideal UX.

As above, there is many technical hurdles to overcome before big usability changes can begin to be worked on.

4. Simplified transactions/UTXO management can ease accounting challenges and enable quiet privacy preservation.

Same comments as above - the GUI doesn't do that bad a job here though it could be better but it's constrained by Qt widgets.

5. Developers are the primary active users of BTC Core wallet, and not for the GUI.

Generally this is the case for CLI's. Why don't they use the GUI? See my comments on insight 1 above.

There was a lot of discussion around how designers could improve the CLI but I don't think the CLI's usability is a problem. People aren't using the CLI and abandoning it like they are with the GUI. If the Bitcoin Core tooling's usability was too complex for developers we wouldn't be seeing the success we are currently seeing Bitcoin have. This is a non-issue and designers should not be focusing their attention on design work for the CLI. Furthermore, tools like this are meant to be taken as just that, a tool, and then features a product requires can be added on the application layer. For example, many wallets use BIPs not directly supported by Core, this is good and how it should be. Bitcoin Core ships a modular toolbox for building bitcoin products and the GUI should be a representation of that toolbox, not some flashy wallet that uses BIP39 seeds / non-hardened derivation etc.

I guess there could be an opportunity to more cleanly present documentation around Core but this is a more 'nice to have' kind of thing not a priority.

6. People largely run nodes for non-tx based reasons: for goodwill and to learn/experiment (and on separate hardware).

This is only true for running core natively. There is a huge amount of utility in applications built on top of Bitcoin Core node products like Umbrel / MyNode (particularly if you want to use the latest lightning tools) beyond just confirming transactions. This distinction was made in the presentation but thought I'd just note it. This wasn't something that was explored in this research though it really should have. It could help answer the question as to why most node runners use Umbrel or MyNode compared to just running core natively - could/should core go down a similar path to these node products?

On the separate hardware point. Buying hardware to run a node is a major barrier to entry in running a node. Forking out $400 to run a node cuts out a lot of people and is really against the ethos of bitcoin. What's the point in keeping blocks small so people can run nodes if it costs this much to set one up? I see a push towards desktop nodes in the future. It is the more democratic path to take compared to things like Umbrel due to lower barriers to entry. We should not kill the GUI for this sole reason as despite its flaws it is the easiest way to run (but not really use) a node.

There is drawbacks in running a desktop node though such as being more malware prone and it won't always be on resulting in having to wait to sync to send/receive transactions (probably not a huge issue if you're using it for savings though and not spending which is probably more what the GUI is tailored for). Things like Utreexo, assumeUTXO will make the always on issue less of a concern and having hardware wallet integration will help against malware - these will come with time.

I'd like to posit that this is a where Bitcoin Core GUI has an opportunity to be focused on being a 'desktop savings (or vault) node' product.

Once we have things like hardware wallet integration / multisig in the GUI focusing on making the node component of the GUI more feature rich would be great.

7. Open source products elevate trust, and can exasperate the fear of experiencing technical challenges with no support system.

Totally! Maybe we could start an 'unofficial' telegram chat for users of the GUI to help guide new users. Would be happy to be one of the main admins. As well, we could write guides on using the GUI to help hold people's hands who may be intimidated by how the GUI looks.

8. Lack of standards infrastructure may be holding back developers and great UX.

I don't think this is the case at all. The GUI is usually the first to adopt many great UX standards (PSBTs, Bech32 default, descriptors etc.). The biggest barrier holding back better UI/UX is Qt Widgets and the tools for saving (HWW/multisig) not being there.

Summary

Overall I think the GUI should be designed for users who prioritize security over usability and focus on being a cold storage node type product. It is already kind of there, it just needs to catch up with standards common in the industry such as multisig / hardware wallets / database encryption. Once these features are present I imagine a big uptick in people using the GUI as their primary wallet. In saying that though there is room for usability improvements and maybe one day we can re-vamp the whole UI if we switch from Qt Widgets to Qt QML.

I think the major reason people don't use the GUI are technical, not design. Plenty of work in progress in overcoming these issues though!

[gwillen]

As another Bitcoin Core GUI user (and contributor), I would definitely panic at the idea of losing the Core wallet GUI. I honestly don't know what I would replace it with. Writing transactions by hand in the CLI is extremely fraught, but there's no other wallet software I really trust to the same extent.

Of course it's very hard to sample Core users, since Bitcoiners are a privacy-oriented bunch. One question in my mind is, what are the very largest transactions made with? For low-value transactions you can use whatever wallet you want... but what about this transaction, which spent an output worth about 8.5 million dollars? https://blockstream.info/tx/7f7dd826bc22c0f54638ee95755fc4641029fdd57dd07ae5150ee041fdb96cbf

If that transaction was made by an automated system (e.g. an exchange backend), I expect there's a good chance it used the Core CLI/RPC wallet, but if it was made by a human being from a local wallet, I think there's at least a decent chance it was made with the Core GUI. (And even in the case where the transaction was signed using RPC, it could very well have been monitored by a human using the GUI with a watch-only wallet.)

When asking why we need a Core GUI, I think a few transactions like that are more important to consider than any number of coffee-sized ones, which could really use any wallet. If people can't easily use Core to transact on behalf of their exchange / hedge fund / OTC desk, that could get serious for Bitcoin pretty fast, I think.

Of course, this all assumes that at least some such applications do use the Core GUI, versus e.g. in-house tooling designed around Core RPC. I don't have any particular evidence I can present for that. But it's going to be hard to check; most people making single transactions for $8M USD are probably not going around talking about the details, if only for security reasons.

In sum, although there may seem to be few Core GUI users, I think that at least some of those users may well be one or more of:

• pivotal in some way to the ecosystem
• making significantly higher-value transactions than average
• difficult to find for interviews
• hard-pressed to find an alternative that meets their needs.

[Rspigler]

I would be curious to hear if the Core GUI is the primary place that your store your coins, and if not is it a place where you are conducting the majority of your transactions?

I use Bitcoin Core's GUI exclusively for my hot wallet. For my cold storage, I build an HD multisignature wallet using offline Core installations as signers, with one online as the broadcaster/coordinator. This currently isn't possible through the GUI, but is being worked on.

it’s unlikely the resources will be put into it and forking it and starting from scratch would probably be more fruitful

This is a misunderstanding of the current situation - so many resources currently are being put into it; financial and technical. There is no reason to fork and start from scratch.

there are sufficient non custodial trustworthy and high quality wallets outside of core wallet.

IMO, this is debatable. The reason why other wallets have an easier/faster time implementing features is because they have a centralized development team of 1-5 people, or because they lack the standards process of Core (look into the ypub/zpub vs descriptor wallets). The decentralized development process, along with gitian builds (now being upgraded to reproducible and bootstrappable builds) is something no other wallet has.

the most intense and fervent users of Core wallet are developers, who could be served better with a suite of product features and tools.

I don't believe this is true, but if it is, it shouldn't be. And I don't think I'm the only person who believes this, as we have had tremendous improvement in the GUI over the last year re: offline signing and multisig, along with other various improvements, and have much in the future planned.

Anyway, we don't have to agree. You can always build/download Bitcoin Core without the GUI, and if the current developers need any more help financially for their time, I'd be happy to contribute.

@Bosch-0 is correct when he says that Bitcoin Core is the most audited and secure. In terms of being a wallet for cold storage, all the work being done on HWI, offline signing, multisignature, descriptor wallets, PSBTs, miniscript, etc will enable it to be one. And without the Core devs, these standards/technologies wouldn't exist.

[Bosch-0]

A) it’s unlikely the resources will be put into it and forking it and starting from scratch would probably be more fruitful

This kind of already exists in the form of Umbrel / MyNode etc. If it was forked and developed by a different team it would lose that one thing that makes it valuable - security / auditability.

CLI clearly is not being abandoned, nor is usability an issue. The question is prioritization. Where does the community want to commit resources? Developers are possibly the most active users of BTC Core Wallet via the CLI, and building products on it like myNode or other node products/tools.

Considerable resources are already being committed to the GUI as @Rspigler mentioned. Yeah they are and that's bitcoin/bitcoin improves upon. Every Bitcoin product essentially uses core wallet in some way. There is a lot of constraints with Qt Widgets the framework that the GUI uses holding it back from being more user friendly.

I don't believe this is true. The hardware nodes that were being used were largely for non-transactive purposes. Additionally many who claimed to care about privacy had never done anything to do with privacy on a node, but had it for when they needed it eventually. In the meantime, it was a tool for Most people who are running nodes in general (from the data we collected) are not running core natively. Developers who may have an extra computer or need it set up may have it running natively, but often in addition to several hardware nodes. Non-developers-- no one running core on their computers.

I use my MyNode almost weekly for making transactions on lightning - many, many others also do. I'd argue these hardware products are mostly used for transactions (on LN anyways).

I disagree here too. This is absolutely the case for people building on BTC Core. We spoke with devs working on BTC Pay, a widely used node implementation and a multi-sig wallet developer. The insight isn't about standards in the GUI. This project is about Core Wallet, not just the GUI.

These projects wouldn't exist without Bitcoin Core, it's the foundation of that and pretty much every Bitcoin project in the space. Like I said earlier, Bitcoin Core is a toolbox that doesn't have everything (but has the most vital components) that these projects like BTCPay configure to suit their needs. Yes they may not use it as is but that's not how it was intended to be used - that goes for pretty much any open source project really.

[Rspigler]

@Bosch-0 Can you link me to the discussions previously had on QML? Maybe that should be revisited

[Bosch-0]

@Bosch-0 Can you link me to the discussions previously had on QML? Maybe that should be revisited

https://github.com/bitcoin/bitcoin/pull/16883

[jonatack]

Interesting comment from Pieter Wuille on IRC yesterday that I liked:

"hardware wallets" is a terrible name. They're not wallets, they are signing devices. Ideally the choice of hardware wallet or not, and how, is orthogonal to the choice of what wallet to use.

I agree with @gwillen. I use the CLI for day to day and small things as I prefer the command line over GUI interfaces, but it's less safe to use the CLI than the GUI for larger transactions. I have no intention to trust third-party software for larger amounts that I haven't personally been reviewing.

The main issues for me with the GUI are:

• the locking/freezing issues
• improved integration with hardware signers
• security and privacy (not GUI-specific)

And on the UI side:

• the lack of easy dark mode
• the horizontal stripes in the UI that my eyes have difficulty with
• the unpolished, non-clean, clunky Microsoft-Windows-y UX that is difficult to change due to the open source process making it hard to get past bikeshedding, and maybe also due to devs preferring it stay more in "developer language", clunky icons and arrows, etc.
• lack of UI configurability for different users' needs (beginner, expert, accessibility, maybe documentation)

I've found the review bikeshedding to be a far greater hurdle to cleaning up the UI than the fact that it uses Qt (I'm no Qt dev but it works for me so far) but maybe people are thinking about trying to make it look super fancy in a way that is better baked in with other frameworks (and I know nothing about QML so feel free to ignore this sentence) whereas I'd just like clean and minimal with maximum configurability for users from beginners to experts. Maybe it's just the nature of design/UI/UX being hard to do in open source, I don't know.

I certainly disagree with any suggestion to kill off the "core wallet" or the GUI. And in software, the "great rewrite" is also usually a terrible idea (or a "false good one"). Maybe what was meant is that there is a desire to separate the GUI project from the main repo (and that has been done and also an additional maintainer was named) to help it nurture and grow its own developer and designer/UI/UX ecosystem.

[Rspigler]

What are some security and privacy issues in the GUI that are not present in the CLI?

edit: noticed the edit

[Rspigler]

As shared in the presentation via 3 stories, 3 of the devs we spoke to had challenges with standards for xpubs psbts, etc

The Core dev team creates standards that solves longstanding interoperability issues, for example the descriptor language and PSBTs. These have been implemented in the GUI.

[jonatack]

wallet is stagnant

I've chatted about this on-and-off with various core dev colleagues and maintainers the past year or so. Apparently that has usually-to-always been more-or-less the case since the beginning. The wallet-focused devs have often not been working full-time on it, as they are mostly employed by exchanges or private industry. Perhaps the recent expansion of grants will change that (I thought it would have changed things more by now).

[Bosch-0]

"hardware wallets" is a terrible name. They're not wallets, they are signing devices. Ideally the choice of hardware wallet or not, and how, is orthogonal to the choice of what wallet to use.

Completely agree, I used hardware wallet above but this is a my preferred terminology also.

but it's less safe to use the CLI than the GUI for larger transactions.

Very interesting point, something I didn't think about much as I rarely use the CLI.

the unpolished, non-clean, clunky Microsoft-Windows-y UX that is difficult to change (I've tried) not due to Qt but to the open source process making it hard to get past bikeshedding, and maybe also due to devs preferring it stay more in "developer language", clunky icons and arrows, etc.

The big issue with Qt Widgets is it inherits styles from the host OS. This makes it almost impossible as a designer to do mockups as yes it may look good in your Linux styled mockup but when applied it looks bad on macOS/Windows resulting in a lot of accumulated design debt / focus on minor changes that take up a lot of valuable time. Having standardized design systems (which is impossible with widgets) makes the design process much more fluid.

standards for xpubs, psbts.

There is certain 'standards' that the Bitcoin Core wallet has not adopted for security reasons (applies to CLI and GUI). Lack of BIP39 adoption / xpubs is one of them. It's not a fault of Bitcoin Core it's actually one of its strengths.

psbts is used in core wallet the same as it is in practically every multisig coordinator. It was created by core.

Surveys of 400 people on my project and survey of 1000+ people on andrew chows survey project clearly showed what ppl are using nodes for.

It hints towards that but it isn't that clear. There is video tutorials on YouTube for setting up nodes with 100k+ views. Everyone who runs a LN node also runs a bitcoin node. There is thousands of LN nodes with capacities (meaning they are using it for transactions) you can see this here - https://terminal.lightning.engineering/#/.

The research shows people don't use Bitcoin Core natively for transactions but I find this hard to believe for nodes in general (of which pretty much are all Bitcoin Core).

[jonatack]

Certainly, wallet dev can go much, much faster in smaller projects with BDFLs or in private initiatives.

[jonatack]

The big issue with Qt Widgets is it inherits styles from the host OS. This makes it almost impossible as a designer to do mockups as yes it may look good in your Linux styled mockup but when applied it looks bad on macOS/Windows resulting in a lot of accumulated design debt / focus on minor changes that take up a lot of valuable time. Having standardized design systems (which is impossible with widgets) makes the design process much more fluid.

Good points, thanks. I'm more focused on the p2p and consensus parts so I'm not very aware on these things.

The research shows people don't use Bitcoin Core natively for transactions

I do use it natively for most transactions, but sure. If we are talking about the masses, indeed, there will need to be a slow convergence over time between increased general awareness and education and improved wallet UI. We'll need to work to close that gap on both fronts.

[gwillen]

I think it would be helpful if core devs who think that the GUI is "stagnant" could come here directly to elaborate on their views -- I would love to hear their further thoughts on what ought to replace it / what direction we should go from here.

One thing I'm not super aware of -- what does the marketplace of "Bitcoin-Core-based wallet GUIs" look like? I.e. GUI Bitcoin wallet apps which implement only the GUI layer, and use Core for the underlying wallet machinery. I see that myNode is a bit like this, but it seems fairly specialized. If I just want to download an Electron-based GUI for the Core wallet, presumably talking to it over RPC, does that exist? If so, how popular is it? And if not, why not, and would it make sense to try to make it easier?

(One obvious answer to "why not" is that Core is pretty heavyweight, and anybody who wants a snappy attractive GUI probably grabs one of the light wallets. I think a lot is already being done to remedy that, e.g. making it easier to start in pruned mode, and then further to things like assumeutxo.)

If I had the option of running a Core-wallet-backed GUI, with the GUI a separate process and a separate dev team, that would seem pretty attractive I think. (Of course, one still has to trust the GUI dev team to a certain degree. But the amount of trust required is much less, I think, versus how much one has to trust the underlying wallet dev team.)

[Rspigler]

@gwillen I believe that would be Spectre, Nunchuk (sort of), and Yeti (note, I work with Yeti). At Yeti, we have the goal that Bitcoin Core will eventually incorporate the features we allow for (GUI offline signing using Bitcoin Core instances), and that Yeti will no longer be needed. I have offered bounties for this, and also worked on BIPs 129, 88, and 87.

[Rspigler]

I would still NACK removing the GUI from Core. Yes, it is less trust than removing the entire wallet, but it is still trust in another dev team that could have consequences on user funds. Of course, users have the right to use another GUI, and this is dependent on the existing devs continuing to code for the GUI (which no one can force obviously).

[jonatack]

What does NACK mean

negative acknowledgement, i.e. disagree with change and/or concept

https://www.freecodecamp.org/news/what-do-cryptic-github-comments-mean-9c1912bcc0a4/

[Bosch-0]

GUI Bitcoin wallet apps which implement only the GUI layer, and use Core for the underlying wallet machinery

No desktop node GUI's exist besides core. Umbrel / MyNode / Raspiblitz which run on dedicated hardware are the closest but they have many application layers built on top.

yes! this is what i had proposed in my project. separating the underlying core wallet machinery and enable people to build on it.

This already exists. The example you used about the BTCPay is just that - they used the core wallet machinery and fine tuned what they wanted to suit their application.

I would still NACK removing the GUI from Core.

Agree, Bitcoin Core GUI has the least barriers to entry for running a node (doesn't require hardware like Umbrel / MyNode). Unless something better and easier to setup exists the GUI is important.

[jonatack]

"real people" ;)

I doubt I'm the only one here with consumer product experience, but I did an MBA at INSEAD followed by worldwide product & marketing management for mass consumer brands for a few years as a change from software, before returning to software.

I don't know if a top-down approach can work well with the more ad hoc bottom-up, scratch-your-own-itch open source process, especially one that places as much importance on decentralization as bitcoin does. Nevertheless am always interested to listen / hear more.

[michaelfolkson]

Which was the purpose of the project.

The purpose of which project? Bitcoin Design or the Bitcoin Core GUI? This issue was set up to focus on the Bitcoin Core GUI. I don't think much of this discussion is relevant to the Core GUI. There is lots of prior discussion on this issue and the previous issue on how a centralized for profit company can focus on product in a targeted way that a decentralized open source project can't. All we can do with the Core GUI is attempt to identify who is using it and improve it without hurting the experience of existing users. That incremental approach wouldn't be acceptable for a company who are seeking to maximize user growth etc.

e.g. https://github.com/bitcoin-core/gui/issues/45#issuecomment-671333460

I don't expect the Bitcoin Core GUI will ever be ditched (there will be always be a use for a solid, reference GUI) but I do expect there to more innovation and more experimentation on GUIs that don't have to go through the Core review process and perhaps aren't quite as focused on security, conservatism and consensus. I suspect the designers that will be attracted to this project will be the ones that want to learn more about Core beyond design and those who want to focus entirely on design with greater autonomy will gravitate towards other projects. (I could be wrong though!)

[michaelfolkson]

Update from my post above, here is a recording of Jaamal going over Project Horizon: https://www.youtube.com/watch?v=oZkBU5H2WjY

This project looks cool but we should try to stay on topic on this issue (some of above discussion is relevant but some of it isn't). While there are users and contributors to the Core GUI it isn't going anywhere and arguably Core is an infrastructure project rather than a product.

Maybe it needs to be clearer. My project isn’t about the GUI. When i’m talking standards, i’m not talking about the GUI.

To the extent that this isn't about the Core GUI this should be discussed elsewhere. There are many standards that already exist and are in the process of being drafted, indeed there is an entire standards track in the BIPs.

[harding]

@jamaalm

We did speak to one core dev that does use the GUI, another two core devs we spoke to do not. In your case, I would be curious to hear if the Core GUI is the primary place that your store your coins, and if not is it a place where you are conducting the majority of your transactions?

Bitcoin Core is the primary place I store my coins (two wallets, one a small-value hot wallet and one a multisig cold wallet). It's the only wallet I use besides a C-Lightning node. For my hot wallet, I send/receive almost all of my transactions through the GUI. For my cold wallet, I'm able to start a transaction through the GUI, but I usually finish up on the CLI because of my need to use HWI. (It's been a few months since I last touched my cold wallet, so I'm behind on some of the recent integration work.)

Not many ppl transacting in BTC use core as their was to transact because it doesn’t meet the needs as a transaction wallet.

That it doesn't meet people's needs surprises me as I find sending and receiving through the GUI to work perfectly fine, and I appreciate the many features Bitcoin Core has that other wallets lack. One of the problems is that most of those features are related to security and privacy, so they aren't visible to users.

Previously I had created a sub-site to Bitcoin.org describing those benefits, but that material was never transfered to BitcoinCore.org when we moved in late 2015 / early 2016. I'll see if I can work on that next week.

The reason I suggest “killing the GUI” is because it is so far off course that: A) it’s unlikely the resources will be put into it and forking it and starting from scratch would probably be more fruitful

Are you aware of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ?

I'd strongly suspect that any attempt to rewrite the GUI from scratch will probably never end with it integrated into Bitcoin Core to the same degree that it currently is.

B) there are sufficient non custodial trustworthy and high quality wallets outside of core wallet.

Very few such wallets integrate directly with a full node for the security and privacy benefits it provides. Even those that do integrate with a full node often don't provide the additional security of highly-reviewed wallet code or the additional privacy of things like -avoidpartialspends.

the most intense and fervent users of Core wallet are developers, who could be served better with a suite of product features and tools.

What is the purpose of keeping [Bitcoin Core GUI] alive?

The security of the Bitcoin system depends on people being able and willing to refuse acceptance of incoming payments that violate the consensus rules they personally think are important. The vast majority of wallets outsource part or all of that rule enforcement to third parties; only wallets based on full nodes perform all of the enforcement themselves.

One reason the most feverent users of Bitcoin Core's wallet are developers is because they understand this principle and so know that using a full-node-backed wallet is important. A consequence of this is that devs have, when necessary, "scratched their own itch" in usual open source fashion and improved the parts of the wallet they personally use.

This may give the impression that the only parts of the wallet that are important are the parts used by devs, but I don't think that's correct. Bitcoin's long-term security needs there to be an easy-to-use way for everyday users to fully verify their own incoming transactions. Currently the best product I know for accomplishing that is Bitcoin Core GUI, and for as long as that remains the case, I think it's essential we continue to devote resources towards maintaining and improving it.

[jonatack]

Thanks @harding, when I wrote this above in https://github.com/bitcoin-core/gui/issues/45#issuecomment-844726829

I certainly disagree with any suggestion to kill off the "core wallet" or the GUI. And in software, the "great rewrite" is also usually a terrible idea (or a "false good one").

I was alluding precisely to this

Are you aware of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ?

[harding]

@jamaalm

My project was about the product — Core Wallet. Right now that product isn’t great.

The great thing about Bitcoin Core's wallet is that it provides features that no almost other wallet provides by default. The usage of those features is essential to the security of the network. This was the main point I tried to make in my earlier message to you and I'm disappointed that I don't really see it addressed in your response.

I get the impression that you're looking at this as a typical market-fit analysis: we have a market (Bitcoin users), so how do we design our products (Bitcoin Core Wallet CLI/API & Bitcoin Core Wallet GUI) so that they become widely adopted by the market?

As I understand it, your conclusions are (roughly) that Bitcoin Core Wallet GUI is so underused, and far behind its competitors, that it's better to abandon it so that we can invest contributors' limited resources into improving Bitcoin Core Wallet CLI/API for a niche segment of the market (i.e., devs and power users that either need the advanced features available through RPC or need a programmable API).

That's a perfectly reasonable conclusion coming from those inputs. But I see things a bit differently. I think what users want more than any particular wallet feature is for Bitcoin to continue to exist as a decentralized system that resists censorship and coercion. That property requires a sufficient percentage of users to use full nodes to verify their own personal incoming transactions.

Bitcoin Core Wallet CLI/API and Bitcoin Core Wallet GUI are two of the only products that perform that verification by default. If large numbers of people aren't using them, and if they aren't using non-default alternatives, then it's essential to the long-term health of the system that we find a way to get people back to fully verifying their own received transactions. The easiest ways to do (that I know of) are:

1. To improve Bitcoin Core Wallet CLI/API and Bitcoin Core Wallet GUI until people are willing to use them again.

2. Education---explaining to users the non-obvious security and privacy benefits of using a personal full node.

The alternatives (like rewriting the GUI from scratch; or simply killing the GUI and hoping things just work out) sound like they would, at best, take a lot more work to achieve the same goal of keeping the network decentralized.

In short, I'm asking you to look at this not as a problem of designing software for the short-term things users say they want but of getting users to use software that does what they need in the long term. It's a much more challenging problem, akin to getting people not to eat junk food in the short term but instead make long-term healthy choices about food and exercise.

[harding]

@jamaalm since I started writing a reply to you (during which I went to lunch), you've edited your post 23 times (many of them adding or removing whole paragraphs). Could you let me know when you're done so my reply can address all of your points?

[harding]

@jamaalm

Can you please point me to the place where I said I'd like Bitcoin to not exist as a decentralized system? Again, I'm not sure if this is intentionally a straw-man or your premise is completely off on what my intentions are, my project and who I am.

I'm sorry, I didn't mean to imply that you were anti-decentralization. My concern is that we might end up in a case where Bitcoin's decentralization is lost because everyone assumed someone else was guarding that decentralization.

Improving the GUI will not magically solve that.

I don't think anyone is expecting magic; I do think some of us believe incremental improvements to the GUI can make running a node-backed wallet more desirable, thus attracting people who want to support decentralization but who currently need (or really want) a particular feature.

What is going to materially change the amount of usage based on a change in the GUI (without changing the product)?

One small change with significant impact we had a few years ago (which has been improved since) was exposing the pruning options in the GUI. This made it much easier for a number of users on laptops and other devices that are often disk constrained to run nodes (accessing the option previously required editing the configuration file).

Future options might be integration into the GUI of support for assumeutxo sets, allowing the GUI wallet to be usable within minutes instead of hours or days. Or we might make cold wallet and multisig wallet support easier through the ongoing descriptor wallet support. Or something like the HWI GUI bridge might also be adapted to provide LN support through the GUI.

It seems to me that there's lots of things that could be done in the GUI that would make it more attractive to users.

The "education" excuse in consumer products is 99% of the time just a bad product.

Bitcoin Core isn't a typical consumer product. Typical consumer products are regulated by law so consumers who are ignorant of how the product works don't get excessively harmed. Full nodes and self custodial wallets exist outside of that safety net. To a certain degree, we experts can design Bitcoin Core's various UIs (both CLI, API, and GUI) to avoid footguns, but we can't stop developers of other wallets from offering those footguns to users as if they were fancy features. In that case, there's nothing we can do but tell users about the risks (and benefits) and hope they make the most appropriate decision for their situation.

Using lightweight wallets is one of those footguns. If a small percentage of people use lightweight wallets, that has no significant effet on the security of Bitcoin, but if everyone uses lightweight wallets, then miners and service providers can change the rules of Bitcoin at will.

The demographic I referenced in the last post I made - they largely run nodes (none using Core, natively)

Are you saying you interviewed a bunch of people who run non-Bitcoin-Core nodes? That seems like an odd crowd.

The GUI isn't keeping Bitcoin decentralized, nodes are.

People who receive payments in Bitcoin Core GUI are making a meaningful contribution to Bitcoin's decentralization. People who run nodes without using them to verify their received transactions are not meaningfully contributing to Bitcoin's decentralization.

What is it that you're calling junk food in your analogy with the specific demographic I already pointed out? Specter? Cold Card? Casa? Trezor? Electrum? myNode? That's junk food to you? Ok then.

I believe Specter desktop connects to a full node by default, so that's good. I don't know much about Specter hardware wallet, but I'd guess it often gets used with Specter Desktop, so that's also good. AFAIK, ColdCard doesn't have a "default" wallet it works with, so the people using it with Bitcoin Core through HWI are also in a good place.

Specter hardware wallet and ColdCard when used with most other software, Casa, Trezor, and Electrum by default don't contribute to Bitcoin's decentralization, so if everyone used them with the default settings, Bitcoin would fail. This is similar to how, if all someone ate was junk food, they'd probably be dead within a few years.

(I'm not familiar with myNode; I can look into that if it's important to you.)

Let me turn it to you. Do you up think people that are running a node, but not natively using Core Wallet are uneducated?

Some of them certainly are; perhaps most of them.

Do you genuinely think "educating them" is the right problem to solve?

The problem to solve is to get people to verify their received transactions with their own node. Education is one way to help address that deficiency.

(You ask these same two questions in several different ways in succeeding paragraphs; my answer is the same to each.)

Have you thought that maybe understanding the needs of a very particular, bought-in, bitcoin-believing, self-custody, node-running, technically-competent demographic could be useful

I'd love to understand the full extent of their needs better, but I already know this: if they want to ensure Bitcoin's consensus rules aren't changed in ways they don't want, a sufficient number of people need to use their own full nodes to verify their own received transactions.

Maybe you should articulate exactly what the archetypical person that needs education is?

I remember when I wrote https://bitcoin.org/en/full-node in January 2015, I didn't understand why a full node was important. I thought simply runnig a node and sharing data was sufficient to help protect Bitcoin's decentralization, but that's wrong: what we need is economic enforcement of Bitcoin's consensus rules. You can see Chris Belcher's explanation of why that's the case here: https://en.bitcoin.it/wiki/Full_node#Economic_strength (I mention my own explanation in the next section).

What are you educating them on? [...] Please be very specific about what they need education on

I think this content written by me in 2015 is sufficiently detailed: https://web.archive.org/web/20150929204455if_/https://bitcoin.org/en/bitcoin-core/features/validation#help-protect-decentralization

Here's the PR where it was added with statements of support from Wladimir van der Laan, Theymos, and others: https://github.com/bitcoin-dot-org/Bitcoin.org/pull/1044 (there was more support on IRC, but I'm too lazy to dig up the logs).

Additionally, maybe be specific about the GUI tweak you think would unlock said archetype to now use Core wallet?

Options for assumeutxo (when available), cold wallets, multisig wallets, external signer support, and LN support, plus better backups.

[Rspigler]

@jamaalm We are going in circles and it doesn't seem like you are really reading any of the responses.

Bitcoin Core is the primary place I store my coins (two wallets, one a small-value hot wallet and one a multisig cold wallet)

This is rare. We met one person that also had a similar practice to you.

As mentioned previously, I do the exact same thing.

The only reason the one core dev was using Core wallet is it's primary and arguably ONLY feature that it has better than any other wallet (if we're excluding the other features accessible outside the GUI): it is the most trusted wallet

In Bitcoin, where security means everything, this is no small matter...

people that value: extraordinary high assurances (based on trust in the codebase bc it’s open source, or it’s origin, or those that work on it), self-custody, open source

If people value these things, they should use Bitcoin Core

WHY aren't people largely running/using Core natively for a wallet and/or node? Improving the GUI will not magically solve that.

Improving the GUI will help, along with other improvements being made (improvements are always being made). Performance improvements, security improvements, multisig, offline signing, HWW support, assumeutxo, process separation, miniscript, hybrid SPV mode, etc. If you want something that isn't here, people usually offer bounties rather than complaining (that's something I've done in the past). But I've discussed all these things being worked on in previous posts. Core might take longer to do things, but we do them right (descriptor wallets vs the ypub/zpub mess; BIP 87/129 vs the mess of derivations and vulnerabilities in existing multisig wallets).

What is it that you're calling junk food in your analogy with the specific demographic I already pointed out? Specter? Cold Card? Casa? Trezor? Electrum? myNode? That's junk food to you? Ok then.

Using HWWs without a full node is incredibly stupid

Do you think their choice to use other self-custody tools is somehow because they're uneducated or sending coins takes one too many clicks in the Core Wallet GUI?

I'm not aware of any true self custody that doesn't use a Bitcoin Core full node, and I'd argue even further that for any secure setup, the wallet and even possibly GUI should be Core's as well.

Have you thought that maybe understanding the needs of a very particular, bought-in, bitcoin-believing, self-custody, node-running, technically-competent demographic could be useful

I would love to meet one person in such a group who doesn't run Bitcoin Core :laughing:

[Bosch-0]

This project looks cool but we should try to stay on topic on this issue (some of above discussion is relevant but some of it isn't). While there are users and contributors to the Core GUI it isn't going anywhere and arguably Core is an infrastructure project rather than a product.

Yes it has gotten a bit off topic. I figured Project Horizon would give us some insight around the topic question at hand. However, It's mostly just proved assumptions most of us working on the GUI hold without a lot of actionable insight. Frankly I think it missed a lot of context around Core and the GUI as well as attempted to apply a methodology that doesn't quite fit with how open-source products are developed. Though in saying that I really appreciate the work you have done @jamaalm and I know there is a lot of criticism in the posts above but this is the defensive nature of Core and is one of the reasons it, and thus Bitcoin, is so robust.

Let's get back on track and/or move discussions around Project Horizon elsewhere.

[hebasto]

Let's get back on track and/or move discussions around Project Horizon elsewhere.

Anyway, to make Project Horizon results useful for us, it'd be nice if someone translates its insights into the issues on this (or main) repository that developers could assign themselves to.

[Rspigler]

I believe I've done so here

[hebasto]

So, @jamaalm has deleted all of his comments. Now this discussion looks a bit messy :)

[Bosch-0]

Incredibly unprofessional. Open-source has no place for big egos.

[jarolrod]

please, no attacks on @Bosch-0. He's very much involved with design work on Bitcoin Core.

edit: another deleted comment by @jamaalm

[Rspigler]

@Bosch-0 is a valued member of the Bitcoin Core team.

@jamaalm is a troll