1 on 1: The future of bitcoin wallets

Pavol Rusnak (pavolrusnak)

Lawrence Nahum (larrybitcoin)

Giacomo Zucco (giacomozucco)

https://twitter.com/kanzure/status/1043445104827084800

GZ: Thank you very much. We're going to talk about the future of bitcoin wallets. As you know, it's a very central topic. We always compare bitcoin to the internet. Wallets are basically like browsers like back at the beginning of the web. They are the first gateway to a user experience for users on bitcoin. It's important to see how they will evolve. We have two exceptional representatives of the wallet world; one is Pavol Rusnak who is one of the leading contributors to the Trezor hardware wallet. It was the first publcily available commercial hardware wallet. It was the first publicly available hardware wallet. The other person on the panel is Lawrence Nahum, the creator of GreenAddress wallet. It was the first wallet implementing p2sh addresses for multisig, bip32 stuff, and the first wallet for supporting many things.

GZ: My first question to you would be, we will talk about the future of bitcoin wallets in general. Can you tell us a little bit about your perspective of bitcoin wallets? What is it that it does? Is it another boring bitcoin wallet, or is it something with some particular features and some particular added value services?

PR: Hello everybody. Like Giacomo said, we were the first available hardware wallet. The idea got into my head and slush's head around 2011. There was a conference in Prague, one of the first bitcoin conferences ever, and we were having a lot of discussions in the hallway like- okay, bitcoin is secure, but we're really not sure about common people who are not IT nerds like us whether they would be able to use it because the protection of the keys is a Key Factor here. We decided that it would be a very good idea to have a special hardware device dedicated to bitcoin wallet operations. It would keep the private key separate from an environment that might be compromised like your laptop or your operating systems that you use like Windows, Linux, Mac, Android, whatever, have 100s of millions of lines of code and it's hard to audit htat. For hardware wallets, it's much less and it's possible to go through the code. We were playing with the idea and experimenting, and it took some time, but in 2013 when we did our crowdfunding effort. It was way before ICOs so we just did regular pre-orders. Since 2014, we were able to deliver this hardware wallet to all users around the world. We've been on the market for 4 years, although the idea is a bit older. What's unique about hardware wallets is that the keys are outside of the really nasty insecure environment. At the same time, there are some limitations. Trezor has relatively small display when you compare it to the normal mobile phone or desktop screen. We have challenges about how to fit all the information we need into that small screen or space. At the same time, we want to be as precise as possible so that the user will not get confused. This are the think the unique features. We have really good security, because the private keys are off the compromised environments, but we have problems with usability because of the screen space on the hardware device is so limited.

LN: I think I started around 2012. There wree no hardware wallets available. I think they were working on it. My biggest fear was that any single device is relatively easy to compromise. To me, multisig was the solution to that problem. The big differentiating factor of GreenAddress is that it uses multisig. It allows you to have a little bit more security and improved security by keeping your keys on one device yet being able to verify things on a separate device before you confirm them. If one of your devices gets attacked, you still have some security left. Inevitably, devices will get compromised, so it's important to have multiple levels of security. As soon as hardware wallets were around, I thought it would be a great marriage for multisig and hardware wallets. This was one of our biggest differentiang factors. When I started, there was nothing that worked across devices. I wanted something tha tI could use on my desktop and also my smartphone, and at the time there was nothing like that. Last but not least, because it's multisig, you can start to enforce interesting things, not just two-factor authentication, but also threshold limits or you could start saying well since I'm part of the signature maybe I could prevent double spending and provide third-party guarantees to others that accept these funds. And this was a long time before lightning was a thing.

GZ: So this was the easy comfortable question, which was what do you do well and what is your take on bitcoin wallets. But now I can go to the nucomfortable question- we have discussed this a lot among long-term bitcoiners about business models and revenue models. The bitcoin wallet is a little bit like the browser like the Mosaic or the Netscape the first gateway. But how do you monetize that? What will be evident to people is that you can't rely on intellectual property, because if you do them properly, you're open-source in this environment or on the client side. You cannot lock the user into an enclosed environment because open protocols like bitcoin or HTTPS or SMTP is to make everybody interoperable with everyone else, and you need an open environment. You can't sell the data of your customers because the point of a good bitcoin wallet is to collect as little data on your users as possible, which is called privacy. With trezor, that's a little bit different. But assuming the hardware becomes commodity, how the hell do you guys or can you guys monetize or have a revenue model and business model to make a good business model?

PR: Our business model is trivial; when there's a gold rush, sell shovels. Hardware wallets are the shovels, in part. Our business model is just selling hardware wallets. Every piece of the service around it is free. We are aware of the fact that because everything we do is open-source, we have open specifications for hardware, all the code running on the hardware is open-source, so we already have some Trezor clones that copy the idea of a hardware wallet. Because they don't have strong R&D like we do, they can cut the prices lower. We are aware of the fact that maybe in the future once the hardware wallet is totally commoditized, we might need to change the business model. I don't think this will happen soon because people tend to buy established hardware wallets because trust is important. It doesn't make sense to save $20 on a hardware wallet and then put $1m into it. That's one point. At the same time, we're looking at different monetization efforts. Like you said, because we are open and we can't close the wallet. We're the good guys in the industry, so we don't want to sell user data. We don't even store it. I don't want to deal with the authorities asking for that data. That's another business model being used quite often by big companies, but not really applicable to us. There might be others like for example adding extra features that are not currently part of the basic package, for example I could imagine some enterprise setups using for example multisig which is great thing for a company that needs to manage budget, but not interesting for users necessarily which may need simple schemes like 2-of-3 multisig but as a company you might like intricate schemes like 2 signatures from directors or 7 signatures from vice presidents. We are looking at encrypted filesystems and authentication schemes and other security devices and other areas. We might use a business model being used by Redhead and Susse which are working on an operating system of Linux and everything they do is open source but they generate money by having a paid support channel for big enterprise users that might have problems and they get a straight line to level 3 support guy and they have top priority. This might be another way of how to monetize the business. This is not limited just for hardware wallets, but it could be used for software wallets as well. Having enterprise support for big companies who can't afford any downtime, for example.

LN: It's a great question, and a great opportunity to announce our new ICO ((laughter)). Joking aside, for me this whole thing has been a tremendous learning experience. When I started, I wanted to charge per transaction or something like htat. But it was quickly obvious that this was going to ruin user privacy because you would always be able to track our users by looking at extra outputs that pay us, and are they a percentage or a constant, and you would be able to programatticaly detect this. We thought about other ways of doing this, like top up, or pre-pay, or that sort of thing. But that was a lot of development, and the user base is not large enough to warrant that development. You're not going to monetize it that much, unless the ecosystem grows. I thought that the most important thing was to concentrate on improving the user experience and improving user security and prepare bitcoin for taking over the world pretty much. There are a few other options, some of them are referrals like hardware wallets we could say that after a user has a number of coins and it has a risky amount, you can start saying you could use a hardware wallet, and we give them a link and we get a cut of that or something. Another option would be to package what we do for the open-source community into a hardware appliance that you sell to enterprises. There are various ways we think we can monetize this in the future. It's also useful for example with our Liquid service. The idea is that we can build the libraries and the tools people need to integrate not just with Bitcoin but also things like Liquid.

GZ: So a synthesis of your answers would be, enterprise/p2p added value, or b2c/added value services like shares per user and referrals and things like that. I want a follow-up question: what about the legal implication of your centralized service providing added value to the user? For example, there was a discussion about european union asking for KYC/AML on bitcoin wallets even without fiat. Of course, that's bullshit. But if you're a company that is providing added service to your user, they could maybe try to force you not the generic vanilla single signature wallet, but you to provide the information and request that. So this aspect of adding value service is intrinsically more censorship prone than the wallet itself. Do you think this model is somehow risky or should maybe be reconsidered? Do you have any emergency plan?

PR: I like Prague. I don't want to run away from Prague. I would want to change the business model so that I could stay. It's pretty easy for us. Right now, most of the users use our hardware wallet with our software web wallet. But it's not really a requirement. There are a lot of privacy oriented people that prefer to use our trezor with electrum, for example. At the same time, we're trying to-- it's possible because everything we do is open-source, so you can run our own backend on your own server if you want.

LN: It's not just regulators, but also hackers. You want to minimize the information you have.

GZ: So it's about legal hackers and illegal hackers.

LN: Right. You want to minimize the information you have; use zero-knowledge proofs and rangeproofs to enforce things without knowing many things about the customer. If it comes to that, you build something where people can run their own instance. They don't need to use a centralized service. That's the direction we're moving to anyway.

GZ: Assuming there's a government censorship attempt on mobile wallets, while something like a dekstop wallet can be easily compiled from source and distributed... the norm is, within that norm, users trying to use mobile wallet.. is very centralized, app stores on Google and Apple. There was precedent a few years ago of Apple banning all bitcoin applications. Right now we're seeing censorship about infowar or free speech related problems and bitcoin is free speech with money instead of war, basically. In case of a serious crackdown, what's an alternative to the app store model? Of course you can just go to a random javascript website without an application, but in that case, it's very easy to attack you and inject malicious javascript code. The real advantage of an application from the app store is that you can be sure it hasn't been changed over night by the developer. It's a guarnatee against you.

LN: It's also harder to target you if you just use an app.

GZ: Exactly. App Store and Google Play start to be unfriendly or something-- is there a workaround for mobile phone normie users?

PR: I don't think there's a reasonable workaround for Apple, because their operating system is designed to make this hard to install third-party applications without completely compromising the system's security. For Android, there are countries, such as China, where people on Android phones don't use Google Play store but rather Amazon Play store. That's not really a solution because Amazon can do the same censorship things that Google might. There's a really good alternative for Android, called fdroid. They have a distribution platform, you install one application which might be troublesome for normal people because that's the only point where you can mess up with something. You need to manually download the fdroid apk file from the internet and check whether the hases are fine. Once you have the application on your phone, it behaves exactly like the Play store and download apps from the internet, check their consistency, make sure they were not modified on their way to you, and it performs updates. How the project works is that if you're building an open-source application, you register on the fdroid website, and they build the app from the source code and you can check whether they did anything malicious by using deterministic builds, and there's a signature tha tthe biunary was built by their build server. Anything distributed by fdroid needs ot be open-source, because they need to build it. If you want to build a closed-source bitcoin wallet, I don't know a good solution for that.

LN: Closed source bitcoin wallets are a bad idea in the first place. Don't use that.

GZ: That's like a custodian, right.

PR: iOS apps, I don't know. For Android, fdroid might be a good way, if you're a little geeky or if not ask your friends to help you install it.

LN: In order to do anything on Apple, you have to jailbreak it, and you lose some security potentially depending on whether you know what you're doing with it. Android recently added the opportunity for co-signing where you sign it and they co-sign it. We have wallets in the fdroid store, but we also provide APK files on our website and github, which are signed. Another thing not for normies but it's available is that you can build on github or get it directly. It's a good idea to have your app across different commercial stores, but having them on fdroid is the way to go.

GZ: We're talking normies vs geeks. Do you think your respective wallet is a good wallet for normies for non-technical people? If not, do you have a suggestion for a good enough wallet? We know there's always a tradeoff between usability and security. If your wallet is meant to be used by experts, do you have a preferred simple alterntaive for new users? If you think your user is good for both types of bitcoiners, how do you do that? How do you stay in touch with the needs of non-technical users? How can you emulate the behavior and the needs and the pain of a completely clueless mass market user?

PR: We're pretty good at combining security and usability. I have to admit from time to time, we dumb down a little bit our web wallet to stay usable for most people. There are expert geeks that are asking, I would like to have this replace-by-fee feature or child-pay-for-parent feature.

LN: Or coin selection.

PR: Or coin selection, and some people want to just spend htis coin and this output. It is possible, technically, but it would bloat the user interface on the software side. There's always a way- you can use, for example, electrum or any other wallet that has this expert feature and supports the hardware device. In the hardware wallet, these are supported, but we try to keep the web wallet as simple as possible but still some extra features like entering OP_RETURN script because it was easy to add into the user interface. When it comes to hardware itself, in the new Trezor model, we have a much bigger display than the old one, and it's powerful, and we try to establish some kind of user interface narrative so people are not confused when they for example if they do a destructive operation it's using red color. If it's just confirmation of some non-critical thing like changing labels, then it's green. We try to be approachable by normies and newbies. It's easy for us to emulate this, because we have around 50 people at the company working on Trezor. There are some developers, around 10 of them, but most of the people are working with regular people like you mentioned. We also have email support. When we throw out a feature, we immediately see the reaction from the public through our customer support channel. Not all of our employees are geeks. You don't have to hire some external company for usability testing.

LN: Normies and geeks are moving targets. When we started, p2sh didn't even exist. When we launched, we were one of the easiest wallets to use. It meant one-time backup. You don't have to backup multiple times, you just backup once. In a way, it's a moving target. What we have today isn't super user friendly, and we're working on a refresh which should be out in a number of weeks.

PR: Two weeks, right?

LN: Always two weeks. It's good for developers to be in the support group and feel the pain of the users. Optimize for those. Simplify the user interface. The requests from geeks keeps increasing. At the beginning, they were happy with bip32, but now they want hardware wallets, coin selection, replace-by-fee, generic multisig, and soon they will want Schnorr signatures and taproot and so on. It's a constant balance between trying to keep the user experience as simple as possible while enabling power users; you can't just ignore power users. You can't simplify things to the point where they are too dumbed down to be useful for power users.

GZ: What are you excited about in the wallet space and what are you looking at for R&D or production-ready features? Since most of the wallet developers mentioned lightning as a possible next step, I will prevent you from including that in the list.

PR: Somebody might have noticed that Trezor has been experimenting with lightning network already. We have the biggetst node in the network. We're trying to figure out how things work, and I don't mean technical things- that's already documented. We're trying to understand how exactly the lightning network is being used to understand what kind of transactions are going to be there. We're also trying to think how we should integrate of course lightning network with the trezor ecosystem. It's actually pretty hard because historically, trezor wallet was always an offline device which was not directly connected to the internet. And also, we never were trying to solve the mobility problem. We were always saying trezor is here because security of private keys is not a problem. If you want to be mobile, just use a mobile application. Just put some $10-20 and walk around downtown and you'll be okay. But suddenly there's a lightning network which is against these two paradigms we built Trezor with. The straightforward thing to do would be to start and fund a lightning channel using your hardware wallet, and then use a mobile app to operate the channel. But there might be some other options for example if you're a lightning node operator then you might want to have keys stored in a Trezor but then we would need to create some kind of mechanism because currently you need to confirm every transaction manually on the device and this is not an option for lightning because there might be several thousand transactions per minute on the node and your finger would fall off. We might come up with some kind of business rules like if there's a transaction goiung through my node and it's not touching my coins it means sum of inputs and outputs are the same then just verify it's correct but I don't need a user finger press, just relaying the transaction. But this is also new, to being a relay.

LN: Historically, for every feature we add, we have to be backwards compatible forever because users want to spend their coins eventually. The same goes for Lightning. In an ideal world, we would have had it a few years ago. There were a few things that were higher priority for us- improving the user experience and streamlining it for normies while making it still powerful enough for the geeks. The reason I'm saying you want to maintain backwards compatibility is now that lightning has been around I'm conflicted: should I spend a lot of energy implementing the current version to have to support it forever, and then later implement eltoo or something else? We're going to announce checksequenceverify (CSV) support soon, which was an important feature because it makes the entire wallet trustless and it's better for privacy and security. In generla, there's a number of things I was hoping to do that before. If by the time we're done with these features, we'll go to eltoo if it's out, otherwise we might have to implement Lightning.

GZ: What wallets are you excited about and what features might be present in your wallet? When the bitcoin price is $70,000 in 2019, what will it be?

PR: We're thinking about data encryption, but that's not bitcoin related. We're looking into other extensions of bitcoin protocol like for example scriptless scripts and so on. I'm really excited about extensions like MAST and taproot but it's not something that the user will see, it's just a modification of the hardware. But what is going to be perceived by users a lot, and I'm excited about this, we're working on replacement of bip39, which was the standard we devised a few years ago where you first run the device we show you 12-24 words and you write it down on paper and you create a backup of the randomness of the device so that if you lose the device you can recover from the paper seed. Other people were asking they want to create some kind of split scheme so tha tthe device will give me a set of words and I will bury them in several gardens, and to recover the seed, I would need to dig up just two of the burried passphrases. This is shamir secret sharing. We're working on this. I think it would be a really nice way for in the future for how to do proper backups. Right now, a lot of people just take these words, split them in half, store half somewhere and the other half at another location but they don't realize it's not a good idea because you can bruteforce the half you don't have. In Shamir secret sharing, you have a cryptographic guarantee that all the shares are required and you can't compute the secret otherwise. There's some minor details we have to figure out, but it's something we're excited about.

LN: The thing I'm most excited about is privacy and fungibility. The two most important things coming out, hopefully before the next conference, is taproot and Schnorr signatures. What I really like about these two things together is they finally allow wallets that provide advanced security with multisig to look like every other bitcoin transaction. From the perspective of the outside world, they can't tell if you were using a single signature wallet or a multisig wallet. You get a privacy benefit and also a fee benefit because your transaction is going to be cheaper due to its smaller size. In a few words, the idea is to have multiple spending conditions and for the vanilla case which is the one tha thappens the most often when you don't have a dispute between the participants, the transaction will look like a single signature on the blockchain. You get hidden in a sea of similar looking transactions. This excites me a lot. Security, yes there will be improvements like generic multisig, and multiple hardware wallet support. The most secure bitcoin storage solution is n-of-m and whatever n and m are for you, with a different random hardware wallets used, and maybe also a software implementation in the group as well. Then you're not relying on any one individual vendor, you're relying on separate pieces which are harder to compromise.