There’s a time for action and there’s a time for dreams. This is the time for dreams.
In this paper I am going to explore the question: how to achieve Bitcoin mass adoption with current Bitcoin technology, without compromising on security, trust, or privacy.
Unfortunately Bitcoin mass adoption is inevitable. Unfortunately because it will be tied to the next financial crisis. The certainty of such event is not disputed, the debate is only about its timing. And, during these dark times masses will flow into Bitcoin. And, we better be ready. But, what does being ready mean? Having a Bitcoin wallet that does it all. That is able to satisfy the needs of most of the population of the World. This may not be sufficient in itself, but without this, all hell will break loose.
Putting it into perspective, this article is all about exploring the question: how to save the World of the next financial crisis by building out a ready to use alternative?
To achieve the stated goal, I established 7 principles, that will guide my thinking while putting together this software and hardware stack.
7 First Principles
1. Security
If there is one thing you want to do with your money is that you want to keep it secure. Thus security is the first, most important principle.
2. Privacy
If there is another thing you want to do with your money is that you want to keep the knowledge about it to yourself. I don’t want to tell you how much money I have, and you don’t want to tell me how much money you have. Thus the second most important principle is privacy.
3. Trustlessness
Trustlessness is the third most important principle. Even if you are able to keep your money secure and private, you will also have to be certain about that your money is secure and private. You don’t want to ask your custodial wallet service provider if your money is secure and private, you don’t want to trust in third parties on this information, you want to trust in the architecture of the system you are using.
4. Open Source
In this paper open source is a means to achieve trustlessness. Nothing more, nothing less.
5. Accessibility
The accessibility principle wants the wallet to be accessible and usable by most of the World’s population. However it does not mean the wallet has to satisfy the needs of niches, in fact satisfying the niches are contradictory to the accessibility principle, because every single additional UI element makes the system a little bit more confusing for everyone else who does not use the feature.
Similarly adding a translation for a language that is only spoken by a few million people makes the system less maintainable. Every time a new feature is added, it will have to be translated also. Because of this, the developers would be crippled, or more likely make dirty decisions, thus the target audience of this system would suffer. And, there goes my native language.
The accessibility principle is also a restriction on the scope of the project.
In order to make design decisions about the accessibility of the system, I will use the Pareto Principle: At least 80% of the potential users’ needs must be met.
6. Stability
There is no worse crime a wallet developer can commit than building an instable system. The responsibility of a developer cannot be understated when this tremendous amount of money is flowing through it.
Interestingly the accessibility principle is an aid for the stability principle. If the developer knows for certainty, that this system will never be handling Dogecoin, running on x86 architectures, on raspberry pies, on Windows 8 with a language setting of Sumerian Cuneiform. If there is certainty about future development direction from the get-go, the developer is much more likely to be able to avoid the inevitable unreliability that comes with cross platform systems.
7. Sustainability
The last principle wants to emphasize that, it is not enough to build something. It also has to be maintained. Historically, large open source projects without revenue streams were only be able to thrive if they acted as backbones of other systems, if their target audience were also developers, or if entities with sufficient resources decided to keep these projects alive.
Design
What systems need to be in place in order to be able to server most of the World’s population?
Platforms
Web, tablet, desktop and mobile. There are many important considerations here, and the first one is to drop the web platform. At the first glance, building a web wallet seems to violate the security principle, but that’s not true if we ensure that, the web wallet can only be used through a hardware wallet. It also seems like it violates the privacy principle. Building network level privacy to a web wallet, as of today is not possible, however I am not short on ideas on this topic, more on this later. Why the web platform should be dropped is because web-apps are second class citizens, while an application that aims to handle most of the value, the user accumulated over his life, should be one of the most important, if not the most important application, which deserves to run natively. This notion does not yet rule out the web platform, but it establishes the need for a software on desktop, tablet or mobile platforms.
Everyone has a smartphone, but not everyone has a tablet or a laptop/desktop computer. Based on the same logic, building software for tablets and desktops are redundant. However with such great project, the stability of this software stack also depends on the health and censorship resistance of the Bitcoin network as the whole, which makes desktop software necessary. I will dive into how the desktop achieves this and how mobile doesn’t later on.
For mobile, Android and iOS are the kings, but in order to ensure stability of the system, design decisions shall not stop here.
Since updating these systems today are somewhat enforced by the walled gardens those created them, the practical design decision here is to guarantee stability only on the latest versions of these operating systems, furthermore, the difficult decision should also be made here about which smartphone models should be supported.
Today Apple and Samsung has over 50% of market share and the numbers here are rapidly changing. This means this wallet will need to support numerous models and vendors in order to ensure the over 80% target. This research is to be done if someone ever would like to execute this plan. Two things to note: market share may not be the best metric here, and do not skip specifying the exact smartphone models and a way how to change this specification.
Desktop. The market penetration of Windows and OSX is over 80%, which should be sufficient to rule out Linux, but the censorship resistance of the Bitcoin network can be undermined by such a design decision, which affects the stability of this system, thus Linux should be supported, too. However, again, because of the stability principle, the exact Linux distributions, operating system versions shall also be specified, which I will omit here.
Hardware Parameters
x86 vs x64, CPU, GPU and such shall also be subjects to upfront considerations.
Localization
Although localization can be a bottleneck for any software project and huge maintenance burden for developers, supporting only the 10 most spoken languages in the World won’t even serve 80% of the population, so the number of languages those need to be supported, just like smartphone models are have to be numerous.
Network Health
Large projects must also make sure of the stability of the system they build upon. This is why a Bitcoin full node and an LN hub and a Tor relay node must be built into the desktop client. To also ensure practicality these systems shall be opt-in, but also easily opt-in.
Security
To minimize the possibility of dependency attacks, the used software packages must be kept minimal and ideally have developers working on both this project and on the software dependency project.
Small dependencies must be either copypasted (with proper attribution) or forked.
Test coverage should approach 100% of critical parts of the system.
There is no other user friendly way to ensure security of the users private keys than hardware wallets. Unfortunately even hardware wallets fall short in this. Supply chain attacks are hard to solve and we can expect in the future organized groups specializing in this field. Furthermore extracting keys of various hardware wallets have also been demonstrated from time to time.
What hardware wallets are great at is withstanding remote attacks.
For the above mentioned reasons, it is a reasonable design decision to delegate the physical security of hardware wallets to the user itself. Being in possession of a hardware wallets shall not be cool, but it should be a secret, whenever possible, instead. This design decision should be clearly communicated to the user.
Regarding supply chain attacks, more research shall be done. A good starting point can be whatever Coldcard is doing.
Hardware wallets are the main revenue stream of the software stack described here.
Hardware wallets are a bastion of this system, however I will only detail how they interact with other components later.
Privacy
Unlike my current project, Wasabi Wallet, this system shall not thrive for ultimate privacy, rather for sufficient privacy instead. Unfortunately it may very well be the case that sufficient privacy is impossible to achieve in a grandma friendly and cost-efficient way with today’s Bitcoin, without Confidential Transactions and Bulletproofs.
What can be achieved in a grandma friendly way is privacy against mass surveillance, but not against targeted attackers. Just like with hardware wallets, we will have to accept this trade off here, too.
Generally privacy can be split into two different categories: network level privacy and blockchain level privacy.
On the network level one must ensure to broadcast transactions in a private way. If a full node is given, a full node should be used for broadcasting. If a full node is not given, the most reliable and fairly private way to broadcast a transaction is to a backend server over Tor.
Unfortunately the Tor traffic is somewhat blocked in large parts of the world, thus a built-in VPN-like service should also be provided as part of the system. While there are some fairly private ways to broadcast transactions without an anonymity network, Tor will play an important role in the followings, so we can assume Tor is a given. The VPN-like service should be another revenue stream for the company.
The second large concern regarding network level privacy is to make sure wallet addresses cannot be connected together by third parties. If a full node is used it is a given, but if a full node is not used it won’t be a given anymore. In Wasabi we use client side filtering, which gives the feel of a light wallet, but for various reasons, it won’t grandma scale, nor mobile scale. Why? I won’t go into the details, you have to trust me with this, I built the damn thing.
A fairly private way of balance retrieval could be to assume no address reuse in the wallet. If we do this, we only have to query address balances those we are expecting coins to and if we do this over different Tor streams, we will rarely expose the link between very few addresses. (Even though we do it over new Tor streams, we will expose the link, because of timing.) Also note that balance monitoring would only be needed for receive addresses, because we know the change address balances, since only we initiate transactions to them.
On the blockchain level there are various ways to achieve the above mentioned resistance to mass surveillance. Assuming no liquidity JoinMarket could be a fine way to go. To ensure cost efficiency with maximum reliability and speed, everyone would have to do every one of their transactions as a 2 of 2 JM coinjoin. However everyone would also have to be a JM maker in the same time, otherwise the privacy gains are dubious. This system’s privacy properties would be similar to Monero’s privacy, except many times weaker, because of the constant 2 anonymity set transactions. However it’d probably throw off non-targeted blockchain analysis, which was my stated goal.
Still not assuming liquidity, but assuming frequent intra-wallet transactions Pay 2 EndPoint could also achieve our stated goal. However it’d change the user-workflow.
Finally assuming liquidity we could do a 2 of 2 protocol, where a sender would either make or take an offer whenever he wants to do a transaction. After pairing the two senders, they could negotiate a transaction where either the changes or the active outputs have equal values from both parties. This could probably also result in the death of most of today’s crypto-financial mass surveillance. This is the most cost-efficient way to transact on-chain in a semi-private way.
Scalability
Unfortunately blockchains don’t scale. Today it seems like the way towards scalability for Bitcoin will be through the Lightning Network. Luckily LN provides sufficient privacy for most people, by most non-crazy definitions of sufficient privacy, but only if the software that facilitates LN is built right. I don’t go into what “built right” means, because I don’t know, but I thin it’s a fair assumption there’s a way to do this. Is it a user friendly way? LN however also brings a host of UX challenges, exploring and solving these are upmost important to this software stack.
Due to the immature state of LN and the lack of developer tools, working on a lightning capable wallet should be delayed to the latest phases of the project.
Revenue Streams
As mentioned above, the software stack’s revenue would come from hardware wallet sales and a VPN service, but also the software stack can implement a “pay as much as you want” model for downloads and the Red Hat model: charging for support.
Putting It All Together
I don’t want to carry my entire life savings with me anywhere all the time. Not only because of security concerns, but also because I may end up buying something that I really should’ve give second thoughts to, but there are many other reasons to separate concerns here into accounts, we already do that. Also note that, by accounts I mean different seeds here, not BIP44 accounts.
There are two types of accounts, one is a the spending account, this account must be implemented on both desktop and mobile. This is also a Lightning Network capable account.
The other is the savings account for desktop, which is not LN-capable, but hardware wallet capable. Movements of value between these accounts should be facilitated with merge avoidance.
Furthermore the savings account is going to be more privacy conscious, more trustless if the user chooses to run a full node. LN hubs must be ran on a spending account.
While 2 of 2 spend-time coinjoins probably doesn’t need special “coinjoin capable hardware wallet improvements” because they are happening real time, such hardware wallet would certainly improve the user experience.
Conclusion
I presented a rough plan for an infrastructure that can be built upon Bitcoin to get ready for mass adoption. This plan requires a large amount of resources and expertise, this plan is large, but so is its impact.
