Voucher-Safe, a Next Generation Digital Currency – Part I

Digital Gold Currency is a fantastic idea. Gold enjoys thousands of years of history as an excellent currency and store of value. It is a form of money that is constantly chosen by the market and that needs no legislation to support its value. Gold is stable, solid and cannot be pulled out of thin air. With modern technology gold can be used as a currency online without any more effort than it takes to check your email. Brilliant!

But as DGC’s were starting to take off and be recognized for their many benefits, the rug was pulled out from under the industry with the prosecution of e-gold. The old DGC business model is centralized and vulnerable to seizure, censorship and prohibitive regulation.

The Voucher-Safe system allows for a more decentralized, Anti-Money Laundering compliant way to anonymously exchange value. It’s DGC 2.0, a more flexible and resilient system where anything can be money. “The idea behind voucher-safe is that it isn’t about making just one thing money. Money  can be gold, it can be existing national fiat currencies, it can be bitcoins, it can be silver, it can be anything of value that people want to exchange.”

I recently had some very in-depth discussions with Sidd, Voucher-Safe’s founder (also co-founder of Pecuinx) and Kevin, the principal developer. Voucher-Safe is software and a network that allows for the anonymous and very affordable exchange of the encrypted representation of value. DGC readers will be familiar with Voucher-Safe from the 2011 Industry Overview Issue.

Sidd and Kevin began designing the system when they ‘saw the writing on the wall’ soon after the demise of e-gold.  As Kevin put it, they began discussing how it would be possible to “operate one of these businesses without getting an ankle bracelet like Doug Jackson’s.”

The problem with the old DGC model is that they are account based and centralized.  Kevin recalls “seeing footage of Doug Jackson testifying before congress and actually boasting about how he was able, because it was all in one database, to track every little flake of gold from the first time it was put in the system to every account it had ever been in and so on.“ With an account based system the operator has a record of all transactions and can be held liable for their clients’ illicit transactions. E-gold’s ability to track all transaction through the system was used against them. Having records of all transactions is “absolutely a sucker’s game, particularly if you’re talking about an alternative currency that’s not going to be in good standing to start with simply because it is alternative. You have to separate the payment system from the store of value”

The Voucher-Safe system is designed to do exactly that. The Issuer, who hold the assets, is separated from the rest of the system and has no knowledge of the transactions taking place with the ‘cash’ that it has issued.

The system is modelled after gold backed “claim checks” or receipts. A good analogy would be a gold backed paper currency where you have gold sitting in a vault somewhere and the “claim checks” on this gold then circulate as cash. In this situation, those looking after the gold in the vault have no idea whose wallet that claim check is sitting in. Their only concern is the safe keeping of and accounting for the assets that back those claim checks.  “And that situation has been recreated technologically with Voucher-Safe where the vouchers are a circulating bill and you have digital wallets where different kinds of vouchers representing different assets can circulate.”

It is a complicated process to replicate this situation in the digital world. To understand how Voucher-Safe works you need to understand who the players are. There are three primary players in this system, the Issuer, the Publisher and of course, the users.

The Issuers are the entities holding, maintaining and accounting for the assets that back a particular issue of vouchers. The Issuer is AML compliant. Anyone wishing to purchase assets from the Issuer will need to provide identification and information in accordance with Know-Your-Customer rules. The Issuer is responsible for maintaining those assets and assuring that the amount of vouchers issued is always less than or equal to the assets that they hold. However, the issuer has no knowledge of what their customers may or may not do with those vouchers once they have been issued to them.

The Publisher works with one or more Issuers, facilitating transactions and is an essential part in the payment system. Publishers join the Voucher-Safe network to earn tokens which are in essence mini-vouchers. (This arrangement will be discussed in the next part of the series.)

The users are anyone who is using the Voucher-Safe software to exchange value with other users.

The Publishers and the exchange process are the heart of the Voucher-Safe network. To achieve the goals for the system, it was necessary to find a way for transactions to take place without centralized receipt signing, accounts or transaction records, all while maintaining anonymity. Not an easy task.

Because this process is so important to the functioning of the system, I’ll list the steps in the process. But, for those who don’t want to get bogged down in the technical details, here is an analogy that will hopefully be helpful in understanding the process.

Issuer A is a respected bullion vault and you would like to own an ounce of gold stored in their vaults. You go to Publisher A, who works with Issuer A, you give them $1,700 and you receive a receipt for one ounce of gold. (You can think of the Issuer and Publisher as a private Mint and Treasury.)

You owe Joe some money for some services he has provided and the two of you decide to settle your bill by passing the receipt for one ounce of gold stored in Issuers A’s vault on to Joe.

Joe gives you a lock for which only he has the key.

You then take this lock to Publisher A’s office and ask them to please place your receipt for one ounce of gold in a safety deposit box and give them Joe’s lock to put on the box.

Joe then stops by Publisher A’s office and notices his lock on one of the boxes.

Joe is able to open the box with his key and retrieves the receipt.

You and Joe then give each other receipts for the transaction.

Note: Neither one of you have an ‘account’ with the Publisher. The Publisher never asks you for ID and has no idea who you are. The only thing Issuer A knows is that you purchased one ounce of gold stored in their vault and that they issued you a receipt for the gold. They have no idea that you exchanged this receipt with Joe

In the digital world, this process is much faster, but involves a few more steps.

It is very important to note that the single most important feature of the Voucher-Safe system is the limited information that each player in the process has. This is particularly true of the Issuer who has no knowledge of anything besides vouchers. It knows which vouchers are on the circulation list and it knows about voucher serial numbers and nothing else. It is a “need to know” system.

This limiting of information is done through encryption, so that each player only has access to the information they need, and through anonymous communication via the OFS Gateway. You can think of the OFS as a proxy that hides IP addresses. All user login and payment-related communications happen via the OFS and, of course, the OFS cannot read the contents of any of the messages traveling through its system.

Below is a step by step of the transaction process in the Voucher-Safe system.

  • The Payer logs in and all the vouchers in his safe are decrypted
  • When the Payer initiates the transaction the client software automatically selects a voucher for payment, starting with the oldest first
  • To send a payment, the Payer will need to have the Voucher-Safe ID of the Payee. (This  looks like an email address, but is similar to a Bitcoin payment address)
  • The Payer enters the Payee Voucher-Safe ID of the safe that they want payment to go to
  • The software creates a message that includes the voucher(s) to be transferred and Payee safe ID and any payment details (a memo field, or baggage fields)
  • If there are any payment details associated with the payment, (information in the message that is only for the Payee) then these are encrypted using the Payee’s public key.
  • The whole payment message is encrypted with the Publisher’s  public key and signed with the Payer’s private key
  • The message is securely transmitted to the Publisher via the OFS
  • The Publisher decrypts the payment message and checks the signature from the Payer
  • The Publisher looks up the Payee’s safe ID and retrieves his public key
  • The Publisher verifies its own signature on the vouchers to be certain that they are unaltered and valid
  • The Publisher sends a message detailing the amounts, serial number, and amounts required (if splitting or combining vouchers) to the Issuer via an encrypted communication.
  • The Issuer checks that the vouchers are still on the active circulation list (this prevents double spending)
  • If there are no problems, the Issuer assigns new serial numbers for the output amounts and sends this information to the Publisher
  • The Publisher acknowledges the Issuer and makes the new signed vouchers using the new serial number, while the Issuer retires the old serial numbers and adds the new serial number and amount to its active circulation list
  • The Publisher includes the new voucher and the original payment details in a new message which it signs and encrypts to the payee
  • Publisher places the encrypted voucher & message on the DHT (Distributed Hash Table) which acts like a safe deposit box in the cloud
  • The Publisher places the change voucher (should there be one) back in the Payer’s safe and returns a successful status reply to the Payer
  • The message is stored on the DHT with a unique encrypted address that the Payee can find
  • When the Payee logs in to his Voucher-Safe (or clicks “refresh”)the software automatically checks the Distributed Hash Table and finds the encrypted message
  • The Payment message is collected and decrypted
  • Payee now has the voucher, but he needs it to be stored permanently in his safe by having it revalidated and replaced with a new voucher of identical value
  • The Payee creates a message that includes the voucher and the Payer’s ID
  • The Payee then signs this message  with its private key
  • The whole message is encrypted with the  Publisher’s public key
  • The message is securely transmitted to the Publisher via the OFS
  • Once again the Publisher facilitates the issuance of a new voucher and destruction of the one sent by the Payee.
  • The Publisher signs this voucher with its private key and then encrypts it with the Payee’s public key
  • The Publisher stores the new encrypted voucher in the Payee’s safe and sends a successful status reply
  • After the successful pickup by the Payee, the transaction becomes irrevocable
  • If the Payee fails to pick up the payment within the time set by the Payer, then the Payer becomes able to pick up the payment voucher himself (i.e. retrieve it)
  • The Payee’s Voucher-Safe software generates a receipt for the Payer, signs the receipt with its private key and places the receipt on the Distributed Hash Table for the Payer to find
  • If there were any private payment details, those are included in the receipt data signed by the Payee, along with any optional return memo text

Even this is simply an overview of the process. There is quite a lot happening under the hood, but thankfully the Voucher-Safe software makes the user experience much simpler. You can watch demo videos, or try it out for yourself at Voucher-Safe.com.

For those who are interested in the technical specifics of the Voucher-Safe system, they can be found by creating an account at Voucher-Safe.org. The client source code and API documentation for all components can be downloaded from the site as well.

Voucher-Safe is a secure cloud based system.  Unlike Bitcoin, “there is nothing actually on your phone or on your computer. If your phone should get lost or stolen or arrested by authorities, there is nothing for them to find.” All of the information in the system is encrypted, sometimes twice. “What that means is that no one, including the voucher Publisher, can see what value somebody has. They might see that there are so many rows in the table at this hash for that particular safe, but there is no way to know what those rows represent, or whether they are simply payment receipts.”

Voucher-Safe’s carefully thought out design and payment system make it vastly more flexible and resilient than previous digital currency business models. “We’ve been through generation one of digital currencies now and it’s time for generation two.“

The next parts of the Voucher-Safe special will cover Issuers and assets, the economic incentives of the system, trust in the system, the extensive security procedures, supporting apps and payment software and more.

Part II examines the Voucher-Safe economy, trust, security and software.

Part III looks at Voucher-Safe’s interaction with Bitcoin, Issuers and OnionPay.