Meaning and Origin of “Don’t Trust. Verify.”

There was a proverb “Trust, but verify”. It was later turned into “Don’t Trust. Verify” as the Bitcoin or blockchain mantra.

Did Satoshi Nakamoto Say That?

When Satoshi Nakamoto announced “Bitcoin open source implementation of P2P currency” on February 11, 2009, there was no such term.

The discussion was about how “trust” played an important role in conventional currency, but Bitcoin was based on cryptographic proof, so anyone can “verify” the ownership.

What to Verify?

Even for a software engineer, it’s more likely that we don’t really verify everything on the blockchain personally. We trust those distributed validators.

Now it comes to cryptocurrency wallet. For Ethereum EOA (Externally Owned Account) wallet, e.g. the popular MetaMask, we trust and reply on it, too.

But shouldn’t we verify before trust it? Especially when it comes to many other wallets out there, either software or hardware wallets?

A Brief About Mnemonic / Secret Recovery Phrase

Cryptocurrency users should have known that mnemonic is the ultimate secret for the wallet. Store it safely and don’t ever lost it.

Private key and corresponding wallet address are derived from mnemonic. We should be able to recover the wallet with mnemonic, whenever the software or hardware wallet breaks.

That’s why MetaMask called mnemonic as “Secret Recovery Phrase”.

Why Verifying Mnemonic?

But how do you know the mnemonic, generated for you, is genuine for accessing the wallet? We store the mnemonic, not the private key!

Before using any new wallet, it would be better to verify before using it, ex. whether the same wallet address can be derived from the same mnemonic through verification.

If the wallet passes verification, reset it for ready use.

How to Verify Mnemonic?

Any experienced software engineer could build with the cryptographic libraries to verify it, in the terminal. But it might be just too hard.

For regular users, the simplest way would be verifying with different wallet vendors. But it could be cumbersome and still relies on other wallet brands.

I would like to have a safe and verifiable “verifier” for people and myself. Everything built from scratch, entirely from source code. And here it is:

Let’s Run the VerifyMnemonicJS App!

Firstly, you need an iPad. Sorry for those who don’t have one. But we need the Swift Playgrounds made by Apple, so we’re building upon the trusted Apple, if you will.

Click the project link and open in Playgrounds. Anyone could check the whole code to be executed. It’s pretty simple UI with a few lines of JavaScript code, along with ether.js. Here are what you can verify to trust: developer of the code (me, @denkeni), and ethers.js (@ricmoo).

That’s it. Nothing else. Run the project and verify the mnemonic in the app!

Why It Matters to Have an App Like This?

For people without security mindset, it would be much easier and safer to run app on the iOS/iPadOS, where malicious software would be hard to hack in or attack in the background, compared with traditional computer, including Windows or even the Mac. Clipboard hijacking has also been prevented through system level alerts.

With Swift Playgrounds, everyone can build the app from scratch. There are some other developer tools available on the App Store, e.g. JSBox, Pythonista. I simply choose what Apple has offered to minimize third party tools.

Why building from scratch matters?

Open source is the building pillar of blockchain. Serious software engineers would build his software from source code, instead of using binary executable built from others. It would not be easy to verify whether malicious code is compiled or even injected into binary executable, especially on the iOS app.

What about building a web app as a crypto wallet? Theoretically it can be done, but managing and safeguarding private keys in web browser storage can be troublesome.

Lastly, I would like to make the verification app as safe as possible, even if someone inputs mnemonic of wallet in use. The app suggests turning off network before using it. By running JavaScript rather than native code, no Keychain item would be created, which could be preserved even between app reinstalls. Minimizing attack vectors.

Will You Submit It to the App Store?

No. Building from open source code is the key feature of the app. But even if you’d like to run it on the iPhone, you could build the project with Xcode on the Mac. By the way, the project is under MIT license. Do whatever you’d like. No warranty!

There’s definitely room for improvement. We’ll see how it goes.

Final Thoughts on Trust

Because it’s impossible to verify every aspect of the whole code, it’s more important to build the chain of trust. Even Linus Torvalds works like that! Based on the chain of trust, similar to how relationship works in real life, lots of software kingdoms are built.

When running this project, you’re trusting people or organization as follows:

• code (@denkeni)

• ethers.js (@ricmoo)

• Swift Playgrounds (Apple)

• iPadOS (Apple)

As Ken Thompson's Turing award lecture “Reflections on trusting trust” saying:

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

But people made mistakes. In 2015, Apple’s Xcode was found malicious code injected, called “XcodeGhost”.

So we verify, to challenge and rebuild our trust.