Pondering Codius - where the smart oracles live

Back in 2013 I attended the Ripple Developer Conference at Money2020. One of the interesting presentations that stood out to me was a discussion on smart contracts that would be able to make autonomous decisions and even pay for developers to improve their code.

Since that conference there has been a lot of more development in the space of smart contracts, especially if you look at Ethereum. However, one of the biggest obstacles limiting what a smart contract can do has always been the information it can use. To put it simply, smart contacts running on blockchains could only access data from within that blockchain, not from the Internet as a whole. This is to make sure those contracts are executed in a consistent manner at every machine - you couldn't for example have a contract checking the current Foreign Exchange rates online, since two different machines asking for the same information could get different data. Moreover, there is a question of security and preventing DDOS attacks - a script asking for a web page 1000 times executed at 1000 locations would result in a million page requests.

To address these issues, the concept of "smart oracles" came about. A smart oracle is a piece of software running on a machine that has access to both the blockchain data, as well as the real world data, and can interact freely between the two. You might have, for example, SatoshiDice checking the blockchain for transaction bets and evaluating them, or some bot that checks the current Bitcoin exchange rate and embeds it into the Bitcoin blockchain.

One of the projects offering a distributed platform for running smart oracles that inspired today's blog post is Codius. It's a project that grew out of the initial idea for smart contracts on the Ripple platform into what it is today. I would like to present to you some ideas of what could be built using that platform. But first, some assumptions.

Smart oracle assumptions

A useful smart oracle platform needs to offer the following functions:

• Make the code to be run verifiable and open - anyone interacting with the code needs to be able to make sure the proper code is running and it hasn't been tampered with
• Interact with both the Internet and the blockchains - this is needed to leverage the power of smart oracles over smart contracts
• The oracle needs to be able to keep some private data - whether it's private keys for signing transactions or other proprietary data, the oracles are more useful when they can store some data privately. Of course, the private data can be made public through proper function handlers
• In many cases, it is beneficial for multiple smart oracles to be run by different parties to ensure there is no collusion. Because of this, the platform running the oracles needs to be open source and not have proprietary code

Given those features, we can build some interesting projects...

Factom in a script

Since Factom is essentially just embedding information to be stored in the blockchain, it would be easy to setup some smart oracles where you can pay some money and have certain pieces of information embedded into the blockchain - whether it's hashes of proof of existence, or actual data like the current exchange rates, it doesn't matter much. Having more than one oracle communicating on what data to embed can also be useful to make sure no single party is manipulating the data.

Coin to Crypto 2.0 gateways

In the Crypto 2.0 space, there is a need for efficient, cheap and secure gateways between the various coins and the 2.0 system. Most of those gateways are currently run by centralized parties, but with smart oracles you could easily reinvent that model and run it on a few smart oracles.

Distributed gambling

Smart oracles could serve as an interesting platform for betting and gambling. Users would be able to register and gamble with the oracles against one another, real-world events, or against the house, which can also be run by the oracles in a fashion similar to JustDice. 

Distributed messaging

Since the oracles would be able to store private data, anyone would be able to send messages to be stored on multiple oracles that can later be retrieved by the intended recipient. This communication could be end-to-end encrypted, and since it wouldn't reside on a single server, it could be more robust than a lot of networks.

Arbitraging bots

A lot of exchanges (centralized or distributed) benefit from initial market liquidity bootstrapping that can be achieved through the use of bots. Those bots are usually tasked on copying the market from an existing exchange onto the new one and locking in any trades that might take place. Moreover, there is even more benefit if there is competition in this space - having multiple parties competing with one another to provide the best rates stimulate activity, as well as make the market more competitive. If an exchange that needed liquidity would provide smart oracle code for anyone to easily deploy and run on Codius with tweakable parameters, they could quickly see a lot of amateur market makers provide them with a competitive market on their platform. Similarly, the same could be done on a 2.0 platform with a decentralized exchange like Ripple.

In this example, the smart oracles are mainly used as cheap, 24/7 hosting platforms.

Timed releases of secret information

Through the use of encryption and Shamir's Secret Sharing, smart oracles could be programmed to release the decryption keys for various files or documents at a given point in the future. Even if some of them went down or did not release the keys, the secrets could still be revealed if the minimum threshold was reached. This could be used for example by provably fair gambling platforms releasing their secret seeds at a predictable time in the future.

Economic contracts

There is a lot of need for various economic contracts out there, and a lot of them rely on some external data, such as the current exchange rate, being fed in. Smart oracles could not only facilitate the proper data being verifiably embedded into the blockchain, but also execute the smart contracts as desired in an objective fashion.

And many more...

There are many other ways one can use smart oracles, ranging from simple servers running scripts on one end, through embedding data into the blockchain, down to leveraging both the cryptocurrencies and data from the real world. The main advantage of using oracles over traditional servers is that a lot more of them can be deployed at the same time, and the same script can be easily executed by multiple parties, therefore minimizing the risk of malicious behavior.

Shipping without incentives and features

Recently I was doing some research into Factom, a new project that aims to embed a lot of data into the Bitcoin blockchain and create a "proof of existence as a service", among other things. I stumbled upon some criticisms of the software (Google Cache link, as the original was taken down). One of the crucial features missing from the Factom code at the current time appears to be the lack of incentive for nodes to store any data after it is embedded into the Bitcoin blockchain. Pondering this for awhile, a few similar issues with other systems came to mind, and thus I'm writing this blog entry on various Bitcoin-related software that launched without some important features or incentives.

"Convenient bugs and arbitrary features" is also a recommended reading related to this topic.

Red balloons - Bitcoin is not without its flaws

When I was doing research for my master thesis on Bitcoin, some researchers from Microsoft and Cornell University released a paper called On Bitcoin and Red Balloons, where they pointed out the Bitcoin nodes have no incentive to propagate transaction information through the network, and miners have all the incentive to actively withhold that information.

The gist of the research is that while anyone creating a transaction has the incentive to propagate it through the network (they want the transaction to be put in a block, so they spread it to everyone), miners have the incentive to include paid transactions into blocks (to earn fees), Bitcoin nodes have no incentive to relay the transaction information. They are not getting paid to do so, nor do they benefit from the transactions they transmit directly. Moreover, if a miner knows of a transaction with a fee, they benefit from not broadcasting it - this way it is less likely to be mined by their competitors and they are more likely to earn that particular transaction fee.

One can argue, however, that every business built on top of Bitcoin has the incentive to run a full node that relays all the information. While they don't benefit directly, the abundance of full nodes makes the network more resilient to attacks and more distributed. What benefits the community at large is also beneficial to the individuals in some way.

Mastercoin - a token without a purpose

Back in the day when Mastercoin launched (and has since re-branded into Omni), my biggest question surrounding this technology was - "what are mastercoins used for?". In the Bitcoin space, you would use bitcoins to pay the transaction fees. In the Mastercoin space, well, there wasn't a clear use for mastercoins. Sure, the project itself benefited from the crowdsale to fund the development of the protocol, and some people earned some pretty penny speculating on the price of the coins, but there was no immediate use for the tokens themselves. There were no mastercoin-denominated fees in the system, the transactions instead paid the standard Bitcoin transaction fees. Only much later did the developers include a clear use case for the tokens - to burn them for crowdsales. A little bit of an arbitrary feature in my opinion, but at least it is some feature.

Ripple validators - a big burden with no reward

In a similar vein to Bitcoin's lack of incentives for running full nodes, the Ripple network provides no incentive for network validators. A validator is similar to a miner on the Bitcoin network - they process all the transactions taking place on the network and create new ledgers. While mining bitcoins is a computationally-intensive task due to proof of work, the Ripple network is more heavy on the disk space (full network history taking up 100-500GB of data at the moment).

Unlike Bitcoin however, Ripple fees are not paid to the miners / validators, they are instead burned. Similarly, Ripple has no coin distribution schedule - all the XRPs have been created in the genesis ledger. This leaves validators with no incentive for a potentially burdensome effort (most of them are currently run by Ripple Labs last I heard).

There are two approaches to solving this issue however. One is the idea that the Ripple gateways should also run validators, as they are the ones earning the most money from the network operating. The second approach could build on top of Stellar's token creation - the validators can be compensated by the users of the networks for their contributions with newly minted stellars.

Factom - pay to save, never load

As mentioned in the opening paragraph, it appears that the Factom network allows its users to save any pieces of information into the network for a fee, but fetching the data in the future carries no cost and thus no reward for the nodes to carry out that request. If someone decided to abuse the network, they could try flooding it with a lot of requests similar to a denial of service attack - honest nodes would be overburdened with having to provide a lot of data, while lazy nodes that wouldn't even attempt to provide the information would be better off.

As such, it appears that the Factom network will need to expand its fee and reward structure to provide incentives for nodes to store information as long as it is useful, similar to how MaidSafe is supposed to work.

Branded coins - start with a purpose

I heard a few similar pitches - a company wants to release a new, branded coin and tie it to their service. They usually have some grand vision of how everyone will want to use their coin since they will be able to spend it in their system and pay anyone just as easily as they do with Bitcoin. Sometimes it's customer rewards for shopping, sometimes it's some coin to raise brand awareness. However, quite often such pitches lack one crucial thing - why would anyone want to use the branded coin over Bitcoin? If you say, have a payment processor that accepts Bitcoin and their branded coin, I personally see no reason to use the branded coin over Bitcoin, nor to hold it any longer than it takes to convert it back into BTC. Even the usefulness of presale tokens can sometimes be dubious.

In the end, a branded coin needs to serve some purpose other than just existing for the sake of it.

Conclusions

There have been a lot of projects in the past that have launched without all the necessary features or without proper incentives to support all of the functionality. While we can expect some level of altruistic behaviour from the people running the software, a well-run system shouldn't rely on altruism alone - either you pay to use the resource, or you lose it.

Specialists, not generalists - the upcoming service fragmentation in the 2.0 world

I am a strong believer in the Crypto 2.0 space. I see the world heading towards the Singularity of Money, where the currency we transact in won't matter as much as the value of that currency. Today, I would like to share with you my thoughts on how various services we know from the Bitcoin ecosystem might look in the "2.0 world".

Exchanges turning into gateways

In the current model, we have a lot of Bitcoin exchanges. Everyone is trading their local currencies to and from Bitcoin. Because of this, every exchange has to fulfil a few roles:

• Verify customer identity
• Onboard and offboard both Bitcoin and fiat
• Securely store both Bitcoin and fiat
• Facilitate trades through its trading engine
• Usually provide some open API for automatic trading

If the exchange fails on one of those aspects, they are essentially out of business - an exchange with a crappy trading engine is no good, neither is one that can't hold its BTC balance. Because of this, building an exchange is no easy task - you have to be proficient at all parts of your business.

Now, in the 2.0 world, a great deal of what an exchange does can be fragmented using the gateway model. Instead of dealing with everything, a gateway can focus on handling one part really well. We can have a gateway that handles only Bitcoin (onboarding, offboarding and securely storing BTC), and a separate gateway that handles only one fiat currency. Neither of them have to worry about holding more than one currency they know how to handle, and neither of them has to build any trade engine - that is either provided by the 2.0 system itself (like Ripple), or can be built separately.

Once we have a gateway for a given currency, that currency can be traded for anything else on the system - BTC for USD, CAD for EUR, gold for oil or whatever else you want. The market will decide what it wants to trade, and all the gateways need to do is provide IOUs for their currencies or commodities of choice.

Lastly, good money will drive out bad money - if a gateway is involved in some shady dealings (like MtGox in the exchange space), their IOUs will devalue quickly for everyone to see. In contrast, good and diligent gateways will secure the value of their IOUs. As nobody wants to hold inferior money, people will flock to the good gateways, leaving the bad ones in a subversion of Gresham's law.

All in all, in the Crypto 2.0 world we will see the rise in importance of gateways and a diminished need for exchanges.

Currency-agnostic exchanges

Even though we will move away from the current proliferation of exchanges, there will still be a market for high-performance currency-agnostic exchanges. Usually the first place to trade IOUs from gateways will be the 2.0 system they are issued on - be it Ripple, Omni, NXT or something else. Since those are distributed exchanges, they can only settle so many trades and work so fast - a trade on Ripple might clear in 5 seconds, while a trade on Coutnerparty might take 10 minutes on average. There are some applications where you need to achieve higher speeds and transaction volume, and that's where we can see the rise of high-performance currency-agnostic exchanges.

The exchanges built on the 2.0 systems can be quite different from what we see today. They might only take one settlement method - the 2.0 network they are connected to, but would accept any number of supported currencies from that network. For example, we could have a Ripple-powered exchange that accepted BitStamp.USD, SnapSwap.EUR, as well as DYM - the silver dimes. Once the deposits are settled, the exchange users can trade them away using the high-performance trading engine. Once all the trades are settled, the withdrawals would similarly take place through the 2.0 network.

In general, while we might see the decline in the number of exchanges, we will also see the rise of high-performance currency-agnostic exchanges.

Market makers

Similarly to how we currently have traders going into multiple exchanges and copying the market between one platform onto another in hopes of locking in some profit, we will see the rise of importance of market makers in the Crypto 2.0 space. Both the distributed exchanges living in the 2.0 systems and the various currency-agnostic exchanges will need liquidity from many markets. Since we will be dealing with a lot more currency pairs than just everything-to-BTC, we can see people copying the stock market, FX market, as well as copying the existing liquidity from Bitcoin and altcoin exchanges. Efficient market makers will get their trades and earn money, thus creating an incentive for many parties to compete and bring everyone the most competitive prices. Thanks to that, everyone will be able to get an FX rate for their currency conversion, rather than relying on "spot +-3%" usually offered by the banks.

In the 2.0 world, we will see a number of market makers copying the liquidity from the old world into the new.

Bridges between worlds

Built either as part of the gateways, or perhaps as standalone services akin to ShapeShift, the 2.0 world will be connected to both the "old world" as well as between the various 2.0 systems through the use of bridges. A bridge in this context is a service that provides onboarding and offboarding between various systems in a convenient fashion. For example, if I go into the RippleTrade wallet (a wallet handling only Ripple) and decide to make a transfer from my account into a Bitcoin address, the wallet will figure out how to pay the recipient, even though they are on a completely different network:

Bitcoin bridge from Ripple

One can imagine the same bridge functionality for any other system - SEPA, PayPal, etc.

All in all, in the spirit of the Singularity of Money, we will see a lot more bridges connecting various systems together.

Currency-agnostic services

Just like with exchanges, the current model for services usually ties them down to a single currency. For example, we see Bitcoin-only payment processors like BitPay, Bitcoin-only ATMs like Lamassu, and Bitcoin-only wallets like Blockchain.info's wallet. In the 2.0 world, we will most likely see a lot of services become more currency-agnostic (like say, CoinPayments to BitPay).

All of the services will focus on what they do best while letting everyone else focus on their strengths. Lamassu might decide that it is really good at handling cash, and instead of also converting the cash into Bitcoin, it might either pay its customers directly in fiat IOUs from a gateway (USD cash in, BitStamp.USD IOU out for example), or perhaps use ShapeShift or other dedicated high-performance currency conversion tool to pay its customers in any currency converted on the spot through open APIs.

There is a lot of room for many companies to redefine themselves when transitioning from the Crypto 1.0 world into the Crypto 2.0 world to benefit from the network effect. In the end, if you can do something better than everyone else, you can still be in business letting everyone tap into your strengths as long as you separate them from your weaker points.

In the 2.0 world, a lot of services will focus on the service they offer, not the currency they use.

The connectors - putting it all together

The last important part of the transition into the 2.0 world will be the connectors - services that bring everything together and form a coherent user experience. Instead of going to all the services separately and managing everything yourself, you are very likely to see some user-focused all-in-one services. They might take a form of a currency-agnostic wallet that automatically connects you with all of the gateways to let you receive any currency you want, uses the bridges to deliver your money where it needs to go, perhaps even has some built-in handles into an exchange to allow you to trade on the FX market.

If the 2.0 world is ever to be mass-adopted, it will require a user-friendly layer that connects everything together.

Conclusions

When we transition into the Crypto 2.0 world, we are more likely to see more specialists, not generalists. Every service will have to re-examine their strengths to build on and weaknesses to move away from. This works similarly to the Principle of Comparative Advantage - even if you can do everything better than everyone else, focusing on your few key strengths and letting everyone else focus on their strengths might be better overall:

60 Second Adventures in Economics - The Principle of Comparative Advantage

So, does your company have a Crypto 2.0 roadmap yet?

Vanity Pool - the geekiest service in Bitcoin

Bitcoin is the money system of geeks. While you don't need to be one to use it nowadays, it is still undeniably complex. The way it uses cryptography to securely move funds around can only be fully understood by computer scientists.

Now, take this geeky technology and try finding some more niche appeal. We have technologies like Factom embedding data into the blockchain, SatoshiDice using transaction hashes as gambling randomness and so on. However, I do believe that one of my projects is perhaps the geekiest service in Bitcoin ;).

But first, some theory.

Vanity Addresses

Just like some cars have vanity plates, so can Bitcoin. While some people are satisfied riding in their Bitcoin Priuses:

Bitcoin Prius

some of us want to create some nice flairs for our wallets. While it's easy to create an invalid Bitcoin address with any text (such as 1Piachuxxxxxxxxxxxxxxxxxxxy3XorwA), it takes a lot more effort to actually generate an address you can import into a wallet and spend (like 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm). Normally this process would involve generating a lot of addresses and looking for your desired pattern. It is somewhat manageable with GPUs (especially in the pre-ASIC era of GPU mining), a lot of people didn't have the necessary hardware to perform this operation.

Back in the day, those people would result in having to trust someone to generate their key for them and not steal their money in the future. In the Bitcoin world, having to trust someone with your private key is unacceptable, but luckily, the laws of mathematics gave us a solution!

Split-key vanity addresses

Now, things are getting a bit complicated, but I'll try to keep it as simple as possible. If things get too complicated, feel free to skip to next heading.

Bitcoin private keys are essentially really large numbers (lets call it A). Bitcoin public keys are those large numbers multiplied by a Generator (essentially a point in space), which give you your public key point:

A * G = AG

A - private key
G - Generator
AG - public key

Everyone that sends you money knows your AG, but since division in this math space is impossible, they will never guess your private key A from it. All public keys easily map to Bitcoin addresses.

Now, lets say we have another private key B. The following equations hold in the Bitcoin space:

(A+B) * G = AG + AB
A * B * G = AG * B

This means that if you add two private keys, the public key of the sum is identical to if you would have added the public keys together. Same thing with multiplication.

Now, what are the practical uses of this? There are some uses for combining addresses for storing money (especially in pre-multisig era), but the use I want to talk to you about is Vanity Address Mining.

Vanity Address Mining

Given everything explained in the previous heading, we solved our privacy issue from before. Now we have a way to have someone generate us a private key without them knowing our private key. The only information they need is our public key and the pattern we want. They generate us a private key that we combine with our own private key, and we get our vanity address. Because our private key was always secure, we can be certain only we know the private key.

Now, given that the users request vanity addresses with information that can be shared publicly and vanity miners submit results that can also be publicly broadcast, we can start connecting the two in a more methodical fashion without any special concerns for privacy. And this is a role for...

Vanity Pool

Vanity Pool is a service I created a few years ago to leverage the split-key address creation in the business of vanity address mining. Anyone can go onto the website, request any reasonable vanity pattern to be mined, pay the fee and let the miners do the work for them. The miners would query all the available work and start mining the addresses one by one until they find a solution and cash it in.

Since the service launched, it had helped many people create addresses for themselves and their businesses. Yours can be next! ;)

As it stands, Vanity Pool is one of the geekiest services in Bitcoin. It not only leverages clever cryptographic tricks, has its own mining ecosystem, but also does all of that in a provably secure manner. No private keys are ever exposed.

Conclusions

Vanity Pool is a geeky Bitcoin service that uses ECDSA math in a clever way ;).

Trust-based currencies - good money, bad money, LETS, Ripple, etc.

This week at Decentral Vancouver we had a discussion with Michael Linton and Dominique Legault from Open Money about the LETS (full recording). LETS, or Local Exchange Trading System is essentially a community-run non-for-profit system for recording transactions, often using a form of a local currency. During the discussion various comparisons to the current Crypto 2.0 systems came up, along with some debate whether local currencies in general are good for us. Let us dive into these topics deeper.

Trust-based systems - explanation

Trust-based systems can be defined as a monetary system based on currencies requiring a trust that other parties won't default on their obligations. Examples of such systems include banks, gift cards, debt, as well as the aforementioned LETS, Ripple (minus the XRP portion) and Open Transactions. Counterexamples are currencies where you directly control the monetary asset transacted in, such as barter, gold or Bitcoin.

All trust-based systems can be boiled down to managing Trust and Debt:

Trust and Debt in Ripple Trade wallet

Trust is the limit of how one person is willing to have the other person owe them, while Debt is the current amount owed. So if I Trust BitStamp for $100, I am willing to hold up to $100 of their Debt before they won't be able to send me any more money. If I hold $10 in balance from BitStamp, they are $10 in Debt.

These simple relations are pretty much how all of the modern banking works. A savings account is you Trusting the bank and them being in Debt to you at your current balance. A credit card is the bank Trusting you, and the amount you charge onto the card is how much in Debt you are to the bank. If I send money from my account to yours, bank's Debt to me is reduced, and it is increased for you.

Based on how Trust is placed, we can have 3 different systems - centralized, decentralized, and distributed:

A centralized system is like a government issuing a currency - everyone in the given country is obliged to trust it and use it. The world economy is a decentralized system - every government issues their own currency, most people use one currency, but there is some connection between the systems. Local network of interpersonal debt ("I owe you $5 for the drink last night") is a distributed system.

All of the trust-based systems can take a form of any of the three systems. Currently, Ripple Classic and LETS are more focused on the distributed model, while Ripple and its gateways are focusing on the decentralized approach.

Decentralized vs Distributed model

As the centralized model is pretty similar with decentralized model, I will omit it and discuss the other two models.

From a practical perspective, you will most likely have some combination of a distributed and decentralized model in your trust-based system.

The distributed model appears to be more useful when "liquidity" is scarce and there are more direct interactions on a community level. For example, if you have two people with no cash on hand that are capable of working for $10/hour, under the centralized or decentralized model they wouldn't be able to do anything because they wouldn't be able to pay one another. Under the distributed model, they can still work by tracking how much they each owe one another and settling the difference in kind. Similarly, the debt could be exchanged in a web of trust in the local community for different goods and services.

The decentralized model appears to be more useful when parties don't trust one another, but can trust some third party. For example, a person selling a $100k house might not want to trust a stranger to repay the debt over many years, but would be more willing to trust a bank or similarly large institution. This model is also useful for trade outside of your circle of friends as it reduces complexity. Sending money overseas in a decentralized model means going from you, to your bank, to recipient's bank, and to them, rather than possibly funnelling through a network of many people.

Good money vs bad money

Gresham's law is commonly stated as "bad money drives out good money". It is often mentioned in context of money's nominal value (how much value is printed on the bill or coin) and its commodity value (how much the raw cotton or metal used to make the money is worth). To put it simply, people would value a silver dollar coin more than a dollar bill due to the metal, and as such would first spend the dollar bill.

When talking about trust-based money, the same issue comes up in a more interesting way. Say we have a local community money like SeedStock and a government-backed Canadian Dollar. If we have an inefficient market (it is hard to trade SeedStock for CAD), people might value SeedStock roughly around 1SS=1CAD and use them interchangeably as needed on the local level. The trades would obey Gresham's law and SeedStock should be spent first.

However, if we have an efficient market (trading between the currencies is instant and on the fly), we would discover the true value of SeedStock. Perhaps it would turn out 1SS is only worth 50 cents since too few places accept it, or maybe it's a more optimistic 95 cents. Whatever the value would settle at, that should be an equilibrium at which people would be just as willing to spend SeedStock as they would spend Canadian Dollars.

A practical example of this would be what PurseIO does - as it turns out, Amazon gift cards are worth about 80% of their face value when used to purchase Bitcoin.

Back to our systems - it is very likely that local currencies from the distributed model will turn out to be "bad money" (or at least worse than the alternative), while the money from big, decentralized gateways will act like "good money". The good money will probably also be used as a measurement of value, even when bad money will be used as settlement (I owe you $10 worth of my labour).

If we have an efficient market, no merchant will be interested in taking settlement in any bad money other than the one they issued themselves - if they can receive 10CAD or 10CAD worth of SeedStock, unless they need SeedStock directly, they would rather hold the good money. This would work until the entire market would either dry up or become inefficient, in which case there would still be a use for bad money to facilitate trade.

LETS - how does it fit in?

During our discussion at Decentral Vancouver, Michael Linton was arguing that local currencies in the LETSystem are needed to keep the local economy from drying up. We can illustrate the local trust-debt relations as:

However, no matter what currencies we are using, there will always be a need for transactions between the communities in the modern world. Unless the system is hindered by not being able to trade between the currencies, those currencies will be traded and some exchange rate between them will be established. Just like with the modern world - whether what one community supplies is valued higher or lower will determine the exchange rate until there is some price equilibrium (say, if oil is 10% cheaper to buy and import from US than to buy locally in Canada, the economic system based only on that should value CAD at 10% discount until it is just as cheap to buy and import than to buy locally).

As such, the LETSystem is fine in allowing communities to issue their own currencies, but hearing the technical explanations, it appears inferior to Open Transactions and Ripple. Both Open Transactions and LETS were built for local pockets of transactions between individuals that were checked and validated by a third party (a notary for example). Communicating between the local instances is more of a problem in both systems. If that is an important feature of a system, Ripple is more suited for the task, provided you are willing to sacrifice privacy for transparency.

Conclusions

The LETSystem has definitely influenced many developments in the trust-based currency system for over 30 years of its existence. The decentralized and distributed currencies appear to be complimenting one another - one working better on a local scale and when liquidity is scarce, and the other one when there is less trust between the parties.