April 26, 2018
4 min. read
Disintermediation — … again
Trustless has become kind of a dogma in the crypto community.
Lets start with a look at the roots, that is, the Bitcoin Whitepaper. It mentions trust in the following contexts:
Satoshi’s clear, non-bullshit language and the elegance of the system he envisioned reminds me a lot of the story about Joshua Levine (as narrated in this book) who in the 1980s set out to cut out the powerful intermediaries on Wall Street (which human brokers still were back then) by building an electronic system which would allow ordinary people to directly interact with each other.
The discrepancy between the effects Joshua expected to have vs what actually happened should be a cautionary lesson to everybody in the crypto community who sincerely wants to change the world for the better.
Invisible trust requirements…
Satoshi clearly identified the trust requirements his system was about to eliminate. He did however probably not have such a clear idea about trust requirements hereby introduced, because on an abstract level they are not visible.
Essentially, the requirement to trust 3rd parties has been replaced by the requirement to trust yourself: your technical capabilities (on a lot of levels), your capability to not make mistakes, your capability to not forget. To be fair, in the scenario with intermediaries those trust requirements are not totally absent, but they’re usually reduced by regulation shifting liability to the intermediary unless you act too negligently.
… lead to centralization (again)
What happens in practice when a system tries to shift the full burden of responsibility on the individual is that many (maybe most) just opt out.
Not surprisingly, alot of people today keep their crypto assets in crypto banks (coinbase et al), often without even being aware of that.
Many in the community keep believing that the solution to this problem of re-centralization is to increase the efforts of educating people and to improve usability.
In my opintion, while both are important, that’s not enough.
Trust is not binary
We need to break out of the mindset imposed by the trustless dogma.
Trust is not a simple binary concept.
I’ve recently bought a used folding bike from a stranger. He trusted me to ride the bike to an ATM out of his view of sight, because I had forgotten to bring enough cash with me. He trusted me not to take advantage of the opportunity to steal the bike and disappear — he even declined the offer to leave my phone as collateral.
This ad-hoc trust relation was induced by a lot of parameters, e.g. prior experiences of both of us, our current mood, the environment where we met, the social capital of the place where we’re living etc.
Trust needs to be understood as a gradual concept, not something hardcoded.
2-Factor-Authentication for an application handling secretes or valuables should not be configurable only in a binary way (on or off), but also be able to depend on context, e.g. the amount to be transferred by a wallet application.
Similarly, a blockchain transaction with zero confirmations isn’t automatically a bad thing to be avoided. It again depends on context — in many cases the usability advantage outweighs the risk.
The golden mean
I claim that in order to build applications which are safe and appealing for many, we need not to switch from one extreme (everybody trust a simple entity, as in Facebook) to another extreme (everybody trust only themselves, as in Bitcoin), but start from trust relations which already exist in the real world and leverage those to build more decentralized (but not atomized), more resilient — ultimately more natural — networks.
There’s already timid developments into that direction. Zeropass for example allows key recovery through distribution of key shares to family and friends. A similar concept was dubbed “social recovery” by the uPort project (mentioned in this blog post).
I think there’s much more we can do.
Our digital tools need a much better awareness about existing trust relations and become much better at inferring and also visualizing adequate trust levels. Defaults need to become smarter, because good defaults are a core element for usability and safety.
Finally, an example for what this could mean:
Vault-type applications (e.g. wallets) need a mechanism which from a user perspective works like a “forgot password” button — because that’s what most people are used to and thus also expect.
The process started by that buttons and the prerequisites to have that process in place when it’s needed, without requiring an opaque central authority and without introducing worse attack vectors than we have now, that’s one of the challenges we have to tackle.