Many people believe that all cryptocurrency wallets should be open sourced, this may not be the best option despite the current nature of open sourcing for cryptocurrency. Let’s examine some of the issues involved.

Open source coding has greatly helped the cryptocurrency movement no doubt. Cryptocurrency is difficult to understand for the average software programmer who doesn’t have a sophisticated math background and without open source progress would have been much slower due to the need for developers to write their own cryptography libraries.

While it is quite straight-forward to lay out the math in practice, it is still not trivial to write the code to implement it. Thanks to open source, there are probably less bugs and vulnerabilities due to coding errors than would otherwise exist.

Another reason people like open source is because the code itself can be checked by anyone for ‘backdoors’, ‘spyware’ or other malintent software.

While this is also great in theory, it doesn’t really provide a 100% guarantee that there won’t be issues. Why? Well, because 99.9% of the people using the software will not inspect the code and in fact rely on other people to do it for them. And even when other people do in fact, check it, issues can easily be overlooked.

A recent example of where people relied on open source code and got burned was the recent Etherium hack, where a rogue programmer set up a smart contract that effectively drained 3.6 million ether out for himself. In that case, the code was open source and in fact pored over by many people.

Some people believe in open source so much that you will often find people who are part of the ‘core’ team of a particular cryptocurrency warning people to not use code that is not produced by the ‘core’ itself (see here for an example). Yet, they expect you to 100% trust ‘core’, when in fact ‘core’ teams themselves are often anonymous groups of people without any inherent liability. And in fact, most ‘hacks’ are often ‘inside jobs’. The aforementioned Etherium hack was believe to be an inside job (see here) , as was the Shapeshift hack (see here) and of course I assume most readers are familiar with Mt. Gox. Although Shapeshift and Mt Gox were not open source codebases, the Etherium incident shows that open source model doesn’t 100% ensure against problems.

Well, you may say, we still need open source, because the whole point of Bitcoin and cryptocurrencies in general is to avoid trusting 3rd party entities. It is to “be your own bank” and not rely on counter parties. While that is true, most people are not in a position to write their own software or even review open source code and then build their own applications.

So given that, most people will rely on getting software elsewhere.

So let’s look at the various options

1 Write your own software 2. Download open source code, review and compile an application 3 Download pre-packaged software from a “core” team, that is supposedly based on 100% open source 4 Download software from an external or ‘3rd’ party company, that is supposedly based on open source 5 Download software from an external company that is ‘closed’ source

While 1 and 2 are out of the realm for 99.99% of people, these are the only 100% secure options.

Given that what are the other challenges? Let’s look at each of these cases.

Take 3. Most core teams will provide downloadable prepackaged software for several platforms such as Windows, Mac, Linux and even Android. They may even have an open source code base on the same site such as github.com. However, often the main developers are not the same people who put together the binaries, especially considering that most developers tend to favor one platform over the others and they may farm out the work to build the packages to someone else. Having an automated process to build the various binaries would solve this problem but it can be time consuming to set up and is often skipped. Given that, it would not be that difficult for one person to insert some rogue code into the final builds that are distributed. While, it’s probably assumed this person will get found out eventually, that may be no comfort to people who lose money in the short-term and given that many core teams are anonymous the perp may never be tracked down and held accountable.

Now let’s look at 4. In the case where the process used is similar to 3, then we have the same issues, but perhaps with less trust than the case in 3. That is, the ‘core’ team probably don’t want to damage either their reputation or the reputation of the coin itself, while for a 3rd party, they may care about neither. On the other hand, if they are either a limited company or an individual with a publicly available name and traceability, then in fact their reputation may be more important than a core team due to the fact it may be the basis of their livelihood and they could be subject to lawsuits in the event of issues.

If the process for 4, is not similar to that assumed for 3, then the ability for people to verify that the code downloaded is in fact from open source becomes impossible unless everything is documented and can be verified by independent sources. However, like the previous flow, the developers reputation is still at stake.

In addition, for particular platforms such as IOS, there is no way for independent parties to check that the application they get is exactly the same as an independently built one — without jailbreaking a device. Even that may be somewhat difficult to do unless again everything is well documented, since difference in Xcode versions, etc could still be in play. And if you have cryptocurrencies on your device, you probably don’t want to jailbreak your own device, since it removes the safeguard of app sandboxing.

Now looking at case 5. The liability and reputation model is essentially the same as 4, but is there perhaps a indirect benefit to the end users?

Yes, in fact I believe there is. Since 2, 3 and 4 all provide code, it is possible for anyone to download it, modify a few lines to add some malintent code and then also make it available to the public in any of the forms 2–5.

Since malintent crypto software can be made to act legitimate for the most part, it can easily be made to give the appearance of being trustworthy for an indefinite time. However, code could be written for example to wait for a particular date in the future and at that time transfer all of the coins to a particular address across all of the installed instances of the application. It would be impossible to check for this kind of code by only looking at the executable code and thus the problem wouldn’t be known until it was too late.

Although I don’t know how some particular Bitcoin wallets have done something similar to this, there are reports of several ‘scam’ wallets across the AppStore. There was one case where one mimic-ed the well known “Breadwallet” by supplying an app called “breadwallet” (i.e just a lower case b instead of uppercase). This is even more treacherous than just producing a scam wallet with a different name, since many people may say to others, “Yeah use B(b)readwallet, it’s reliable!”

Some people I’ve discussed this topic with have said, “Well that’s what the rating/review system on the AppStore is for”. We should rely on that since scam wallets will get bad ratings and even be removed from the AppStore, while good wallets will get good ratings. I hope you can see the trap here — any scam wallet could be made to look completely legitimate for any period. In fact, a developer could update a legitimate wallet several times, adding improvements each time and thus getting better and better reviews. Then once he has achieved his reputation goal, he inserts his malicious code through an app update and bam! he drains all of the wallets at once to his own address.

In addition, for the AppStore, although Apple has recourse to that developers information, it is not clear for the cases of scam wallets that have already existed, how they have dealt with it (Would be great to get a comment from Apple on this!). What exactly are the laws here? And will law enforcement take action no matter what territory the original application is uploaded from? It’s also possible that fake identities may be used to create the developer account. So you can see, there are potential issues with having too much faith in the rating system.

So, as you can see, there is a serious problem with fake or scam cryptocurrency wallets. At this point you may say, we need to start regulating these wallets and businesses. Well, I believe eventually that may happen, but for the meantime, regulation is slow to move on these types of issues.

Given all of that, I believe it is better to avoid putting complete open source packages out there— in the form of applications that can easily be built and packaged — for cryptocurrency wallets. I mean, why make it too easy for the scammers (I may in fact follow up this article with a step-by-step illustration of how easy it is) ?

You may say “Security through Obscurity?”. Yes, that may be true but probably the only way to achieve full security would be to write all of the software yourself and even then you are still potentially exposed to the vulnerabilities of the particular platform you are on (but since that’s true for all cases, let’s ignore that). So, essentially, you’ll have to trust someone.

So at this point, who would you prefer to trust? a) An anonymous core team, b) anonymous 3rd party developers, c) An identifiable individual and/or d) a limited company.

My vote would be for c) and d). Although I don’t know of many individuals providing cryptocurrency wallets, I do know there are some companies that do. Two examples of companies that provide excellent software are 1) Exodus and 2) Decentral (provider of the Jaxx wallet). In addition, they both provide solutions across multiple platforms and allow you to use keys that provide ways to access your funds through other wallets.

At this point, it’s also worth mentioning that the people behind the previously mentioned “BreadWallet” Bitcoin wallet, have a company called “BreadWallet” and their wallet on the AppStore no longer claims to be open source.

I don’t have any affiliations with any of these companies but have used their software and chatted with their developers (in the case of Exodus and Decentral) and feel quite comfortable trusting them.

Would love to hear your feedback.