Who is the GUI being designed for? -Continued Discussion- #45
Comments
|
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.
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!) |
|
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. |
|
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:
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:
Thoughts? @gwillen |
|
Ideally, we give users the choice. Important then would be to inform them about the up- and downsides of their choice. privacy / trust
walletHardwarewallet 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. 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.. Creating a wallet should:
Of course its conceptually missing all the cool multisig stuff. |
|
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. |
|
@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. |
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
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.
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. |
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. |
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 |
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:
|
|
Relevant comment to this thread #96 (comment) from @harding
|
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. |
|
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 |
|
Thanks! Will watch and looking forward to the published findings |
|
Update from my post above, here is a recording of Jaamal going over Project Horizon: https://www.youtube.com/watch?v=oZkBU5H2WjY |
|
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:
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.
This is also very shocking and unfortunate, and means we need to do much better on education |
|
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! |
|
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). |
negative acknowledgement, i.e. disagree with change and/or concept https://www.freecodecamp.org/news/what-do-cryptic-github-comments-mean-9c1912bcc0a4/ |
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.
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.
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. |
|
"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. |
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)
|
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.
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. |
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.)
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.
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.
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
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. |
|
Thanks @harding, when I wrote this above in #45 (comment)
I was alluding precisely to this
|
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:
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. |
|
@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? |
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.
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.
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.
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.
Are you saying you interviewed a bunch of people who run non-Bitcoin-Core nodes? That seems like an odd crowd.
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.
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.)
Some of them certainly are; perhaps most of them.
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.)
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.
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).
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: bitcoin-dot-org/Bitcoin.org#1044 (there was more support on IRC, but I'm too lazy to dig up the logs).
Options for assumeutxo (when available), cold wallets, multisig wallets, external signer support, and LN support, plus better backups. |
|
@jamaalm We are going in circles and it doesn't seem like you are really reading any of the responses.
As mentioned previously, I do the exact same thing.
In Bitcoin, where security means everything, this is no small matter...
If people value these things, they should use Bitcoin Core
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).
Using HWWs without a full node is incredibly stupid
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.
I would love to meet one person in such a group who doesn't run Bitcoin Core 😆 |
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. |
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. |
|
I believe I've done so here |
|
So, @jamaalm has deleted all of his comments. Now this discussion looks a bit messy :) |
|
Incredibly unprofessional. Open-source has no place for big egos. |
|
Comments that were deleted by @jamaalm:
|
|
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. ✌️ |
|
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.
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. |
|
I'm grateful for the contributions here from all of you. It's a useful discussion to have. |
|
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. |
|
May I suggest to close this issue in favor of #352? |
|
^ seems like a reasonable step forward |
|
Yes let's move discussions there |
a44caf65fe Merge bitcoin-core/univalue-subtree#28: Import fixes for sanitizer reported issues 135254331e Import fixes for sanitizer reported issues d5fb86940e refactor: use c++11 range based for loop in checkObject ff9c379304 refactor: Use nullptr (c++11) instead of NULL 08a99754d5 build: use ax_cxx_compile_stdcxx.m4 to check for C++11 support 66d3713ce7 Merge bitcoin-core/univalue-subtree#29: ci: travis -> cirrus 808d487292 ci: travis -> cirrus c390ac375f Merge bitcoin-core/univalue-subtree#19: Split sources for easier buildsystem integration 4a5b0a1c65 build: Move source entries out to sources.mk 6c7d94b33c build: cleanup wonky gen usage a222637c6d Merge #23: Merge changes from jgarzik/univalue@1ae6a23 f77d0f718d Merge commit '1ae6a231a0169938eb3972c1d48dd17cba5947e1' into HEAD 1ae6a231a0 Merge pull request #57 from MarcoFalke/test_fix 92bdd11f0b univalue_write: remove unneeded sstream.h include ffb621c130 Merge pull request #56 from drodil/remove_sstream_header f33acf9fe8 Merge commit '7890db9~' into HEAD 66e0adec4d Remove unnecessary sstream header from univalue.h 88967f6586 Version 1.0.4 1dc113dbef Merge pull request #50 from luke-jr/pushKV_bool 72392fb227 [tests] test pushKV for boolean values c23132bcf4 Pushing boolean value to univalue correctly 81faab26a1 Merge pull request #48 from fwolfst/47-UPDATE_MIT_LINK_TO_HTTPS b17634ef24 Update URLs to MIT license. 88ab64f6b5 Merge pull request #46 from jasonbcox/master 35ed96da31 Merge pull request #44 from MarcoFalke/Mf1709-univalue-cherrypick-explicit 420c226290 Merge pull request #45 from MarcoFalke/Mf1710-univalue-revert-test git-subtree-dir: src/univalue git-subtree-split: a44caf65fe55b9dd8ddb08f04c0f70409efd53b3
and others
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.
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).
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.
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
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
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.
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?
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.
The text was updated successfully, but these errors were encountered: