Posts in the Discussion category

Privacy in Bisq

To write a blog post about privacy in Bisq has been already a long time on my TODO list.

One reason why I postponed it for so long was that I tried to fix the weaknesses rather than to explain such complicated stuff to a broader (potentially non-technical) audience.

But as we still don’t have the resources to fix the main issue (see section below about the BitcoinJ bloom filter) I want to explain the background of the issue and propose the solution how you can protect your privacy even in the presence of that existing weakness.

Beside that I want to give an overview about different areas where privacy is relevant in Bisq.
I think we have already achieved a very high level of protection of user’s privacy. We can do still better and are working on further improvements.

But the main goal of that article is to give those who take privacy serious enough background and guide them how they can get out the most from Bisq.

Be warned, that blog post will be a bit technical. Privacy is a complex topic and requires some basic understanding about how Bitcoin transactions work.

So let’s get started.

One area where privacy plays an important role is how the data between the peers are transferred.

Privacy in the P2P network

We use Tor (hidden services) for the P2P network.

With Tor we get a very high level of privacy on the transport layer. So there are no IP addresses visible which could be used to identify a trader. As we use hidden services we even don’t have the issue that the exit nodes are a critical bottleneck in Tor.

In Bisq there are mainly 2 different types of messages:

– Broadcast messages (e.g. offers are broadcasted to all peers)
– Direct messages (e.g. 2 peers are communicating directly in the trade process)

In the first case the messages are not encrypted as all users need to be able to read the offers. The only identifying data included in an offer is the onion address of the offer-maker. That is required to contact him when one wants to take the offer.

The direct messages are sent directly to the other peer and are encrypted and signed in Bisq. Beside that it is encrypted as well on the Tor layer.

Though there are some things which needs to be considered – even with Tor.

The repeated usage of the onion address carries a potential privacy concern:
Onion addresses of offers and trades could be used to map together an identity.

But that privacy leak to the trading peer can be also seen as a feature – and is actually used as such:
The small icon on the right of an offer entry or trade shows the onion address, whether you have traded already as well as the nr. of trades. This kind of “P2P reputation” (only you get the info about the data which you have anyway in the app from past trades – there is no centralized data collection) can be useful to easily identify traders with which one has traded already.

You can even tag a peer with arbitrary text like “Fast trader” (this data is only used in the scope of your local application).

Edit peer info

 

Tooltip

 

There might be different opinions if the re-use of the onion address for all offers and trades is positive (can be used for reputation) or if it is considered negative in regards to privacy.

Future improvements:
In future versions we want to make it possible to reset your onion address (in the settings).
There might be another option that we use separate onion addresses for each offer. But that might be resource heavy as multiple Tor circuits need to be maintained, multiple hidden service published (takes about 30 sec. – that is the delay at the application startup) and will complicate code as well. So this is not considered for the near future.

Beside that we will support an optional GPG key which can be used for reputation.
In the next version we will add this already on the data layer, though it is not implemented yet in the UI. With that key we could build a reputation system where a user can proof with his signature that he is the originator of certain offers or trades if he wants to and to whom he wants to.

That way we decouple the network ID with reputation and users can choose if they want to build up a long term reputation at the cost of loss of some privacy to the trading peer or if they prefer to not use reputation and in case of network ID renewals the offers and trades cannot be associated to one identity.

What can you do now?
For users who don’t want to connect potentially all their offers to one identity it is recommended to create a new data directory from time to time (you must not have open offers, trades or disputes) or to use a program argument (e.g. –appName=Bisq-2) so a new data directory with that given name will be created and you can run multiple instances of Bisq in parallel which are completely unrelated (that setup is used by developers as well).

Summary:
The usage of the network ID (onion address) might be seen as privacy weakness but to have a long term ID is a requirement for reputation.
In future we will decouple that by using an optional GPG key for reputation and enable renewal of the onion address.

Privacy in Fiat trades

When the users are trading Bitcoin with a national currency the transfer of the Fiat currency requires usually some personally identifying data.

With a bank transfer it is typically the name and the bank account number. With other payment methods it might be an email address or phone number (e.g. ClearXchange, Interac, Swish,…). Only with OKPay and PerfectMoney an account number alone is sufficient. But even there the account is usually verified in the registration process at the payment provider so the company knows the real life identity behind that account number.

It is important to understand that only the trading peer will see that account data (the name in the case of a bank transfer) as well as the arbitrator in case of a dispute.
In all trades which are not disputed, the arbitrator has no access to this data. The account data is only stored locally on your computer.

The Fiat receiver needs to expose his bank data to the other peer, otherwise the Fiat sender could not transfer the money.
The Fiat sender usually also gets exposed by the receiving bank as most banks show the name and bank account nr. of the sender in the transaction history.

There is another important reason why we exchange the account data in both directions:
There are some known social engineering scams where a BTC seller receives the Fiat money from a victim who got tricked into a purchase at some Ebay-like platforms but the victim never receives the purchased good. The scammer gives the victim the bank account nr. of the BTC seller, the BTC seller receives the Fiat and then releases the BTC to the scammer. After a few days the victim discovers that he got scammed, goes to the police and probably requests a bank chargeback. The seller gets in trouble to explain that he was not the scammer and probably accepts the chargeback to avoid more hassles.

Luckily that never happened at Bisq but we need to be careful not to attract such scammers.
To protect against such fraud we require the Fiat receiver to only release the BTC if the bank data in the Bisq application is matching with the data on his bank statement, otherwise he needs to open a dispute.

Planned improvements:
The payment account data (e.g. bank account number and name in case of a bank transfer) could be encrypted by default when the data is exchanged with the arbitrator in case of a dispute. In most cases the arbitrator does not require the data so the traders privacy is better protected. Only in those rare cases when the arbitrator needs the data for the dispute resolution process he can request the decrypted data from the trader.

Summary:
The exposure of the bank account data to the other peer (and arbitrator in case of a dispute) is a necessary requirement when a Fiat transfer is involved. In future releases we might add an improvement that the arbitrator does not see the account data by default and has to request it from the trader if needed.

Avoiding coin merge

The returned change amount when funding an offer and/or trade as well as the funds you get out from a completed trade are re-used for other trades if you choose to use the Bisq internal wallet.
This connects the trades at the Bitcoin transaction graph level.

To avoid that, you need to fund each offer independently from an external wallet and withdraw the funds at the end of the trade to an external wallet.
Of course you need to take care that you don’t leak your privacy with coin merge again in the external wallet (you can use multiple external wallets as well to make that easier).

UI-wise that strategy is fully supported in Bisq (in fact it was the only option initially) but we are aware that most people prefer the more convenient usage of the internal wallet to re-use bitcoins from one trade for funding the next trade.
Unfortunately there is no good solution to combine both convenience with privacy here.

To offer a tool (similar to coin control in Bitcoin Core) to let the user decide which unspent transaction outputs (UTXO) should be used for funding an offer or trade might help to mitigate the problem. But there is some complexity and difficulty involved to decide which UTXO to use as well the problem that often you don’t have enough options to choose from. So that approach does not look like a feasible strategy to solve that issue. It is a conceptual problem from the way how transactions are connected in a graph in Bitcoin.

Coinjoin is one of the very few strategies to combat that issue.
We have rough plans to either add Coinjoin to Bisq in future, integrate an external Coinjoin implementation in a user friendly manner or find another solution with an automated trade to an Altcoin which has strong privacy protection built in at the protocol level like Monero or Zcash.

Hopefully we will see more privacy improvements like Confidential transactions integrated to Bitcoin as well.

Summary:
If you want strong privacy you need to fund each trade independently and withdraw the funds from a completed trade to an external wallet where you have to take care to not merge the coins again (which is not easy).

Privacy in the Bitcoin network

The connection to the Bitcoin network (we use BitcoinJ which uses the SPV model) is by default over Tor (we use a mix of connections to clear-net full nodes which are passing the Tor exit nodes and full nodes running as hidden services, therefore never exiting the Tor network).
The user can pass a program argument to use a custom Bitcoin full node as well. Alternatively a locally running Bitcoin node (localhost) can be used. The Bisq application discovers that local node automatically and uses it as the only node for the Bitcoin network connection. So no configuration is required.

The users who don’t run their own full Bitcoin node are exposed to a severe privacy leak inherited from the broken BitcoinJ bloom filters [1], [2].
I tried to fix the most critical flaws [3] but unfortunately it turned out that it requires more effort to fix that [4]. So the bloom filters are still leaking considerable information to full nodes (in case those are operated by chain analysis companies spying on the network).

What is leaked:
A spying full node will find out quite easily that all the addresses created by the HD wallet (about 1300) are from one wallet (belongs to the same owner).

They don’t see the IP address as we use Tor (with other BitcoinJ wallets even the IP address is leaked).
If one of those addresses is connected to the real life identity of the user all the other addresses are de-anonymized as well (derived from the fact that all come from one wallet – same owner).

Revealing a real life identity can happen easily if you use one of your wallet addresses for any service where you have to register with your ID (centralized exchanges, merchants,…).
Even if you don’t leak any Bisq address, with more sophisticated graph analysis using typical usage patterns (e.g. coin merge) it can happen easier than expected that you lose your privacy.

So don’t expect privacy on the Bitcoin level unless you run your own full node or you really know what you are doing and are aware of all the pitfalls.

We have some bounties open in that area and we consider this a high priority issue which hopefully gets solved soon.
Any developer experienced with BitcoinJ is very welcome to get in touch with us!

Unfortunately the bloom filters are broken also on the design level, but to fix the implementation flaws would give us at least some level of improvement (and render the effort for the spies higher as well as reduce the quality of their data due to a higher degree of uncertainty – though there might be controversial opinions about that).
That said, you should not be tempted to assume that the privacy problems of bloom filters are fixed after the BitcoinJ bloom filter implementation flaw is fixed.
To get a new bloom filter design implemented and deployed to Bitcoin Core is unfortunately something we cannot expect to happen soon. There are a few interesting efforts in that direction but I am not aware that anyone is working on that [5], [6], [7].

But there is another very promising solution on the horizon:
To use a Bitcoin Core node in SPV mode [8].
Jonas Schnelli is working on that and we consider to replace BitcoinJ by that as soon it is production ready and we have enough dev resources to implement it.

So what can a user do in the current situation to get a protection against those spying full nodes?
As said initially the only protection is to run your own full node, either locally (then Bisq connects by default to it) or you pass the IP address to your node (or a trusted node you know) via a program argument (—btcNodes=[comma separated IP addresses]).

But it is important to do that already at the first startup and always. One connection to the public Bitcoin network can be enough that you get connected to a spying node and your privacy is leaked (only a new data directory which creates a new wallet will help then – in our Github wiki there are instructions [9] how to do that).

To communicate that complicated issue by displaying a popup at the first Bisq startup would be too confusing and overstraining for most users.

One possible compromise might be to use by default a white-list of trusted full nodes. The user can change to run his own local or remote full node, use his own list of trusted nodes or use the public Bitcoin network. As explained above it must already be taken care of at the first startup, so to use the public network as default would require a popup explaining the complex topic.
To use a white-list of trusted nodes compiled by the Bisq developers introduces centralization and trust issues.
Though I think that is less critical as the user can change afterwards to the public network without any damage, which is not true for the other direction (first public then trusted nodes).

This is clearly controversial and not an optimal solution at all, but might be preferable to the current state where everyone is leaking potentially (and I assume to a high probability) their privacy.
We have not decided to go that road yet, but it is in discussion.

Though as said above a SPV Bitcoin node would be probably the solution we will go mid-term and that would solve that issue anyway.

Summary:
For achieving privacy protection on the Bitcoin network level you need to run your own full node.
We are trying to fix the implementation flaws in BitcoinJ but unfortunately bloom filters are already broken on the design level so we will never get proper privacy with the current bloom filters (Bitcoin side).
Alternatively we could provide a white-list of trusted full nodes and use that as default instead of the connection to the public network. This is a problematic approach as well and still in discussion.

The mid-term goal is to use a SPV Bitcoin node integrated in Bisq (similar like we use the Tor binary). For the user that would be transparent and the usability comparable with the current BitcoinJ SPV model. That would not only solve the bloom filter issue but also other weaknesses of BitcoinJ’s SPV model (e.g. no validation of consensus rules; in case of a hardfork with Bitcoin Unlimited it would follow automatically the longest PoW chain).

Conclusion

Those who care about privacy, take the time to understand the complex context [10],[11],[12] and are willing to take the burden to run a full node as well keeping the funding of trades independent to avoid coin merge, can use Bisq with a very high level of privacy protection.
The others are probably leaking their privacy already in many other areas as well so Bisq does not really make their exposure worse.

This is not a satisfying situation though as we want to provide privacy by default in a user friendly manner. Convenience and privacy are unfortunately often hard to combine.
But we will continue to work to find the best solutions to solve those current weaknesses.

With all that said we have to emphasize that Bisq has already archived a very high level of privacy protection and clearly outperforms any other Bitcoin exchange in that matter.

  • No registration required. No centralized data collection.
  • We use Tor by default for all network traffic. So your IP address never get leaked!
  • Our UI supports coin merge avoidance.
  • Bisq uses a HD wallet. No address re-use
  • There will be future improvements to decouple the network ID with an optional reputation key.
  • Once we can use a SPV Bitcoin Core node instead of BitcoinJ we get rid of the bloom filter problem.

Protection of privacy is not only a core value of Bisq but we see it also as a fundamental property of money to achieve fungibility.
Bitcoin and the surrounding infrastructure (like exchanges) need to improve in that area so Bitcoin can develop it’s full potential as sound money. Sound money for a sound society. Protection of privacy has to be the default state for all, not just a privilege for techies and geeks.

America’s founding fathers have been more aware of this than today’s retarded politicians.
As we cannot expect much support from that side, let’s build our new model as we think it should look like and make the retarded model obsolete.

References:
[1] Privacy in BitcoinJ: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj
[2] On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients: https://eprint.iacr.org/2014/763.pdf
[3] Review bloom filter fixes in Bisq’s BitcoinJ fork: https://github.com/bitsquare/bitsquare/issues/414
[4] Bounty: Review Bisq’s BitcoinJ Bloomfilter fixes: https://github.com/bitsquare/bitsquare/issues/487
[5] Leo Wandersleb efforts: https://github.com/Giszmo/TransactionFinder
[6] Committed bloom filters for improved wallet performance and SPV security: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
[7] How have fungiblity problems affected you in Bitcoin?: https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/d5ux6aq
[8]Complete hybrid full block SPV mode: https://github.com/bitcoin/bitcoin/pull/9483
[9] Switching to a new data directory: https://github.com/bitsquare/bitsquare/wiki/Switching-to-a-new-data-directory
[10] Bitcoin Privacy Landscape In 2017 — Beyond Coin Mixing, General Guidelines And Research: https://hackernoon.com/bitcoin-privacy-landscape-in-2017-zero-to-hero-guidelines-and-research-a10d30f1e034#.6ptypp28o
[11] Bitcoin Privacy: Theory and Practice – Jonas Nick: https://www.youtube.com/watch?v=HScK4pkDNds&t=11m30s
[12] Bloom filtering, privacy – Adam Back: https://www.reddit.com/r/bitcoin_devlist/comments/3bsugu/bloom_filtering_privacy_adam_back_feb_20_2015/

Share

The really interesting problem in the recent Bitcoin crisis is not the block size debate. Nearly everyone agrees that there is need for a solution, but the consensus ends there. The form that the solution should take – and even the urgency of the problem itself – are still both hotly debated.

The more interesting problem is the little-discussed shift in governance model that some would like to see take place. Bitcoin’s current governance is based on consensus, but Bitcoin XT proponents would like to see it shift to a benevolent dictatorship of sorts.

The benevolent dictatorship model is used in many software projects, is widely accepted, and works well. But Bitcoin is not a usual software project. It’s a decentralized, censorship-resistant currency with a market capitalization of several billion.

How Power Happens

To place a single person in the role of central decision-maker of Bitcoin would create an unpredictable, massive risk for that person, as well as the currency itself.

Imagine Bitcoin scales to become a globally-used currency with orders of magnitude more market capitalization than it has today. Bitcoin’s “benevolent dictator” – whomever it happened to be – would not be able to withstand the pressure that such a position would bring. No one could.

What kind of pressure would this be? When one individual’s actions have the power to affect billions of dollars worth of other peoples’ outcomes, that person becomes a magnet for bidders looking to purchase the most favorable outcome – for themselves. The actions of Bitcoin’s benevolent dictator would truly be up to the highest bidder or the most coercive criminal or government.

So we have a contradiction: those who argue for more scalability – the XTers – want to implement an even more vulnerable bottleneck to scalability. This single-person bottleneck is such a fundamental deviation from Bitcoin’s constitutional values of decentralization and censorship-resistance that the author of this article would switch to using alternative cryptocurrencies.

Most interesting to me is that the block size and fork debates have revealed how human nature responds to power. Even if the involved actors solve the current problem, it will not be the last time that Bitcoin is challenged by a non-technical, existential crisis. Many of us prefer to avoid confronting old ugly politics, but despite our best efforts, they’ve found us anyway.

How to Create & Maintain Decentralization

The current consensus-based governance process in Bitcoin is far from perfect: there is still only a relatively small group of people who are able to make decisions. The primary lesson from this crisis, then, should be how to improve that model.

A better model may be similar to what young nation-states do: set up constitutions and impose structures to prevent deviation from the founding ideas. But is that the only way to go? Is it healthy and future-proof for a project to gain so much power that imposed structures are required to make changes more and more difficult? Imposed structures which attract more and more bidders looking to buy influence as the project gets bigger? Is this inherently political environment inevitable, or are there other ways out?

I propose an alternative, one which was not possible before cryptocurrency: let us support a network of many smaller currencies instead of following the ideas of a single, dominant one.

The Domino Effect as a Sign of Centralization

Isn’t it ludicrous that the current Bitcoin crisis is affecting nearly all other cryptocurrencies as well? It reminds one of the 2008 financial crisis, in which the failure of one institution was deemed a systemic threat to the entire global financial structure.

But supporting a network of smaller cryptocurrencies would relieve the political pressure of trying to have “one true blockchain.” It would create and maintain actual decentralization in money. Releasing Bitcoin’s political burden as a multi billion dollar asset will also make space for innovation. Even the pressure of governmental intervention can be mitigated by distributing its impact across the entire cryptocucrrency sphere, where a single failure doesn’t cause systemic risk for the whole ecosystem.

Now to the caveats of my proposed solution: using a multitude of smaller cryptocurrencies is not the sort of system we are used to. Historically people haven’t preferred to deal with multiple currencies. But the problems of a multi-currency ecosystem can be solved when we have near-frictionless, automated, and trust-free exchanges.

And it just so happens that crypto currencies can provide all of those things.

The Solution Stack

An atomic cross-chain exchange is a possible solution. It currently lacks decentralized implementation, however. If you need to support multiple blockchains, you cannot easily build a P2P system which scales. Additionally, Mercury is an implementation which uses servers to overcome that particular problem.

But there is another possible solution which fulfills the requirements of a fully decentralized exchange without suffering from usability and resource problems. The full nodes of various blockchains need to support the features required for the exchange protocol. If a cryptocurrency implementation does not provide those features, an extension would need to be built for the original full nodes which adds those features.

The users supporting the exchange would then be incentivized to run these nodes, which would be fully compatible with the original node but offer an additional feature set. This is similar to the model Bitcoin XT uses (added UTXO support for Lighthouse). Tasks of a server can instead be executed by an unlimited set of P2P nodes. The node extensions might look similar to blockchain APIs, but come as a wrapper around the original full node of a given blockchain.

Application Example

Imagine a multi-currency wallet with 10 or 20 different coins, where you can decide what percentage to assign to which currency in your portfolio. It would conceptually be more similar to a stock portfolio than a traditional wallet. You could use trading agents/bots to get the best exchange rates, and your trades could be executed automatically in the background using the atomic cross chain exchange protocol.

If a merchant only accepts one coin, and you don’t happen to own that coin, you could simply buy it on the exchange market. The time it would take to wait for a confirmation could be mitigated by services that offer zero-confirmation transactions (e.g. using reputation or security deposits).

Note that this scenario lacks a dominant currency. This is not a problem. It actually liberates coin projects from bearing the burden of having too much power, with the regrettably attendant need for increasingly strict and complex governance models.

In this scenario, centrally-controlled currencies which used a benevolent dictatorship model would not be able to cause systemic risk, because a multitude of independent currencies exist as alternatives. People don’t care if a restaurant is run by a benevolent dictator or by a collective of employees, correct? As long as there are competing restaurants to choose from and no monopoly or cartel controlling the market, the governance model of individual businesses doesn’t really matter.

An Actual Internet of Money

The solution discussed here would get us closer to something like a real Internet of money. Just as the browser was the tool connecting content and later applications together, a multi-currency wallet with an atomic cross-chain exchange would be the tool to connect various flavors of cryptocurrency. As fast and as simple as it is to click links from one webpage to another, so too could it be to exchange one coin for another. It should be kind of a no-brainer, really.

Governance and Politics

We can never escape from the realm of politics and the need for governance, but when we are able to reduce the power we’re exposed to, power’s attendant problems become easier to handle.

If you are a software developer, you already know this: if a problem is getting too difficult, you try to break it up into several smaller pieces. You divide and conquer. Decouple dependencies. Avoid god classes. Because small is beautiful.

However you describe this form of problem solving, it’s nothing new. Only the tools are new. And they’re more favorable to us now than anyone could have ever imagined.

Share

Killer apps

Regardless of what you think or whatever you got presented by the media regarding the Greek crisis, I think many of you will agree, that our current political system is in need for a drastic improvement to say the least.
Depending on the interpretation of the severity of the problem one might come to the conclusion that our political, economic and financial system is just too broken to get fixed.

“To change something, build a new model that makes the existing model obsolete” – Buckminster Fuller

History has repeatedly demonstrated that new technologies are able to catalyze truly disruptive transformations that could never have been achieved through political efforts. Consider for instance the groundbreaking technological and social changes that the Internet has brought about all over the world.
The rise of Bitcoin and Blockchain technologies in general embody such a new model capable of moving our world to the next level while rendering the old paradigm obsolete.

The prospect of technologically induced change should not let us forget the warning awareness that technology is never neutral. We have to distinguish the elements rendering freedom, fairness and prosperity from those amplifying existing power structures.

The Internet of money

Before the Internet the production and distribution of information was much more limited to an elitist circle (journalists, writers, teachers, publishers,…). Only the process of consuming the information was freely accessible for most people (newspaper, radio, TV,…). Today, everyone with access to the Internet is enabled to write, read and distribute information at a global scale with basically no cost.

Other areas where information technology has been adopted are still lacking that kind of liberation. Interacting with money is still highly restricted to the narrow channels the gatekeepers of the financial institutions are willing to provide us. With crypto currencies we get access to the creation, the distribution and the processing of that kind of information which represents value – money.

With the Internet we have seen an explosion of new use cases emitted by the liberation of information: From usenet to mailing lists to web pages to blogs to forums to videos to chat rooms to social networks to peer to peer networks and much more. We can expect that the new space opened by Bitcoin and Blockchain technologies might have the potential to fill up a new universe similar to that opened by the Internet and which is as hard to imagine today as it was for the early birds of the web.

Killer apps

Email – the digital equivalent of postal mail – was not  the killer app for the Internet. Nor was it the online version of newspapers or videos. All those who transferred traditional use cases to the Internet did a great job to enrich the ecosystem, but they did not provide the motivating reason to use the Internet for newcomers.
Following the analogy with the Internet it would mean that replacing today’s traditional payment methods (like cash, credit cards, PayPal, banks transfers,…) will unlikely lead to a killer app for Bitcoin. They simply do not add enough value to exceed the mental costs for an actual change of behavior for the majority of people.

More promising use cases are the ones which were simply not possible in the pre-Internet or pre-Bitcoin era: Search engines do not exist outside the web (you can search in a certain application but not at global scope). Social networks represent another example, since there exists no equivalent to it in the non-digital world. Bringing together the power of the crowd in projects like Wikipedia or crowdfunding platforms could likewise not be accomplished without the Internet. I leave it open to the reader to add more.

My definition for a killer app is that it is focussed on a use case that did not exist before being enabled by that new technology. Furthermore it needs to add enough value for the user to exceed the mental costs of trying out new behaviors that might tap into new and uncertain territories. That added value has the power to give that new technology the needed significance for entering the mainstream.

It is not easy to imagine use cases which do not exist yet but which are important enough to gain traction and to evolve over time within the new technological framework.
It is likely that they will arise not from a single center but from a network of emerging technologies, tools and concepts. I would like to try to spot a few building blocks to get a better picture of the fertile ground where killer apps might grow, and perhaps we may – over time – learn how a potential killer app could look like.

Building blocks

With the rise of Bitcoin a much wider audience has been made aware of the power of cryptography. Not only Bitcoin but also other important achievements like PGP/GPG or Web Of Trust are becoming more accepted while they are being used more frequently.
Bitcoin, like many other relevant IT is standing on the shoulders of giants; most prominently the idea of Free and Open Source Software, a concept so fundamental and carrying such an importance that I believe we should add it to our list of crucial ingredients.
One of the most important properties of Bitcoin is censorship resistance – a property that is achieved through the adoption of a distributed network architecture. To avoid single points of failure not only on the technical layer but also in the way how the development is organized is crucial to fulfill that property. Maybe Satoshi’s vanishing was motivated to achieve that. The removal of the need for trusted third parties is another key accomplishment.
The solution to the double spend problem for digital currencies with the byzantine fault tolerant Blockchain technology was Satoshi Nakamoto’s major breakthrough. That is mandatory for a global ledger used for value representation, but we might find new applications in a wider space which do not have that strict requirement. Although DHT (Distributed Hash Table) networks generally lack byzantine fault tolerance they nonetheless represent a powerful and useful tool in combination with other means (like Bitcoin). Bisq is a child of such a combination.

The actual situation of privacy and data protection is a huge unsolved problem although many people are still not aware of that. I consider the usage of ubiquitous end-to-end encryption and technology helping to protect against surveillance of meta data like TOR crucial for the society and would not like to miss that in any emerging relevant technology.
This road does not stop at cryptography and software but needs to be extended to the physical network infrastructure (Mesh networks) and to open source hardware (Arduino).
3D printing and Maker Spaces depict other family members of our fertile ecosystem.

I don’t consider Internet of Things (IoT) as a building block for those kind of killer apps I am interested in. In fact, IoT will represent an enormous threat as long as security and privacy issues are not sufficiently addressed and solved.

Let us turn our perspective to a conceptual point of view:

The leap from a digital currency to voting is small and a few projects have already started to develop this space.
A digital currency or money more generally can be defined as a representation of value. Reputation, identity, registries, DNS, property rights or smart contracts are all applications, which can extend the usage of the Blockchain technology beyond the narrow notion of money.

Perhaps Bitcoin itself represents only a transition technology and other transformations of valuable information may evolve to become more important in future. It is not set in stone that a generalized value transfer system like today’s national money system depicts the ultimate solution. If the conversion of different forms of specialized moneys becomes near frictionless, money as we know it might become less relevant.

In addition, prediction markets are able to harvest the wisdom of crowds.
Delegative (or liquid) democracy platforms could serve as a tool empowering people to attain consensus in a much more efficient and fair way than it is accomplished today.

As technology reduces the need for human work we are ceaselessly heading towards a society where there will simply be not enough work for everyone. Work and financial income will have to be uncoupled to liberate humanity from inappropriate and pointless activities thus opening up a space for a currently untapped potential of creativity. An unconditional basic income might become an important enabler of these conditions.

What has that all to do with Greece?

While our world is facing tremendous, unsolved social, ecological and economic problems, it turned out that those whom we have put in charge of solving them, are a persistent unsolved problem by themselves. We use political structures created ages ago but they are not adequate to today’s situation, possibilities and challenges.

We have seen incredible progress in the scientific and technological world, but we seem to be stuck in the fields of politics and the way how our society is organized. We need new approaches to solve global threats never seen in history.

While we already hold some promising puzzle parts in our hands, most of them are still rather randomly distributed and lack important interconnections necessary for developing it’s full potential and sparking network effects. If we manage to combine them to create a fertile ground for growing and inspiring each other, we might be able to set new pillars for a new society – replacements for obsolete paradigms.

From some of the above (incomplete) list of technologies, tools and concepts we might see new applications changing fundamentally the reality we live in.

Those are the killer apps I am interested in – they might help us to not get killed by ourselves.

Share
Share
Share