New multi-wallet management page #1040
Conversation
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Is this a good direction to take things though? The trend is toward unified wallet designs. BDK/LDK support this. Phoenix does it. BTCPay and Bitkey are headed in this direction. I'd like to see a bit more about the user motivation for supporting multiple wallets. |
|
Good question, and I think the page needs to present some good use cases. Just to clarify, the unified design is always about a single on-chain & lightning combo, managed by one person, right? This page is more of a continuation of the other reference designs for the upgradeable and shared wallets, and also the inheritance work Michael is doing.
So I think this has a lot to do with separating funds for different purposes with different ownership and security requirements, which is different than the single-owner unified design (if I understand correctly). You could argue that those should all be split into different applications/services/devices, but I don't think that's very practical. I don't think a Let me know how that sounds. I am also curious to hear more about your concerns about this being a good direction or not. |
I was thinking of a single user, yes. But even with multiple users, the ideal UX is that each user only needs to safeguard and backup one wallet's private keys, not 2. Regarding upgradeable wallets, good point. I agree it is realistic for the next 5-10 years that users will start with wallet X and later progress to Y and Z, and while sometimes they can sweep from X to Y and discard X, sometimes they might just test the waters with Y before fully transferring from X. So that's a realistic use case. Regarding shared wallets, I think we'd need to dive into the details more. If it is a use case of parents + children, then the parent(s) can control the single master private key / wallet, but the children can each have a logical wallet on top of the actual wallet (defined at the application layer). If it is a shared wallet among peers, like partners of a foundation, then I'd think the more likely scenario is multi-sig controlling different spending policies. Is there a use case where different users have different allocations that they can unilaterally spend from the same wallet? I cannot think of one (and if there is one, I'm not sure the benefit of using a shared wallet vs. separate wallets?). |
|
I don't agree that the kind of complex wallet features in the example above are a bad idea or the wrong path and I want to give some examples of how I use multiple wallets. I think we should be normalizing more advanced and complex use cases with high quality design guidance. Being able to load and manage multiple wallets is fundamental to how I use Bitcoin. There's some harm in taking the easy way out here and suggesting each use case and purpose to its own application. I think there is merit in encouraging more well-rounded applications. Any range of complex use cases currently necessitates use of a vast collection of different wallet software. IMO a basic Bitcoin best practice is to have multiple keys exposed to different levels of risk and exposure as is fit for their use case instead of the one key fits all solution. A wallet for my coinjoined coins. A wallet for my lightning coins. A wallet for my casual spending and a wallet with moderate accessibility for emergencies. A watch only wallet for my really cold coins, a wallet for KYC coins and non-KYC coins. Different multisig wallets for coordinating with different parties. Wallets for my business. A wallet for when I travel. Wallets with complex inheritance scripts and spending terms. I want to limit my security and privacy exposures while I act in Bitcoin through these segregations and wallets. The burden of verifying and managing all of those different wallets even with unified interfaces takes significant time and research and energy because those unified interfaces don't support disparate functions just singular use cases. Some of these use cases will be amalgamated to descriptor scripts but with single use case wallets what good are descriptor wallets? These mythical general purpose wallets don't exist. Is that how we see people using Bitcoin in the future? Unified wallets for every use case? I think that makes sense in a world where people have very few use cases each. But is that the world we are moving towards? Design guidance towards a multi-wallet, many-use case future is imo needed. |
|
@MrRGnome How is safeguarding and backing up multiple private keys simpler or more safe for users? Why not move to a world in which a user only has to safeguard and back up one, and all other wallets are built on top of that? Wallets such as LN which require a hot wallet can use hardened child keys from the wallet so if they're compromised there is no threat to cold storage or other wallets. See BIP-85 for more details as well as this https://lightningdevkit.org/key_management/#creating-a-unified-wallet In addition to it being simpler and safer, it is also cheaper, as a user only has to manage 1 UTXO set and suffers less fragmentation. This results in bitcoin being able to scale to more people as well. |
@moneyball It's not simpler, it is safer. For a lightning wallet I think the level of diligence required is relatively lower than diligence a user might take in securing other keys or verifying other wallet software. In wallets will typically hold a relatively small amount and its funds are exposed to online risks. In such a context I'm not sweating over building every bit of software and dependency I use I keep it simple with a setup that favors convenience and accessibility over security. Something where I can access these keys anywhere and the funds in them are at relatively high risk if someone were to look over my shoulder at the wrong time or give me a virus. In contrast for long term inheritance funds I would prefer something locked with a liana wallet-like solution, Geodispersed multisig and multiple spending paths. The keys exist in an air gap and would be created with manually verified and corrected entropy. Accessibility should be extremely low with the capacity to monitor and send to the wallet, where receiving and running backup drills are the primary interaction. Often times a fragmented UTXO set is a valuable thing. It makes maintaining privacy much better than managing different flags and labels or manual coin control of UTXOs. If you want any distinction between KYC coins and not KYC coins, Coinjoin coins and not coinjoin coins, or simply a desire for increased privacy between multiple transaction sets multiple wallets is a great way to do it. By having different keys with different lifetime security exposures and general accessibilities I can measure my risks in both security and privacy terms. The only way I can imagine I don't need at minimum 3 different wallets and key generations and handling procedures for these 3 categories of use cases is if I had some way to apply the maximum level of diligence on one set of secrets while segmenting them as you suggest through hardening and child keys and descriptor wallets with multiple scripts and tight coin control and general purpose design of applications. Which is what I'm proposing is valuable. A multi-wallet, general purpose, multi-use case design direction. |
|
Thanks for the great discussion and stretching this in all directions. With our other reference designs, it was a huge help to define a specific scenario to dig into that all the recommendations and UX can be derived from. I'd like to do the same here. For example, if we think of a married person with one teenage child, we could imagine the following: 1. Personal lightning Key 1 on the device 2. Joint account Key 1 on the device 3. Child account 4. Mid-term savings & emergency budget Key 1 on the device 5. Long-term savings & inheritance 6. Archived wallet Key 1 on the device -- What do you make of this scenario? A good foundation for this page? What would you change? This gets complicated quite quickly. My initial plan was to focus mostly on the UI approach to displaying and switching wallets, and not so much on how keys, backup, etc are handled. More like the upgradeable wallet, that is focused on a specific part of the user experience and does not try to capture a full-blown product from all angles. But the most important things is that we cover this concept really well, so we can adjust the amount of content/pages as needed. I'm sure the balance will become apparent as we continue here. |
|
@MrRGnome I think we might be in complete agreement! I agree with multiple logical wallets be they at the application level or even (child) key-level. But ideally the ecosystem transitions to a BIP-85-like world where these wallets all derive from a single master private key. I also agree that where this might break down is if a user has a need to secure long-term funds ("won't touch these coins for many years") they belong in a cold storage system that isn't frequently accessed/brought online to do LN channel openings/closes/splicing/transfers. |
|
I strongly agree this get's complicated quickly. I'm sorry I am doing nothing but making it more complicated. I also really like the pages available so far. I'm for at minimum including reference to multi wallet designs as the current page does in some form, I use multiple wallets currently. I'd like to stop using so many wallets, but then one wallet needs to do a lot of things or be very generalized. Is the answer an additional page to those listed? Multi-Purpose/Advanced Wallets This page would focus on the specific challenges of creating designs that are intuitive and functional to a general purpose with high accessibility to sophisticated bitcoin functions. It would serve the married couple that is migrating wallets and needs a diverse key import/export feature set. It would serve the curious teenager that wants to play around with making simple bitcoin scripts and learning the mechanics. When the married persons at work she'll delegate financial responsibilities to subordinates and control budgets of departments. Both intermediary and advanced general use cases are served. These wallets may let users choose the number of signers arbitrarily. Possibly the number and terms of spending paths. Encourage designers to think in terms of 'accounts' if not wallets, whatever you want to term an arbitrary segregation of UTXO's by any method. Users create 'account's and apply spending conditions to them to their discretion. These wallets also may focus on supporting the diverse ways a user can handle their private keys for import or export. This makes them excellent support and recovery focused use case tools for when the married couple forgets what wallet software they used or what their derivation path was because they never learned about those things. The other use cases include anything you can use the exposed building blocks of bitcoin to do. An example would be a UI that exposed CLTV and CSV timelocks, as well as different spending paths and arbitrary multisig configurations making all of the above use cases possible in one interface. I think liana wallet is a good example of a UI that attempts something in that ballpark. |
|
No worries, scope is a common discussion we have around the guide all the time. Especially with 50+ pages in the guide, we also have a lot of existing content now that we don't want to duplicate, but complement and reference. If we look at the 6 wallets in my scenario above, we have reference designs for 3 of them and @rabbitholiness is working on one for inheritance. The latter will include the timelocks, spending paths, keys with trusted parties, as you mentioned. I could see the advanced export also fit to allow for many different types of backup based on people's unique inheritance situations. Check out the design review call we had with Liana a few months ago. That leaves the child account (application-layer only) and the archived one (single-sig, mostly covered in the daily spending wallet). I'd prefer not to get within the scope of those other reference designs, but just look at how they can be brought together within an application.
A site like Saving Satoshi or a testnet wallet like Padawan might be better suited for this. Not sure you want kids to mess around with real funds on mainnet.
I'd argue that this would be better served by a separate wallet for businesses. Seems irresponsible to manage company budgets via people's personal wallets (just like companies don't like people using work laptops for personal stuff).
Check out the manual backup page, we have something in there about offering print templates that include all this info, so users don't just scribble a few words on post-its. The recovery page also covers a lot of scenarios, including a custom recovery tool like Muun has. So much to cover 😂. Not sure if my reply is helpful. I'll try to take it all in and iterate on the current draft. Feel free to share more thoughts. |
I disagree, I think every wallet should include alternate network settings for users to gain comfort before committing funds. It enables learning. Learning on an unrelated piece of software is fractionally as valuable as learning on the software you are evaluating for use.
Yep, it's imo inevitable we live in a multi-wallet world both for backwards and forwards compatibility. And when we do, users will expect competent and flexible interfaces for them not a new software for every use case.
Whether via printed prearranged documents or post-its, both are terribly bad practice. Plaintext key storage with all the relevant details in one place, let alone paper, is asking for trouble. It's also a reality that most users already in Bitcoin haven't been onboarded with software that meets this design guides criteria. Not describing the function or importance of derivation paths for example is a common pitfall in many users experiences, at least when providing support. I also worry that these guidance are shoehorning people into the universally discouraged for implementation BIP 39 while failing to support descriptor wallets. This lack of support is especially apparent in the singular potential descriptor suggested as a QR code. It's a vision of a future where wallets have a single use case and we first and foremost encourage very poor solutions like BIP39 and paper wallet backups on print outs in plain text. I'm just gobsmacked at how bad that advice is for so many reasons. Please people never feed your secrets to a printer - I WILL STEAL THEM! We need to support users coming from all manner of backgrounds and even having received a half-baked Bitcoin education. This includes users already using multiple wallets as is a current best practice. To me, multiple wallet support is a necessity in most Bitcoin wallets for these reasons alone. In sum best practice standards for wallets should absolutely include alternative network configurations as well as multiple wallet options - even if the design goal is to migrate people to single wallet solutions. |
Pushing updated copy and visuals based on feedback. I am still working through things, but want to make the progress available. Still a draft. No need to give feedback right now.
Re-reading the copy, re-writing for clarity, adding image captions, adding more images to flesh out certain flows, etc.
|
Alright, the page has evolved quite a lot and I'd appreciate another round of feedback. We'll also discuss the page in the jam session on Monday. Everything has been iterated on, and there is a lot more content around the use cases and key management now (based on this comment), but I am sure it still has some gaps and issues. I found myself cross-referencing a lot of pages from the other reference designs, since this one in a way brings them all into a single application and discusses the points of overlap. So if a reader really wants to go deep, they might need to click through to those other pages and read up a bit. I think it's something we can't avoid as the guide grows, if we want to limit duplication. Anyhow, looking forward to your feedback. |
|
Great work, Christoph. I really like the initial flow that leads to the recommended wallet configuration. I was drafting something very similar for the Custom Spending Conditions use case as a starting point. I don't think there is anything missing. Great section about the degrees of separation. One thing worth considering here, and I'm not sure about this myself, is whether to recommend users to create a wallet for inheritance in the same app along other wallets that they use daily. Even if it's just a watch-only wallet. It could turn into a security threat, if an attacker gets hold of my phone and sees that there is an inheritance wallet. Ultimately it will be up to the users to decide, though. Also a good point to discuss archived wallets. |
There was a problem hiding this comment.
Some every small copy suggestions, feel free to do with them as you see fit. This reads very well in general even though it is more complex topic to verbally describe, nicely done there.
One more was the use of the word wallet selector vs wallet switcher. Just to see if its best to use both in the copy or keep to one. Or if there is a differentiation between both words.
Co-authored-by: Mogashni <90313394+mouxdesign@users.noreply.github.com>
Now it's listed along with the other reference designs. Also fixed the border radius on one of the images.
|
We just had a reading sessions where we got together on Jitsi and read through the page from the top and discussed the content (recordings are on BitcoinTV and YouTube). We only made it about halfway, so we'll schedule another session. I have a few notes for smaller changes, but will wait with implementation until after the next session. |
Applying feedback from the two reading sessions. - Some copy clarifications - Added unique visuals for wallet types throughout the page for easier recognition - Few extra links to Stablecoins and Ecash - New paragraph about application-layer accounts - Pagination fixes - Image alt texts
|
Alright, we finished the review yesterday in our second session (big thanks for that). I went through and tried to apply the feedback, as follows:
Now I think this is ready to go. But happy to hear otherwise and appreciate more reviews. |
|
Those calls were super helpful. The page looks really nice. Really like the use of the individual icons which pull the readers eye to understanding the various wallets as well as understanding the copy. Two minor comments. View only inheritance wallet...would it be possible to add in the eye that is also ontop of the other designs? Other than those...I'd say it looks ready to sail ⛵ |
Based on feedback.
|
Your wish is my command. I made both of those changes. Ready for more reviews. |
Jekyll removed some duplicate entries.
This is a new reference design page about how an application UI can be designed where the user has multiple wallets in parallel. Technically, the daily spending wallet has two wallets (lightning and on-chain), but the on-chain one is completely hidden in favor of lightning. This is appropriate for a wallet for personal use for day-to-day spending. This page is about a product for users who need to manage more complex finances, including separate shared wallets and a savings wallet for larger amounts.
Since this is not a one-size-fits-all product, there needs to be a lot of consideration to guiding users towards setups that fit their needs, while also checking off all the security and privacy boxes. Roughly the first half of the page deals with that.
Otherwise, I don't think fundamental changes are needed from the UI of the daily spending wallet, to support multi-wallet UI. But, there are lots of smaller changes across all the various screens and user flows. The sections on the page therefore are split up similarly to the pages of the daily spending wallet.
Something I am not quite sure on yet, is how detailed to get with each of the flows. The first version touches on most user flows with 1-2 screens. That might be enough for a first version of the page that we could expand on in the future.
👻Check the preview🐝
Closes #867 an #986