VS and OT

Note: this article was stimulated by a presentation given by Fellow Traveler (the principal developer of OpenTransactions) at the recent North American Bitcoin Conference. You can view his presentation here. General information about the architecture of Voucher-Safe can be found on the dev site in the Wiki section.

Cousins Raised in Different Households

The VS core technology was designed and implemented between 2008 and 2010. I know from Fellow Traveler himself that when he began work on OT in 2010, he took a close look at VS, and its design influenced his thinking significantly. However it would be a mistake to assume that VS is simply a prototype upon which OT drew for inspiration. As OT nears commercial deployment, both can be seen as related technologies which made some different design decisions during development. So, less closely related than Bitcoin to an alt-coin, but with more in common with one another than either has with Ripple, let alone the previous generation of website-centered payment systems such as e-gold, Liberty Reserve, Pecunix, PerfectMoney, Sovereign Exchange, etc. Here are some points of comparison to examine in more detail:

  1. FT rightly concludes that servers do things which the crypto-coin ecosystem obviously needs, else why would people be building them all over the place? (See also my previous article critiquing the Bitcoin protocol for more on the implicitly centralizing tendencies of "decentralized" payment systems.) He also rightly identifies that servers suffer from “single point of failure” syndrome, and that therefore we must eliminate any need to trust them. In the VS architecture, the Voucher Publisher (VP) is most analogous to an OT server, and performs the “notary” function of instantly clearing transactions. However a VP only signs vouchers, not transactions. Therefore not only is a VP unable to change a user's ledger balance, but it cannot even determine that balance. The “ledger balance” in a VS wallet is simply the aggregate of the individual signed vouchers encrypted with that wallet's public key. There are no accounts, only vouchers. The VP only knows about vouchers which are decrypted by the wallet and handed to it in the context of a transaction. Transaction receipts are signed only by the payee. This provides a level of protection for the VP, in that it could not (for example) give any meaningful response to a subpoena for user balances or transaction history. Unfortunately it appears that an OT server could; in fact it would be impossible to deny any transaction or balance, since they are all counter-signed with the server's private key! This implies that OT users are still trusting the operator(s) of the server.
  2. The VS architecture extends the “trust no one” concept even farther, by breaking up the “server” into four distinct components: the VP, the SDS (Secure Data Store), the DHT (Distributed Hash Table), and the PKS (Public Key Server). The VP is the transaction notary, which signs vouchers and tokens, communicates with voucher currency Issuers to prevent double-spending, and stores encrypted records on the other components. The SDS provides permanent cloud storage for vouchers, receipts, login credentials, and other wallet data. The DHT provides temporary storage for payment notifications and receipts. The PKS stores wallet public key certificates (signed by the VP). All data stored on the subsidiary servers is encrypted, and opaque to those servers. This extends the “no-trust” model by preventing the VP from acting as the monolithic custodian of all customer wallet data, as appears to be the case with OT. It also allows for geographic distribution of the server components. OT achieves distribution by cloning and then “federating” the servers. (I can imagine that doing this might create server synchronization issues, though how these are addressed is not a topic FT gets into.)
  3. The public keys for all VS wallets, as well as those of the VP and integrated exchanges and marketplaces (i.e. the SVX & SVM), are stored on a PKS. (The PKS can be replicated safely; but for reasons of synchronicity each VP supports only one SDS or DHT.) This achieves the same goal as OT's Namecoin/Certificate Authority layer, but with a lot less fuss. The VP is the logical CA, which signs wallet certificates. Wallets can fetch one another's certs and validate them using the VP's pubkey. This also allows something Bitcoin wallets (and maybe OT wallets too) do not support: the ability for a user to “close” their wallet. This prevents future spends from being made to it, due to the presence of its pubkey on a CRL (cert revocation list), also maintained on the PKS. Public keys are used to encrypt all p2p messages on top of the XMPP transport layer (which is already encrypted).
  4. When a VS payment is made, two steps must occur: first the payment is sent by the payer, and then it is received by the payee. If the latter step does not occur within the 1-7 days stipulated by the payer, then the payment becomes indefinitely reclaimable by the payer. This effectively makes it impossible to execute a spend to a “dead wallet” (although a mistaken spend could still occur). This is an important feature for any payment system to support when spends are otherwise irrevocable. I could be mistaken as to the details, but I believe that an OT server records completed spends on its ledger for both accounts, making them final. I assume this because it relies on a “last-signed receipt” model to determine the current balance. (FT specifically states that all previous receipts could be thrown away without harm, suggesting that previously cleared transactions cannot be undone; and spends are said to be irreversible.)
  5. The VS architecture includes integrated “gateways” (one or more) which route traffic between user wallet clients and the VP (and likewise to an exchange or marketplace). This means that a VP never sees a user's IP address, and it allows gateway servers to be franchised and exist in a many-to-many mapping with VPs. The login protocol is designed in such a way that a gateway (OFS) cannot tell which wallet a user is accessing, and end-to-end encryption forestalls any effort at eavesdropping by a compromised gateway. Deploying gateways also allows for geographic distribution of access points into the network. Once a user client has authenticated, it requests network discovery from the gateway, which responds with a network config block signed by the VP. This block contains the public access coordinates for the VP's SDS, DHT, and PKSen. This allows the VP to control this configuration, without needing to trust the gateways for it. Pre-login discovery reveals the list of VPs, SVXen, or SVMs accessible from the gateway. I have seen nothing to suggest that OT clients do not connect to their servers directly, nor anything describing how they discover the current authenticated server list. "Network disco" however is a standard function in XMPP when connecting to a server.
  6. As a further firewall, even the gateways are now connected to via PageKites. A PageKite “front end” runs on a public domain server, such as silentvault.com. A PageKite “back end” establishes an outbound connection to the front end. The two ends then pass user traffic in both directions over an encrypted HTTP proxy, which the back-end forwards to the IP of the actual server (VP, SDS, etc.) The effect of this is that there is no configuration data on the public web server which could identify the IP of the back end, let alone the server. This firewall level, along with the VP proxy gateway designed into VS from the start, is absolutely critical for the “no trust” model: one has to be able to trust that the server itself is as well protected from domain seizure or location identification through traffic analysis as humanly possible. That's certainly true for VS servers.
  7. While OT apparently relies on its own unique protocol for client communications (as does Bitcoin), the VS network communicates on top of Jabber/XMPP, using private extensions to a widely used protocol which has already been extended successfully to do a surprising variety of tasks. This confers a few benefits: it's standards-based, and can therefore leverage existing infrastructure and code libraries; it helps defeat detection of the protocol's use through “hiding in plain sight” amid ordinary instant messaging traffic; it provides legal censorship resistance by transforming economic transactions into a form of free speech indistinguishable from other protected forms of speech; and it can leverage all the existing mechanisms of a robust communications protocol to let users text chat, voice chat, share files, and do everything else which XMPP already supports. It's much easier to embody the VS wallet client as a plugin for a Jabber client (this has been done), than to replicate portions of Jabber inside a wallet client, as OT will need to do (and as KryptoKit and Gliph are doing). Those who do not understand Jabber will be condemned to reinvent it — probably poorly.
  8. The OT design federates servers and marketplaces. The VS model is to franchise them. That is, there can be multiple Voucher Publishers each with their own network and list of currency Issuers (which lists could overlap). Similarly an SDS or DHT or proxy gateway operator could contract to provide services to one or more VPs. Each component (except a PKS) is paid in tokens (micro-vouchers) for storing records. This provides direct economic incentive to provision servers in the best possible locations, with maximum protections in place. This stands in complete contrast to TOR exit nodes or BitTorrent seeders, for example, for which no inherent compensation commensurate with risk exists.
  9. The “colored coins” layer is obviated by the VS architecture, because all assets are inherently represented as “vouchers,” cryptographically signed pieces of XML. However, an asset Issuer which was also deployed on a block chain (perhaps for reasons of transparency) is entirely possible. This issue is properly pushed down the stack to the Issuer side. Everything FT said about market makers, agents, KYC, etc., in respect of currency issuers applies to VS voucher Issuers as well.
  10. The VS wallet client is already beta tested, and in the third generation of its UI. It's considerably more compact and IMHO looks a lot better and already has all the helpful tooltips etc., as compared with the current OT/Monetas client — which is itself a vast improvement over the Bitcoin-Qt client. (You can see the Monetas GUI client demonstrated here and here.) The VS servers have been stress-tested using cloud client simulators, and can support a load comparable to the max rate of transactions on the bitcoin network (which is roughly 7 TPS). Unlike with Bitcoin, additional hardware deployment would increase this linearly.
  11. The SVX (exchange) is already built into the Silent-Vault VS wallet. The intent here is that the SVX code (it's a server plugin) will ultimately be published, and operated for profit by multiple parties at competitive rates. It wasn't clear how OT plans to roll out marketplaces, though the capability of doing searches across all markets at once is certainly a nice feature.
  12. The Silent-Vault philosophy is to integrate the marketplaces inside the client, rather than rely on external websites to provide them. This can be done via further extensions to the XMPP protocol, in support of specialty markets like stock/options/futures trading, p2p sports betting, predictive markets, or the like. For some of these cases, avoiding web domains entirely is essential (just ask Bodog). XMPP marketplaces accessed via PageKites and proxy gateways do not depend on DNS. However, there is also a merchant website payment gateway for VS, called OnionPay, which was developed in 2011.
  13. The BitMessage layer FT describes, to be used for bazaars, Craigslist, and Localbitcoin type functions, would be dealt with in VS parlance by providing an API supporting data extraction from an exchange or marketplace, again via specialized XMPP messaging. This could then be exposed on a website, or forwarded into BitMessage as FT suggests. (Note this does not exist yet.)
  14. VS wallets can be recovered using the answers to 5 security questions. This is a huge step up from “Oh, you lost your private key? Forgot your passphrase? Sorry, but you're screwed!” – which is the standard right now for all bitcoin and alt-coin clients. FT does not address what OT does concerning account recovery.

On Voting Pools

I found FT's description of the use of voting pools to remove money from a currency Issuer's reserve to be quite intriguing. He made it clear though that this idea is largely vaporware at this point (as it is everywhere else its use has been suggested). I believe that this is probably best handled at the Issuer level, but if some extension of the VP-to-Issuer communications protocol were required to implement it, this could doubtless be accomplished. The idea of using voting pools to make spends in general sounds to me like one of those ideas — like the programming concepts of multiple inheritance or overloaded operators — which sounds good on paper but which 99% of people never use, and which generate problems of their own if actually they do get used. Call me a cynic, but trusting a majority of a committee of unknown persons is only marginally better than trusting a single unknown person. The idea of course is to trust algorithms not individuals, and that's good as far as it goes. However it is naive to assume that at the Issuer level, where somebody is actually holding digitally circulating backing assets, that tech can obviate the need to trust anyone at all.