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

Bosch-0 commented at 11:19 am on August 5, 2020: none

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.

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.

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.

bitcoin-core deleted a comment on Aug 10, 2020

michaelfolkson commented at 12:48 pm on August 10, 2020: member

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 commented at 4:38 am on August 26, 2020: contributor

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 commented at 2:11 am on August 28, 2020: contributor

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:

Support in the GUI for popular hardware wallets such as Trezor, Ledger, and Coldcard
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 commented at 7:31 am on August 28, 2020: contributor

@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 commented at 8:15 am on August 28, 2020: none

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 commented at 6:51 pm on August 28, 2020: contributor

@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 commented at 6:27 am on August 29, 2020: none

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 #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 commented at 8:23 am on September 9, 2020: none

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 commented at 8:36 am on September 9, 2020: contributor

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 commented at 7:07 am on September 15, 2020: none

@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 commented at 4:23 am on October 8, 2020: none

Relevant comment to this thread #96 (comment) 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 commented at 12:01 pm on October 8, 2020: contributor

@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.

hebasto added the label Brainstorming on Mar 5, 2021

Bosch-0 commented at 1:01 am on April 29, 2021: none

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 commented at 3:17 pm on April 29, 2021: contributor

Thanks! Will watch and looking forward to the published findings

Bosch-0 commented at 2:36 am on May 20, 2021: none

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

Rspigler commented at 4:21 am on May 20, 2021: contributor

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:

update flashiness
Info on what a node is, syncing, etc. Basically - guideance for noobs.
SPV (https://github.com/bitcoin/bitcoin/pull/9483)
Non-digital backups
Multi-sig Coordinator (https://github.com/bitcoin/bitcoin/issues/21278) (https://github.com/bitcoin/bitcoin/issues/21071)
Repeat seed tests/reminders (https://github.com/bitcoin-core/gui/issues/185)
Better privacy (https://github.com/bitcoin/bitcoin/issues/19148) (https://github.com/bitcoin/bitcoin/issues/19035)
Allow for recording fiat amounts
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 commented at 5:07 am on May 20, 2021: none

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 commented at 5:24 am on May 20, 2021: contributor

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 commented at 5:29 am on May 20, 2021: contributor

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 commented at 5:53 am on May 20, 2021: none

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 commented at 5:57 am on May 20, 2021: contributor

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

Bosch-0 commented at 5:59 am on May 20, 2021: none

@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 commented at 6:02 am on May 20, 2021: contributor

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 commented at 6:08 am on May 20, 2021: contributor

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

edit: noticed the edit

Rspigler commented at 6:16 am on May 20, 2021: contributor

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 commented at 6:28 am on May 20, 2021: contributor

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 commented at 6:29 am on May 20, 2021: none

“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 commented at 6:29 am on May 20, 2021: contributor

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

jonatack commented at 6:42 am on May 20, 2021: contributor

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 commented at 6:48 am on May 20, 2021: contributor

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 commented at 6:54 am on May 20, 2021: contributor

@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 commented at 6:59 am on May 20, 2021: contributor

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 commented at 7:09 am on May 20, 2021: contributor

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 commented at 7:26 am on May 20, 2021: none

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 commented at 1:14 pm on May 20, 2021: contributor

“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 commented at 1:38 pm on May 20, 2021: member

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. #45 (comment)

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 commented at 2:06 pm on May 20, 2021: member

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 commented at 3:43 pm on May 21, 2021: contributor

@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 commented at 3:58 pm on May 21, 2021: contributor

Thanks @harding, when I wrote this above in #45 (comment)

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 commented at 8:11 pm on May 27, 2021: contributor

@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:

To improve Bitcoin Core Wallet CLI/API and Bitcoin Core Wallet GUI until people are willing to use them again.
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 commented at 0:08 am on May 28, 2021: contributor

@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 commented at 1:36 am on May 28, 2021: contributor

@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 commented at 2:44 am on May 28, 2021: contributor

@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 commented at 4:34 am on May 28, 2021: none

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 commented at 4:50 am on May 28, 2021: member

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 commented at 5:20 am on May 28, 2021: contributor

I believe I’ve done so here

hebasto commented at 8:50 pm on May 29, 2021: member

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

Bosch-0 commented at 1:58 am on May 30, 2021: none

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

jarolrod commented at 4:01 am on May 30, 2021: member

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

edit: another deleted comment by @jamaalm

Rspigler commented at 5:45 am on May 30, 2021: contributor

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

michaelfolkson commented at 2:53 pm on May 31, 2021: member

Comments that were deleted by @jamaalm:

Hey Robert, thanks for the note.

You’re pointing to one of the limitations of the research — we couldn’t find a meaningful number of GUI users with our participant search. 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?

Overall most people we spoke to were people who at one point tried to GUI and abandoned it because the product itself (superset of the GUI) did not meet their underlying needs.

Secondarily, it’s not really possible to define a most requested feature set from this project. Rather, the biggest opportunity space is to build intuitive, high assurance ways to hodl. Almost all the people that we interviewed (and almost anyone in the universe of most likely to use or a current hardcore user of the Core wallet) view Bitcoin as something to save, something to hodl. That is the primary focus on what people are doing with their coins, using Casa, Specter, hardware wallets, multi-sig etc.

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

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

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

C) 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 hear you on the worry of the GUI becoming a dev only tool, and it may be better that it continues to live on, despite it falling further and further from being up-to-date or relevant.

My question then is — why? What is the purpose of keeping it alive? The answer may be as simple as the people that currently use it (as tiny as that number is). Or maybe it’s a fail-safe to ensure we have a trustworthy GUI wallet always available to anyone. Curious to hear your thoughts. Also who do you think the person we’d be designing for should be?

Thanks

Glad to see some discussion here. Some comments in response, bosch:

*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.

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.

*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 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.

*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.

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.

Really thankful for all of your comments and thoughtful discussion. My project is just food for thought. And my opinion about what to do with the GUI is simply my *opinion. *That part is not part of the project deliverable, if you watched my presentation - it’s again just my opinion.

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.

I think my statement is more about my personal perception of progress on making a great wallet product + GUI. But also one fo the core devs we spoke to also said the same thing - wallet is stagnant. He also suggested the GUI get killed or forked because it’s not great.

@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.

No disagreement here.

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. I don’t recall anyone stating they run a node for LN, but i’d have to review the write in answers. My assumption is that is a tiny fraction of the universe of ppl running nodes. Not a single person in our interviews running a hardware node was doing it for lightning.

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

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.

My opinion that i shared was maybe the GUI could be killed.

some of the core devs i spoke with had the same opinion. stagnant – and one of them went so far as to say the GUI should be killed.

One of my hunches is that many people running a lightning node are doing it to learn, to support the network or for fun (the reason i had previously done it). i suppose it’s transaction based but maybe people categorized it as learning or something else in the survey? i personally don’t know anyone myself who is using lightning for anything besides experiments tbh. but my network of people using lightning is tiny.

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

i’m personally in favor and excited by that.

What does NACK mean

I would recommend having a product manager or product designer (emphasis on PRODUCT) join discussions or decisions.

Because something exists to some degree doesn’t mean there’s a lot of product opportunities or design space. I see a lot of general statements that clearly downplay the amount of product design space in an idea. This matters a lot in making a great product.

Designing something that would enable and encourage GUI creators to build on the code base could have many many product implications. The question I’d pose is why aren’t there other GUI wallet implementations built on Core then? Beyond introducing new functionality that’s clearly missing in the wallet how could we make it easier and safer to develop GUIs? How do we elevate the end users trust if the GUIs aren’t part of the reference score wallet?

Another example, downplaying standards and their implications because again “they already exists”. Ok - try using core wallet to store your coins and then try to change to an entirely different wallets. Not that i’m suggesting this - but is there a standard wallet.dat file? Is there a standard way to take my meta-data with me that i’d generated about my UTXO’s. Even trying to switch non core wallets can have its standards related challenges, which can relate to core. For example how does one transmit a PSBT? The air gated community has been working on an animated QR code. Or xpubs - there’s some differing standards there too. A question we could also ponder is what role does Core play in being a standard setter or convening the community around standards? Can core play a part in helping us settle on standards faster or being a reference implementation of them?

Another example - I talked about UTXO management in my presentation and specifically why there’s a lot of room for improvement based on how people are behaving. Another response to that in this thread is that core wallet already does that rn or it’s good enough . The labels as they stand are are a poor solution for all the ways I saw people doing UTXO management. That is product thinking - why is the current implementation not solving the problem people face at all or doing it in a less ideal way?

Product thinking doesn’t treat all solutions the same. Details matter a lot.

This project was centered around PRODUCT, not GUI. A great “GUI” doesn’t create a great product. In face it’s impossible to have a great GUI if your underlying product isn’t good.

Implementation matters, and I suggest getting someone with deep consumer product experience in these discussions because details matter a lot and a good product is an extreme super-set of a GUI.

Who is the thing for? What does a thing do? How does it do that thing? And why? — these are some of the underlying questions that MUST be answered to make an excellent product. Without this it’s just a group of disparate functions in a wrapper that may function for technical users or just be good enough, but may not solve the problems real people face.

LOL - yes, it’s short hand for looking outside of this narrow community of people that would be on this GitHub. Which was the purpose of the project.

“The project” Is my project that @Bosch-0 posted.

See updated comment above.

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.

I believe specifically having someone with deep a consumer digital product management or consumer digital product design experience would be helpful. Someone who has built on worked on these at scale would be helpful, rather than generalized consumer experience (not saying that’s what you have).

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.

I am responding to comments specifically about my work here – apologize if this discussion shouldn’t be happening here. I am simply responding to things that were posted here.

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.

It’s not possible to separate the GUI design from product design. But I hear you, and I’ll stop posting here.

This is such a helpful response, and I will respond next week. Thank you for writing this.

Thanks again for the reply, @harding. First I want to emphasize a couple things –

The purpose of my project was to explore the following questions:

What kinds of people are currently using the Bitcoin Core wallet and why? What are key elements in the official Bitcoin core wallet that would bring the most value? What information would users need to navigate downloading and using a wallet or bitcoin node(consensus/validation)? Why do people run nodes and what are their profiles? 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.)

This is rare. We met one person that also had a similar practice to you. They were a core dev (we met with 3 core devs). As stated in the research, developers are the primary, if not the only, active users of the Core Wallet. This aligns with what our research showed. What I think is even more rare than developers using Core wallet, is developers actively using the GUI as a primary means to transact or store coins. Most developers that are using Core wallet at are choosing other products for storing coins and transacting. The only reason the 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 based on it’s history, being open-source and those that have access to modifying the code.

On the flip side, one of the core devs we met with even stated that it may be best to kill the GUI altogether because it’s just so bad.

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.

The purpose of my project was to look beyond the narrow community of people who are on this GitHub. That is often the purpose of design research (not UX research). Sure, any wallet can “send and receive” but that doesn’t make it a great product or a good UX. And it may function for you, but you may be, again, the tiny tiny group of current users that are extremely technical and do not have the same needs as other probable users of the Core Wallet. With all that said, I understand Core wallet is an open source tool and developers work on it voluntarily on what they want, which is often what will serve them personally – and that’s fine. That purpose of my project was to attempt to answer the questions above -that’s it.

Who are other probable users of the core wallet?

My project was to look beyond the small, small number of people using the GUI as it stands and think about who else could be using it based on what it offers, people that value: extraordinary high assurances (based on trust in the codebase), self-custody, open source, are somewhat OK navigating technical set-ups, without being a developer.

Those types of people aren’t using the Core Wallet because “sending and receiving” do not solve the problems they’re experiencing. Those are functions.

Take for example a BTC Miner in Venezuela that needs to mark down the value of bitcoin when he receives a block reward or when he sends it. For most people transacting in BTC, they need to account for the fiat conversion that the underlying transaction is intended to settle at. There are numerous other real-world problems that can’t be solved with a simple “send and receive” function.

Or take Mark, a family guy, that’s storing coins for his mom, but UTXO labels don’t do it for him. Also what happens when he backs up his wallet? Where does the meta-data go?

Or take John, a pretty technical non-dev, that hates that he can only back up the Core wallet with a dat file.

I am NOT saying that Core Wallet needs to adopt these features. My projects intention isn’t to say we need to be all things to ALL people, rather it’s to say WHAT IF? _What if we try to leverage what we have - open source, extremely high assurance product and focus on becoming THE place for people that want to self-custody their coins to do that? _ What would it take?

OR What if we become the GO-TO wallet for developers or focus on building developer tooling since they are the primary user of this product?

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.

That’s fair. The idea of killing the GUI was literally one sentence that I stated as my opinion at the end of the project presentation. Somehow it’s become the thing that people are obsessed with in this thread. It has almost nothing to do with anything in project.

That said, generally the Core Wallet is a pretty terrible product, even for technical people. And no, because it functions for those extremely technical users, that choose to use it because it has extremely high assurances, doesn’t make it a great product. It’s a product that simply does the job for the few that use it, nothing more for them. And again, that may be fine too.

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.

As stated in my project, developers are the core user of the wallet. And the even smaller subset of technical users that use it with real bitcoin are doing so because of its assurances or CLI and extensibility (we had 1 of these people out of 17 interviews, including 3 core devs).

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.

I agree with this, nothing I’ve said contradicts this. People that believe in and act on the above statement are largely NOT using the Core GUI though – they are fulfilling this with other tools.

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.

Yes, agree. That said, there are a lot of non-developer folks who also understand the principle but choose other approaches.

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.

Core Wallet is not easy-to-use way for everyday users. Full-stop. That is what my research showed and is self-evident to nearly all everyday users that are explicitly choosing other tools as their primary holding and transactions wallets, nodes etc.

Why are everyday users not using it? And no, it’s not because “education.” It’s because the product and UX are lacking, far far far lacking for those people. And my definition of everyday users is pretty narrow – those that value open source, understand bitcoin, value self-custody, have the technical (non-developer skills) to navigate all the elements of bitcoin that are needed to self-custody, and maybe multi-sig, today, and may have run or currently run a node. That is a tiny sub-set of everyday users, and the Core Wallet doesn’t meet their needs.

@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.

What features have I proposed by cut, besides possibly the GUI? None. I’m unsure what your underlying assumptions are here.

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?

No, this is not what I’m doing. I’m applying an approach to gathering qualitative and quantitative data to understand why a very particular segment, small and intentional segment of bitcoin users that would very likely be using something like Core wallet, have chosen not to or have churned out from using it. This includes a lot of people that are developers of core and non-core bitcoin software.

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.

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 intentionally a straw-man or your premise is completely off on what my intentions are, my project and who I am.

The assumption that somehow tweaking the Core GUI as it stands will further decentralize bitcoin is dubious as well. That again, is the whole point of my project – WHY aren’t people largely running/using Core natively for a wallet and/or node? Improving the GUI will not magically solve that. Education is also an excuse. What is going to materially change the amount of usage based on a change in the GUI (without changing the product)?

The minute I hear someone say oh “the users need education” it’s a clear indication that there is deep lack of understanding on WHO the user is and what their needs are, and there’s an implied assumption that they’re stupid. The “education” excuse in consumer products is 99% of the time just a bad product.

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:

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

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

Both false, and both will fail. Improving the graphical user interface (GUI) doesn’t fix the underlying product. And education is an excuse for not having a bad product and has an implied assumption that a) you dont know who your making the product for b) you think they’re stupid.

The demographic I referenced in the last post I made - they largely run nodes (none using Core, natively), they all self-custody, they all are very well educated on bitcoin. None of them use core, at all. Or they did and abandoned it – WHY is the question?

Let me as you – why did they abandon Core wallet? Is it because they need you to educate them?

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.

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

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.

I’ll turn this question to you. This is not at all akin to getting people not to eat junk food. In fact, I’ve worked on projects for food companies in that domain – this isn’t remotely like that. That claim is also just such a terrible excuse for a bad product.

Let me turn it to you. Do you up think people that are running a node, but not natively using Core Wallet are uneducated? Do you genuinely think “educating them” is the right problem to solve? 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? Do you think the people that downloaded core wallet and abandoned it for other products are doing it again because they’re uneducated?

For the software devs that use Core as a testing and dev tool who don’t use core natively at all or as a wallet, do you think tweaking the GUI to make it 1 less click to send coins will convert them to a Core wallet user? What do you think they need education on?

😂 go for it. sorry i’ve been writing and editing between meeting today.

@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.

I am reading the responses. You may be failing to appreciate that not everyone is like you and thereby dismissing anything that is contrary to your behaviors and attitudes. We had a participant in the project that does the “exact same thing” too.

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

Again, failing to appreciate that there is many needs that people have. And there is a hierarchy of needs. People can value those things, but choose other tools because something feels too daunting or technical to use and they fear running into technical issues or losing coins based on backup methods.

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).

Those aren’t changes to a GUI. Those are changes to a product. I think there’s a language problem here. In software we never refer to an app or product as the GUI. The GUI is literally just the graphics layer that surfaces the underlying product.

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

This is obnoxious, but go on…

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.

Hardware nodes don’t need the GUI. Using the Core Wallet GUI for a node is a pretty poor experience and unusable for many people.

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 😆

May go back and re-read my posts. My project is about the CORE WALLET. Everyone running a node that I spoke with isn’t doing it through the wallet GUI. They’re typically running it on separate hardware. GUI node is largely unusable for many non-software dev users.

Thanks for the discussion and disagreements. Wish you all the best.

Yes, because I deleted my comments I have a big ego and I’m unprofessional. It’s a stretch.

I don’t at all mind talking about the limitations of my work, but here I have folks talking about my work like I’m trying to mainstream Core Wallet to everyone, or talking to me like I don’t know that the folks running nodes are using Core. You don’t need to talk down to someone because they have a different point of view than you or assume, as another person did, that my intent was to diminish decentralization or something.

I will present my work on my terms, rather than folks taking it second hand and third hand and misinterpreting it.

There are a lot of people LARPing as designers in the bitcoin community, @Bosch-0. Good design is hard and takes a lot of work beyond updating a GUI and I encourage you to look beyond buttons and graphics.

🤣

jamaalm commented at 2:46 am on June 1, 2021: none

I appreciate you putting these back up here, I also have a PDF of the full page before I deleted my comments. Unfortunately you’ve mixed up a lot fo my words with folks like @harding who have a lot of different things to say than I. And he also knows a hell of a lot more than me about Core. I stand by my posts, besides the last one, and have no problem with any them being reposted.

I intentionally chose to delete my posts after having myself and project participants labeled as “incredibly stupid” by @Rspigler and @Bosch-0 holding the flag like that type of harsh labelling is what keeps “bitcoin robust.” Exiting entirely from a hostile environment that isn’t about my work, but rather felt like egos flexing was the best thing to do IMO at the time, so I deleted my posts (sorry, bad call in hindsight!). Labelling people as stupid made it clear that there was no conversation to be had, it simply became about egos flexing. If it wasn’t about ego it’d be about exploring the WHYs behind behavior that contradicts our beliefs. Why are smart people (like some Core devs or devs of other Bitcoin tools/wallets) not using the Core Wallet, or why are others choosing not to run a node with a HWW, despite @Rspigler’s beliefs (which to some degree I may agree with)?

Answering the why behind behavior is the most important element of good product design, even if designing for developers or open-source or infrastructure. Like why do some choose the Core Wallet despite the GUI not being great? The need for extremely high assurances on code quality and trustability may be one plausible answer. The interesting stuff is when the why diverges from assumptions we have. Like why would someone we think that would use the Core Wallet not be using it, despite them having all the education/technical skills, etc. Those contradictions/gaps are what we look for. This could also be applied for current Core Wallet users - where are behaviors diverging from what we assume people would do? (That wasn’t in scope for my project)

I apologize for some of the havoc I caused here. I recognize now that deleting comments rather than simply saying… @Rspigler, that’s a really unproductive and frankly insulting comment to label people not using a node with a HWW as incredibly stupid. There are a lot of incredibly smart people who are doing that, and that is the purpose of design research (or ethnographic research). We try to understand the WHY behind behavior to inspire products or tools or infrastructure that really matter and work for the particular archetypes we’re targeting.

Like many of you, this is essentially volunteer work for me. And similarly I assume, this is passion work for all of us because we love bitcoin and believe it may be extremely important for our future. And I, like you, don’t want to spend my time battling egos over fundamental data and ideas. I apologize for letting it get the better of me.

I also recognize I’m a guest here, this isn’t my space and I don’t operate under the same culture that you all do. But I also am not obligated to be here, and I showed up after someone tagged me in this thread to respond and clarify my work. My intention of being here beyond that clarification was to understand what is being misunderstood/misinterpreted about my work and where I need more detail to make things actionable for design before I release my project work in more detail on the bitcoin design GitHub (the actual content, beyond the video). My work certainly has limitations, and despite it being written off as this process “doesn’t work in open-source” I’d reckon that some sense of human-centered design does matter for open-source, and sure, it may have to be applied in a different way/format but I do believe it matters and can serve the work that you all do. Not that my project is the one to be a most helpful application to serve you. Often gathering stories and data helps incumbent users+builders (people like yourselves) of the product see the water or get inspired on what to build next, even if you’re building for yourself. I’m not an expert, but I think stories of different relevant users can help drive and inspire your work.

I sincerely do appreciate all the work you do and hope that we all can get past this. I am sorry for the part I played in flaring this thread up. ✌️

Rspigler commented at 6:37 pm on June 1, 2021: contributor

Sigh…

Don’t try to turn this on me, and harp on a single quote out of pages of responses I have tried to engage with you in, despite you being very unpleasant.

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

update flashiness
Info on what a node is, syncing, etc. Basically - guideance for noobs.
SPV (bitcoin/bitcoin#9483)
Non-digital backups
Multi-sig Coordinator (bitcoin/bitcoin#21278) (bitcoin/bitcoin#21071)
Repeat seed tests/reminders (#185)
Better privacy (bitcoin/bitcoin#19148) (bitcoin/bitcoin#19035)
Allow for recording fiat amounts
Encrypt meta-data (bitcoin/bitcoin#18085)

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).

I’m actually trying to move this product and conversation forward, while all you can do when faced with criticism is say that your research was product based (ok?…)

Anyway, you can’t use Bitcoin without a full node (without placing trust in miners, or custodial service, etc). This is not a controversial statement. I’m turning this thread off on my notifications.

jonatack commented at 7:11 pm on June 1, 2021: contributor

I’m grateful for the contributions here from all of you. It’s a useful discussion to have.

michaelfolkson commented at 7:20 pm on June 1, 2021: member

Can we stick to discussion on the Bitcoin Core GUI rather than making this personal and emotional please (directed to all participants)? Thanks. Otherwise this issue should be closed.

hebasto commented at 5:14 pm on June 2, 2021: member

May I suggest to close this issue in favor of #352?

jarolrod commented at 6:58 pm on June 2, 2021: member

^ seems like a reasonable step forward

Bosch-0 commented at 1:44 am on June 3, 2021: none

Yes let’s move discussions there

Bosch-0 closed this on Jun 3, 2021

fanquake referenced this in commit 9b49ed656f on Oct 20, 2021

bitcoin-core locked this on Aug 16, 2022

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

privacy / trust

wallet