Once upon a time, merchants would sit around an old tree to seek shade and, of course, trade.
Each merchant would sit with their back to the tree, looking out over the village square, and chatting with their clockwise and counter-clockwise neighbor. They can't see or directly communicate with anyone else around the tree, and don't trust anybody except their own immediate neighbors.
As the merchants tend to speak in whispers, none of them know exactly how many people are sitting around the tree, nor who the other merchants are, nor what trades they are discussing - except of course, for their own one-on-one conversations.
The Whispering Merchants problem is an abstraction of global trade in general, and arises as follows: each merchant only has an item to offer to their counter-clockwise neighbor, and only desires an item from their clockwise neighbor.
This creates a deadlock situation, since no two neighboring merchants can barter one-on-one. Some sort of financial technology will be needed, and the merchants start experimenting with different approaches.
How can each merchant obtain the item they desire from their clockwise neighbor, given that each merchant only has something to offer to their own counter-clockwise neighbor, and doesn't trust anybody except their own two immediate neighbors?
One optimistic merchant has an idea: he explains to his counter-clockwise neighbor that he is interested in an item from his own clockwise neighbor, and is willing to take a little risk, in everybody's benefit. He offers to lend the item he owns to his counter-clockwise neighbor, in the hope his neighbor would do the same, until his own clockwise neighbor has lent the item he wants to him. He promises his counter-clockwise neighbor to cancel the debt once all items have moved one position counter-clockwise, in the hope each merchant will do the same, and his own clockwise neighbor will also cancel his own debt. If this goes wrong at any point, and the wave of lending doesn't make it full-circle, the merchants can all just give the items back where they came from.
This system seems to work at first, until one merchant sees an opportunity to steal from a stranger. He quickly hides the item that was lent to him, and since his clockwise neighbor has no interest in reversing the deal he just made himself, the identity of the thief stays unknown to the victim, who is far away on the other side of the tree.
The merchants now realize that this system is very brittle, since it relies on transitivity of trust: even if your own counter-clockwise neighbor would never steal from you, and their counter-clockwise neighbor would never steal from them, this doesn't mean that this third person, to whom you are a stranger, can also be trusted not to steal from you.
Having learned from their first experiment, the merchants try out a different system. They realize that each of them likes gold, and gold is scarce. They decide to use gold as a currency. Each merchant offers the item they have for sale to their counter-clockwise neighbor in exchange for a grain of gold.
The merchants have invented money, which allows them to make local trades, exchanging an item for a grain of gold each time. The items all move one merchant counter-clockwise, as grains of gold are moved clockwise.
Although this seems to remove the problem of trusting strangers, in reality it has only shifted the trust problem. All merchants now have to trust the value of gold, and each merchant runs a risk that the gold loses value while they hold. More directly, each merchant needs to hope that they can receive the item they desire for at most the amount of gold which they can sell their own item for. If one merchant manages to obtain a high price for his item, it means the other merchants will collectively lose that same amount.
Instead of trusting the value of gold, the merchants could also trust the mayor of the town to provide issue notes that can be traded by the merchants. However, the value of these bank notes could fluctuate in the same way as the value of gold, and speculators could extract wealth from the village by trading the bank notes.
Network Money is a the concept of using peer-to-peer trustlines in a network. Each node holds only a local view of the network, and a snapshot of the entire ledger can only be created by summing up all the local views of all network nodes. This means Network Money systems are generally more scalable than blockchain/DLT systems. Instead of using a global consensus mechanism, hashlocks are used to split transactions into "hops". For instance, if Alice makes a transaction to Bob, it might go into the network ledger asd a chain of hops, Alice → X1, X1 → X2, X2 → Bob. Alice stores only the first hop, X1 stores the first and second hops, X2 stores the second and third hop, and Bob stores only the third hop. That way, each transaction is stored by two nodes. Summing up the three hops, which we can simplify as "(-A+X1)+(-X1+X2)+(-X2+B)" the X1 and X2 terms fall out of the equation, yielding the resulting multi-hop transaction "(-A+B)". Examples of other Network Money systems are Lightning and Interledger.
At the core of Network Money is the hashlock, which makes multi-hop transactions safe to execute at a distance, without having to trust the accounting skills of intermediate nodes.
Having seen both trust and money fail as systems for organizing trade around the tree, and thinking of how circular trade coordination is not much different from the core idea behind Network Money, one of the merchants invents LedgerLoops. What he does is actually quite simple: he tells his counter-clockwise neighbor: I will give you this item, but only if you can show me the solution of this hashlock. This hashlock is a cryptographic challenge which he knows only he can solve, but for which anyone could verify and agree whether a given solution is correct. Each merchant tells his counter-clockwise neighbor the same, until the initiator's own clockwise neighbor does so. Now that the initiator of the hashlocked loop has a promise from his clockwise neighbor, mentioning the hashlock he himself created, he can safely solve the hashlock and publish the solution. After this, the correct solution is sent back in the other direction, and all trades are completed.
To give a concrete example of how this would work, consider Abraham, Bethany, Chad and Dorus from Figure 1. Abraham has a banana to offer Bethany. Bethany has a carrot for Chad. Chad has a durian for Dorus. Dorus, in turn, has an apple to offer, in which Abraham is interested.
Abraham tells Bethany: "I will give you the banana if you show me the solution to the following hashlock: (includes details of the hashlock)". The challenge posed by a hashlock is finding a string that has a certain hash value when applying a one-way hash function to it. So to create a hashlock, Abraham could generate a random string, and keep this string secret, but include the SHA-256 hash value of the secret in the hashlock details.
Abraham knows that only he (holding the secret string) will be able to solve the hashlock, so making the conditional promise to Bethany is safe for him as long as nobody steals the secret string from him. He can be sure his promise to Bethany will be useless and without value unless he himself later decides to activate it, by publishing the solution to the hashlock.
Bethany thinks: if I can get the solution through Chad, then I can get the banana from Abraham. So she reuses the hashlock details received from Abraham, and promises to give Chad the carrot if he can show her a valid solution to this same hashlock. She cannot control when her promise will be triggered, but she knows that when this happens, she can also claim the banana, so that is a good deal for her.
Chad reuses the hashlock details he got from Bethany, and promises to give Dorus the durian if she can show him a valid solution to the hashlock.
Likewise, Dorus promises to give Abraham the apple if Abraham shows her the solution to the hashlock which she forwards from Chad.
And then, Abraham of course recognizes the hashlock details as his own! This is a hashlock to which he holds the solution, and although publishing his secret will probably cost him a banana, he is happy that the apple will be for him. So he publishes the solution by sending it to Dorus, and obtains his apple (this is step 2 in figure 3 below). The solution is now public, and Dorus forwards it to Chad to obtain her durian (3). Chad forwards the solution to Bethany to obtain the carrot (4). Bethany forwards the solution back to Abraham to obtain her banana (5).
During this process, only Abraham knows that he is the creator and solver of the hashlock; the other participants just forward the hashlock to their counter-clockwise neighbor, and a while later, forward the solution to their clockwise neighbor to obtain their own desired item.
The big advantage is that merchants now only have to trust their immediate neighbors. To take Chad as an example, he trusts Bethany to keep her promise about the carrot, and Dorus trusts him to deliver the durian. He knows there is a connection around the tree, linking his direct neighbors Bethany and Dorus to form a loop, but he does not know that Abraham is one of them, or that a person named Abraham even exists; there may just as well be zero or five merchants sitting between Chad's immediate neighbors.
All merchants are amazed at how it took them an entire week to come up with this solution, but are happy that they did now. They send the bankers away and shut down their crypto-currency computers. From now on, they use hashlocks to coordinate all their trades. And they live happily ever after...
Remember that money is used to decompose a flow of value into a chain of local transactions (see figure 2). When using money, each merchant participates in one purchase (giving money to their clockwise neighbor in exchange for an item), and one sale (obtaining money from their counter-clockwise neighbor in exchange for an item). Each merchant only accepts the money from their counter-clockwise neighbor because they hope their clockwise neighbor will probably accept this same money as a currency. But the value of money fluctuates, which means the use of money requires the merchant to make assumptions about the future behavior of people they don't really trust. Also, capitalistic growth causes inflation, which means money slowly loses its value if you possess it for any extended period of time without investing it.
LedgerLoops is an alternative solution to the Whispering Merchants problem, which does not rely on any globally coordinated currency. When the solution to the hashlock is passed around the tree, the solution allows each merchant to obtain one item, but the solution does not itself represent any value. The solution to a hashlock acts as a cryptographic trigger, not a cryptographic coin.
This means that LedgerLoops, as a financial technology, is not just an alternative money system. It proposes a more profound departure from money-as-we-know it, with a potentially more disruptive impact on the way assets change hands. It is an alternative to money altogether.
Suppose in the example above, Bethany disappears before Chad can claim his carrot. That means Chad loses out, but it does not affect Dorus. She was promised a durian by Chad, received it, and can keep it. She does not know who Bethany is, and although Chad's IOU was conditional on Dorus showing the solution to the hashlock, it was not conditional on anyone else's behavior. Abraham actually wins in this situation, because he already received his apple, but Bethany has disappeared and cannot claim her banana from him.
OK, but then, suppose Bethany receives the solution from Chad, quickly uses it to claim her banana, and then disappears. In this case, Bethany wins and Chad loses. Abraham as well as Dorus are unaffected by Bethany's behavior. Only Chad has put trust in Bethany, and he is the only one affected by her betrayal.
Now, let's suppose Abraham and Chad team together to try to rip off Bethany and Dorus. Wouldn't there be something they could do by secretly sharing the solution with each other? This is want I call a "figure-8 attack" in the security discussion (see page 15 of the whitepaper). It doesn't help Abraham and Chad to team together, because it would just reduce the square-shaped loop into two triangle-shaped loops.
What if I create a lot of malicious nodes in the network? That would only work insofar you can convince other nodes to trade with you. Users should be careful not to accept promises from imposters or strangers. They should only accept promises from their real-world friends.
What if I share the solution with more than one neighbor? Then I can claim more than one prize, right? Like, sort of double-spending? No, because you can only claim items from people who made a promise to you. And people will only make such a promise if a different promise was made to them first.
OK, but what if I just make lots of offers? That would be very generous of you, since all people you make a promise to have a chance of obtaining the solution once it is published, and they would all come knocking on your door. If you receive more than one promise then you're lucky, but you can't force your neighbors into making you offers they don't want to make.
For more security discussion, see the whitepaper (pdf). If you think you know of an attack that is not discussed there yet, please submit it to LedgerLoops whitepaper Github issues (or email michiel at unhosted dot org for responsibile disclosure of security bugs).
Conceptually, LedgerLoops as a technology sits somewhere inbetween blockchain and LETS systems. Its use of multilateral netting is similar to Ripple Classic and Trustlines Network, and its use of hashlocks is similar to Bitcoin Lightning and Interledger.
Unlike crypto-currencies, the LedgerLoops network does not facilitate payment. Instead, it aims to facilitate trade through multi-lateral barter rather than monetary payment. The hashlock solution that is passed around acts as a cryptographic trigger for trade, not as an asset that represents value. LedgerLoops is a communication mechanism that allows trade partners to enter into agreements with each other, conditionally on similar agreements being negotiated synchronously. Trade is facilitated without money is being transmitted, so users of LedgerLoops would arguably not need a money transmitter license. That said, you should always check and comply with the legal situation in your own country, and in any case, the trades that are coordinated using LedgerLoops would still be subject to value-added tax and income tax for the participants, like any other trades.
If someone tries to take a valuable item and offer only a much less valuable one, the loop will roll back, and no trade will occur. Still, this creates an incentive for each participant to try to make as much profit as possible, and could lead to a deadlock where none of the merchants is willing to cede their slice of the trade's profit.
In the current implementation, this issue is addressed by making neighbors agree on a unit of value, and an amount which should be the same for each item. That way, each participant can judge for themselves whether they are getting a fair deal.
In a future version, we plan to implement the idea of "Netting at Equilibrium", where merchants wait longer to settle a loop if they want to get a better exchange rate. That way, the merchant who is in the biggest hurry to settle the loop, has to "cross the spread", while ones who are willing to hold out for a better deal can essentially strike up a commission fee as local liquidity providers for their own neighbors.
In practice, not all people sit under trees; they probably buy items in supermarkets and sell services to their employer. A sudden transition from banking ledgers or crypto-currencies to LedgerLoops would therefore not be possible. But unlike for technologies like NFC payments or for newly introduced crypto-currencies, kickstarting a LedgerLoops network does not require global uptake; it can already be used meaningfully as soon as three or more people enter their peer-to-peer debts in a LedgerLoops-compatible software application.
LedgerLoops could be used among friends to split a dinner bill, or keep track of expenses in a shared house.
For instance, two friends could write down debts on a private ledgers, to decide whose turn it is to pick up the bill next time. A third person could be a friend in common, which would already give a minimal network of private ledgers. A debt loop involving three or more such private ledgers could then be resolved through LedgerLoops, without exposing the contents of each private ledger to the rest of the group of friends.
To make this more practical, a hackerspace could for instance start using a LedgerLoops-compatible application to collect its membership fees. The hackerspace could act as a "mini-bank" for its members, allowing them to trade services and items within their local community. Having well-connected hubs in the network makes it more likely that trade loops can be found and settled.
Banks could also offer LedgerLoops-compatible bank accounts, making it easier for their customers to trade with unbanked neighbors.
That way, loops could be routed partially through banks, so more people become connected with each other. Ultimately, LedgerLoops could then also be used for peer-to-peer transactions between people who were strangers to each other until one of them initiates the transaction, think: sharing economy, crowd-funding, charity, and micro-credit.
This is all still theory of course; the exact impact and application of LedgerLoops would have to be seen in practice, once we get the LedgerLoops software past the current testing stage.
Good question! :) In the real world, LedgerLoops was invented in October 2016 by Michiel de Jong, and is hereby published free of patents, under the CreativeCommons BY-SA license.
To read about the technical details of the LedgerLoops messaging protocol, including not only the hashlock and solution message format, but also a routing algorithm and security discussion, please download the LedgerLoops whitepaper (pdf). You can suggest improvements to the various sections of the whitepaper via GitHub.
In order to use LedgerLoops in practice, you will need software. Currently, the software is not ready for use yet, but we're running scalability tests with an early version of it. If you know how to clone a git repo and run a node script, you can try out the examples from the github repo.
Otherwise you can try out the latest build of our browser extension (Firefox coming soon, or for Chrome). and visit our WebMonetization demo to see how a blog could make money by accepting LedgerLoops donations.
The current development focus is on making the software more robust, and making the testnet more reliable. Since this software would be used to keep track of debts and balances, it would be very annoying if ledgers between neighbors would get out of sync due to a bug.
Development of LedgerLoops software (including reusable software components), is done via LedgerLoops on GitHub, and you can contribute there. We'll tweet from @LedgerLoops to announce when alpha/beta versions of software products become available, so follow @LedgerLoops on Twitter to stay up to date!
You're also welcome to build your own closed-source software and claim that it is "LedgerLoops-compatible", as long as you don't directly call your software "LedgerLoops". Since LedgerLoops is patent-free, anybody will be allowed to build LedgerLoops-compatible software without prior permission. We might create a test suite to certify compatibility, if people are interested in that.
I'm @michielbdejong on Twitter. Earlier work attempting to Redecentralize the Internet includes:
Thanks to the people who gave feedback on earlier drafts of this web page, you know who you are. :)