How two conflicting decisions unbalance Bitcoins’ design Two decisions underlying Bitcoin’s design — and indeed, all Blockchain based cryptocurrencies — tug in opposite direction. On one side we find the wish to distribute, on the other the need to access all transactions. This causes an internal strain that required considerable technical ingenuity to overcome, so as to make Bitcoin a more or less practical solution. Money is bookkeeping We know money as coins and bills. But most of the money in existence cannot be touched and has no weight. Think of your bank account. When you transfer a sum to someone else, basically the bank subtracts that sum from the number that represents the money you own ( your account) and adds it to the number that represents the receivers’ money ( his account). debits credits Such money is called . Your account is called a (your money is available on demand). Credit and debit actions are carried out together, preserving a balance, in what is called a . scriptural money [1] demand deposit transaction In an ideal world, where everybody would be perfectly honest, each person records his own mutations. A simple list of expenses and money received would do. Or, even better, an App with a local administration. When A pays x dollars to B, they contact each other through the App and the programs do the calculations, updating the records. In practice banks do the administration. We simply do not trust each other enough! And Apps with local administration can be easily hacked. Not to be confused with . The latter refers to money that has no intrinsic value (as opposed to golden coins, for example); the former (ie scriptural money) refers to its form: cash, or existing merely on the books. [1] fiat money Order of transactions Each mutation (debit or credit) must be performed on the outcome of the previous mutation. Mathematically this is not a requirement for any collection of mutations (6 + 3–1 has the same result as 3–1 + 6). However, as transactions flow in over time, one’s account may have negative value at a certain point in time (in the series 0–1 + 3 + 6 the end result is, again, 8, but after the first step we have -1). Depending on the arrangement between the bank and the account holder, negative value may be permitted to an extent (and at a cost!). Also, banks may perform transactions that come quickly after one another all at once, bypassing or ignoring negative value. This is of course equivalent to some reordering. n to n communication Any account holder may send or receive money from any other account holder. The bank has to provide a means for its account holders so they send their money to each other. When building an information infrastructure for n participants where everybody can, in principle, communicate with everybody else, one must create, again in principle, n * n-1 channels. That is a lot. We can save work by creating a central space with pigeon holes. Anyone wishing to send a message, leaves a note in the right pigeon hole. n pigeon holes instead of n * n-1 channels! Pigeon holes are a honeypot for the unscrupulous. That is exactly what a database is. A central store of the information that must be exchanged. Databases are a marvelous solution, but have their own problems. Such a collection of information is very attractive for those with more self-interest than scruples; Without extra provisions, everybody can read anything. A whole science has been established to ensure that what was collected, is separated again, neatly per person! A central store of information makes an organization vulnerable because all those involved can be hit by a single hack. By forcing communication from many quarters into the same structural straightjacket, is often compromised. meaning Central authority A database, as a central solution, is typically deployed by a central authority. In the case of scriptural money, this gives banks the opportunity (and obligation!) to enforce the right ordering of transactions (e.g. by refusing a withdrawal that exceeds the value in the account) that mutations are only carried out in correct transactions so the balance is preserved. Bitcoin Satoshi Nakomoto quite correctly noted that, with respect to money transfer over the internet, the grain of trust is too large and especially that this trust is too expensive. Micropayments are just not possible with transaction fees of twenty to thirty cents! And that while contemporary intensive cooperation and communication over the internet really needs micropayments in tiny fragments of cents. He attributed the cause of this situation to the monopoly of banks and the fact that payments are not irreversible. The bank should go! His famous Bitcoin is the result. One immediate consequence of removing the central authority is that there is no one to allow an account to have a negative value. This makes the requirement for ordering transactions so that each outcome is always positive, imperative. In an ideal world, we could distribute the bookkeeping entirely. In fact, this is what we do with cash! In a way, if you give me a ten dollar bill (which has no intrinsic value: it just value), I credit my wallet while you debit yours. represents However, in broad outline Nakomoto kept the database solution to the problem of n to n communication. His solution was to (rather than distribute it), meaning that copies of it could be anywhere on the internet. Each node holding a copy would perform a task similar to what the bank did before. Obviously, this requires some form of synchronization. decentralize the database Order of transactions Having multiple nodes duplicating the same work makes the ordering problem bigger. Transactions may arrive in different order at different nodes. Nodes will differ in their opinion of the state of the world because of that, making synchronization all the more difficult . [2] Timestamping transactions will not solve this problem. When a transaction arrives, how do you know if another will not arrive a little later but with an earlier timestamp? Nakomoto solved this by chaining transactions. Each transaction requires at least two previous transactions (one for each mutation). A previous transaction represents an account in a certain state (having a certain value). In fact, this is equivalent to creating a coin — especially in conjunction with the requirement that an account cannot have negative value . Chained transactions form a path for the ‘coin’ to follow. [3] There will be other causes of disagreement, but that is of no relevance here. [2] An interesting question one might want to ask is: have there ever been coins with negative value? One could transfer value with such coins: instead of receiving a positively valued coin, one would send a negatively valued one. At first sight one might think this would not work. No one in their right mind would want to hold on to such a coin! Losing them would be an easy way to get richer. [3] Double spending By hanging transactions off another, red spends the same coin twice. two Alas, with virtual coins the possibility of spending them twice comes into existence. In this case, double spending would occur if one could establish more than one transaction on a single origin transaction . [4] A person about to engage in a transaction would have to ensure that the transaction contributed by his partner had, in fact, not yet been used before. The obvious problem with this is: how does one know without trusting their partner? It is, in practice, impossible to consult all the other account holders! Suppose Red uses a previous transaction X that left his account with a value of 2. He spends these 2 bitcoins (transferring them to Blue) and then his account is 0. If he could use transaction X to spend money (e.g. transferring them to Green), it is as if his account had a starting value of 2! [4] again again The Closed World Assumption to the rescue! Nakomoto must have realized that by assuming that , the problem can be solved_._ Database science (and Artificial Intelligence) calls this the (Reiter, 1978). Everything in reality that is relevant, is available as information. Hence, if something is not described, it cannot exist in reality (or is unimportant). Absence of proof is proof of absence! all transactions ever carried out are in the database closed world assumption The Bitcoin Blockchain code applies the CWA and so can easily establish that a transaction T has no successor yet: if there is no transaction somewhere in the blocks that builds on T, T is available for use. One might ask: why trust that the Bitcoin database really holds all transactions? Well, it is in the to ensure that this happens. Without registration of a transaction that delivers coins, those coins might just as well not exist. receiving party’s interest Bitcoin is overkill The Bitcoin implementation does prevent double spending, but is far stronger than is needed. As a consequence, each node that processes transactions must have access to the entire database! To mitigate this problem, some ingenious solutions have been applied, such as Merkle Trees and Light Nodes. These, however, are not essential solutions of the requirement introduced by using the CWA. We see how Bitcoin is torn by two design decision that are mostly incompatible: one, to decentralize; two, to have access to all information. Resulting Bitcoin weaknesses Bitcoin inherits the problems of databases. The first three problems noted above all apply. First: the Bitcoin database should have huge attraction for those wishing to steal the coins. Nakomoto’s unique solution to this problem is what made Bitcoin and Blockchain famous in the first place. Second: without extra provisions, each user would have access to each other’s finances. The fascination in the Blockchain based cryptocurrency space with anonymity is caused by this problem. The third problem is unmitigated. A successful hack (or any other problem) would probably affect the entire community. The fourth problem, (meaning) does not apply because the represented part of reality (money) is universally understood. Bitcoin is flawed, not Blockchain It is important to realize that the force opposing decentralization is the CWA. Not all applications on Ethereum, for example, need the CWA. They consequently are not affected by the problem discussed in this paper. Beyond Bitcoin But surely, better solutions could exist? Nakomoto looked for a solution in decentralization. However, ironically, he stopped short of exploring the idea of decentralization . But databases are a to the n-to-n communication problem! Analysis of the double spending problem should look beyond the level of a database with the Closed World Assumption. beyond the level of the database centralized solution Why should we employ a database at all? Reconsider the CWA: everything in reality is available as information. All transactions are important, but not for everybody at any moment. The participants in a transaction with two previous transactions X and Y are only interested in possible successors to X and Y. Double spending will be prevented if they have access to . that is relevant, all transactions chained to X or Y Any technology that can guarantee precisely that, will be as safe as Bitcoin with regard to double spending, without the disadvantages. A peek into the future To get an idea on what such technology will look like, we must reconsider the original problem that was solved by employing a database: to create an information infrastructure for communication between n participants. Even though in theory everyone may want to communicate with everybody else, in practice this will not happen and certainly not at all the same time. As one example that quite conservatively explores the possibilities: the Iota tangle can be understood as a probabilistic approach to the CWA. No node will ever see all transactions, but the outcome of the double spending check should usually be equal to what would result if they did. Their approach reflects the insight that a shared database is not really necessary but still rests on thinking in terms of the CWA. Another, more promising idea — and more relevant to the present discussion — is that of the State Channel, because it focusses on communication between a restricted group of parties. In future posts we will delve into ideas that go beyond this.
