Digital Cash

Digital cash with advanced features




Home



Legend

Description

Coin denomination

Various details

Protocol

Alternative

Chosen text attack

Distributed mint



Vela


Digital cash will not be implemented in Vela mainly because the backing assets would still be centralized, so an anonymous currency doesn't seem to help gain much freedom.

Insider attacks are very dangerous for the same reason. Although their risk can be reduced by using several distinct "sub-mints" to sign the issued coins, this would dramatically increase the costs for both the mint and for the users (who now would have to contact online all "sub-mints" to be sure that a coin has been signed by all).



Legend

Mint: the entity which creates digital coins.

Minting: the creation of new coins by the mint. The creation is made by simply signing blinded coin cores.

Blinding: operation which allows a digital signature to be applied on some data, without knowing the actual data, but knowing only an "encrypted" form of the data. After unblinding, the signature verifies as if the actual data was signed.

Coin core: data which describes a digital coin. This is to be blinded and signed by the mint.

Exchange / spend / payment: in exchange for some given digital coins, the mint creates new coins whose total value is the same as the total value of the given coins, minus the minting fee. The given coins are marked as spent and can never be spent again. The returned coins are split in two parts: the part which is given to another entity as payment, and the remainder part.



Description

There are all sort of ways to do digital cash, but they all break trust at some point. Signing makes trust hold in adverse environments.

This is a digital cash protocol which provides anonymity.

The protocol assures that if any party involved in a payment makes false claims, the real facts can be cryptographically proven. The mint, the payer, the recipient, none can lie about a payment and get away with it.

For example, the mint can't lie about a specific coin to have been spent. This is because the coin has an owner, and the mint may mark the coin as spent only if it has a signed document from the coin owner, document which specifies that the coin is to be exchanged into another coin (owned by someone else). Basically, the mint can't deny redemption to anyone who presents a digital coin signed by the mint.

The most important feature of the protocol is that only the recipient of a payment knows the identifiable form of the coins he will receive, and therefore is under no danger of having his money frozen by the mint, at least not with a greater chance than the mint randomly stating that any coin is frozen.

This means that any coin you own can "rust" in your ewallet, and the mint would be unable to ever freeze it or to identify you by examining it when you spend it.

But anonymity is useful, on a large scale, only when coupled with the ability of the spender to prove that he did pay the recipient. The spender can't prove that the recipient has received the digital cash, but only that he has sent the digital cash to the recipient, and that nobody but the recipient can spend that digital cash.

If the recipient claims that he didn't receive the digital cash, the spender can simply give the digital cash to the recipient, in an arbitrated context. As such, the arbitrators can know with cryptographic certainty that the recipient has received a specific amount of digital cash from the spender, and therefore he must fulfill the contract which is attached to the payment document.

The spender can remain unknown to the recipient, if he wants that. Also, the mint is unable to link the spender to the recipient, not even by IP. This is because the recipient never communicates with the mint. Also, the recipient never has to reissue the coins he receives, and therefore the mint can't even connect a spender and a recipient by matching identical amounts of digital cash which are being transacted in a short time frame.

The anonymity is achieved by using temporary asymmetric key pairs, symmetric encryption keys, and session identifiers. The only necessary long-term digital identities are the presentation identities of the recipient and of the mint, which are used only for communication.

The existence of the long-term presentation identity of the recipient doesn't imply that the recipient's physical identity must be known. However, in the absence of known ways to physically reach the recipient, the proof of payment becomes useless. Therefore, spenders should generally spend digital cash only to the presentation identities of the entities which can be physically reached.

The costs of the protocol are high, but the result is worth it. In practical terms, a payment made from a PDA and received on a PDA needs about 10...30 seconds to be initiated by the spender (because a temporary asymmetric key pair is created), 10...30 seconds to be accepted by the recipient (because a temporary asymmetric key pair is created), and 2 seconds for minting. An organization which needs to receive digital cash for their group identity, don't have to create a temporary asymmetric key pair, but simply use a predefined group identity which is not known outside the organization.

All minted coins are signed with two asymmetric key pairs in order to ensure that if a key pair is cracked (by sheer luck), the cracker can't simply mint himself any amount of digital cash.

If the protocol is used only to store and pay large amounts of digital cash, the costs are acceptable.

On average, the mint could process some 40'000 spends per day, per computer, but the protocol is scalable. A network traffic redirector application which runs on a dedicated computer may redirect the spend requests which are sent to the mint, to other computers which execute the spend requests. This way, the minting performance is multiplied by the number of computers.



Coin denomination

Each coin must have a specific denomination. Ideally, there would only have to be a denomination of 1 unit of digital currency. However, in order to exchange large amounts of currency, a large amount of coins would be required, and this would mean a large amount of signatures to apply and a large amount of data to transfer through the Internet.

Therefore, an optimal denomination mechanism is one which minimizes the number of coins returned by an exchange. This can be achieved by using power of 2 denominations.

Consider that "coin weight" is a number from 1 to 32. The associated coin denomination is equal with 2 ^ "weight" – 1.

Now, any value between 0 and 2 ^ 32 – 1 can be represented as an array of 32 weights, where each weight can be either present or absent. This means that each weight is represented by the bit with the index equal with "weight" – 1, from the amount of currency to represent in denominated coins.

A unit of currency which is small enough to be useful in most payments, is 1 / 100 grams of gold. This means that the biggest denomination of a coin is about 42 millions grams of gold.



Technical description

The service descriptor of the mint contains 2 sets of 32 asymmetric key pairs (which are used only for signing coins). There are 2 sets because a coin is signed by one identity from each set, so that if a key pair is cracked (by sheer luck), the cracker can't simply mint himself any amount of digital cash.

The position of each key pair, in the set, is equal with the coin weight represented by the key pair, and is used only to sign coins of the same weight.



Various details

Coins in circulation

The coins in circulation are the coins which were ever minted but which have not yet expired.

The mint must keep a history of all the coins in circulation, and make them public in order for anyone to see what is the total amount of currency in circulation, and compare that with the total value of the backing medium of the currency. This can happen because all these coins are blinded (and the blinding factor is known only to the owner of each coin).

If anyone can show a coin in circulation which is not published, that would be proof that the mint has minted more coins than it publicly states. Of course, this could also indicate that some of the asymmetric key pairs used for signing coins, have been cracked, but this is unlikely.



Coin expiration

The minting identity has an expiration time. After that time, the identity may not be used to sign coin cores, and all coins which were signed with it may never be spent. When a minting identity expires, all coins signed by it expire.

Expired coins are not coins in circulation. Therefore, the mint may delete them and reuse their associated backing medium for minting other coins.



Reuse of the backing medium

The total value of the coins in circulation must be smaller than (or equal with) the total value of the backing medium (of the coins).

The mint can reuse at any time the backing medium in value equal with the difference between the total value of the backing medium and the total value of the coins in circulation, for minting other coins.



Double-spending protection

The mint must keep a history of the spent coins, so that they would not be spent again. These coins must be kept in the history until each they expire, after which they may be deleted.



Reputation services

Reputation services can collect proofs of payment in order to calculate reputation scores for merchants.



Protocol

Step 1

The spender generates new temporary asymmetric key pair to use to sign documents sent to the recipient.

The spender creates a spend-intent request which includes:

  • A spender-recipient session identifier.

  • A temporary symmetric encryption key (with which the recipient will encrypt his responses for the spender).

  • The public part of the temporary asymmetric key pair.

  • The currency name to spend.

  • The currency value to spend.

  • The minting fee. The mint will check if this is the fee it has to charge for fulfilling the spend request, and if it's not, it rejects the transaction.

  • The time of creation of the request.

  • The contract (= reason of payment).

The spender sends the signed request (with his temporary asymmetric key pair) to the payment recipient.

The request is encrypted for the long-term communication identity of the recipient. The session identifier of the encrypted envelope is the spender-recipient session identifier.



Step 2

The recipient generates new temporary coin-owner identity to represent the owner of the coins he will have when the spend will be settled. Organizations which want to have the coins owned by their group identity, must not generate the temporary identity, but use their existing group identity to represent the owner of the coins.

The recipient creates the coin cores with the total value equal with the total value of the coins which he will receive (= own when the payment will be settled). A coin core must contain:

  • A hash for a "coin owner appendix". The appendix includes the public part of the digital identity which represents the owner of the coin. The recipient sends this appendix only to the mint, and only when he wants to spend the coin. The mint guarantees to allow the coin to be spent only if the signature of the spend request is verified by the owner identity.

  • A hash for a "coin inheritor appendix". The appendix describes the inheritors of the coin, and includes the public part of the digital identity of each inheritor, and the date after which each inheritor may spend the coin. The inheritance information is not put in the owner appendix so that the inheritors would be visible to the mint only when they actually spend the inherited coin. The recipient never sends this appendix to the mint.

The recipient creates a response which contains:

  • The (unencrypted) spend-intent request.

  • The blinded coin cores.

The recipient sends the signed response (with his long-term communication identity) to the spender.

The response is encrypted with the temporary symmetric encryption key from the spend-intent request. The session identifier of the encrypted envelope is the spender-recipient session identifier.



Inheritance note

The inheritable coins have to be put in an escrow service. It's not a problem if anybody sees the coins, because only their owner can spend them, and after the inheritance date its inheritors too.

The coin inheritor appendix is sent by the owner of the coin only to the escrow service. The escrow service sends the coin to its inheritors when they can inherit the coin.

When an inheritor wants to spend his inherited coin, he has to send the inheritor appendix to the mint, together with the coin.

The owner has to consider that if he still lives when the coins are about to enter their inheritable time frame, he must spend them (to himself) before that time and set a new date for inheritance.



Step 3

The spender creates the remainder coin cores which he will own after the payment is settled. The remainder value is equal with the total value of the coins to spend minus the value which is intended to be paid, minus the minting fee. A coin core must contain:

  • A hash for a coin owner appendix.

  • A hash for a coin inheritor appendix.

The spender creates a spend request which includes:

  • A spender-mint session identifier.

  • A temporary symmetric encryption key (with which the mint will encrypt its response for the spender).

  • The coins to spend.

  • The coin owner appendix for each coin to spend.

  • The blinded coin cores from the recipient, also blinded by himself. The double blinding is necessary so that if the mint and the recipient collude, they would be unable to know who the spender is.

  • The blinded remainder coin cores, also blinded by himself.

  • The public part of his long-term presentation identity, if he wants to received a proof of spend from the mint.

The spender sends the signed request (with the identities which represent the owners of the coins to spend) to the mint.

The request is encrypted for the long-term communication identity of the mint. The session identifier of the encrypted envelope is the spender-mint session identifier.



Step 4

The mint checks if the spend request is signed by all the identities which represent the owners of the coins to spent.

The mint guarantees to allow coins to be spent only if the signature of the spend request is verified by the owner identity of each coin, or if the coins are in their inheritable time frame and the signature of the spend request is verified by the identity of an inheritor of the coins (the inheritor must be able to inherit all the coins from the spend request).

If the public part of the long-term presentation identity of the spender was specified in the spend request, the mint creates a proof of spend which contains:

  • The time when the spend was made.

  • The public part of the long-term presentation identity of the spender.

  • The spent currency name.

  • The spent currency value.

The mint creates a spend response which includes:

  • The (unencrypted) spend request.

  • The signed proof of spend (with its long-term communication identity). This is not signed with the rest of the response.

  • The signed coins to spend (with its minting identity) from the spend request.

  • The signed remainder coins (with its minting identity) to spend from the spend request.

The mint sends the signed response (with its long-term communication identity) to the spender.

The response is encrypted with the temporary symmetric encryption key from the spend request. The session identifier of the encrypted envelope is the spender-mint session identifier.



Step 5

The spender sends the (unencrypted) response received from the mint, to the recipient.

The response is encrypted with the temporary symmetric encryption key from the spend-intent request. The session identifier of the encrypted envelope is the spender-recipient session identifier.

The spender must keep all temporary resources until the payment is settled.



Step 6

The recipient unblinds the coins he received and stores them.



Optional actions (which prove that the recipient has received the digital cash sent by the spender)

The recipient creates a spend-settled response which contains:

  • The (unencrypted) spend response received from the mint, through the spender.

The recipient sends the signed response (with his long-term communication identity) to the spender.

The response is encrypted with the temporary symmetric encryption key from the spend-intent request. The session identifier of the encrypted envelope is the spender-recipient session identifier.

The recipient may clean-up all temporary resources, but this is automatically done some time later, 7 days by default.



Alternative

There is an alternative method which provides some very interesting features: escrow and recovery.

Escrow means that mint would accept to spend the escrowed coins only if they spend request is accompanied by a certification from the escrow service.

Recovery means that if the recipient doesn't reissue the received coins, the spender can himself reissue the coins. This is useful if the recipient becomes unable to fulfill the action for which he is being paid. This means that the recipient must reissue the coin that he receives, before the recovery date comes. Of course, the recovery date could be a year after the payment, but that still means that there has to be a reissue.

In this protocol, the spender (not the recipient) creates the coin cores, blinds them and sends them to the mint for signing.

The coin core may contain a hash for a "coin escrow appendix". The appendix includes the presentation identity of the escrow service.

The coin core may contain a hash for a "coin recovery appendix". The appendix includes the public part of the digital identity of the recovery agent.

No coin appendix is sent to the mint so that it would not serve later to associate spends. However, when a coin is spent, the coin appendix must be sent to the mint. Since its hash is already in the signed coin, it's certain that the correct appendix accompanies the coin.

The critical problem of this method is that the spender knows the digital identity of the owner of the coins, and can therefore convince the mint, under whatever fantasist reasons, to freeze those coins.



Chosen text attack

To protect against chosen text attacks, the random data from coin cores has to be replaced with hashes of random data. The hashes are checked by the mint, against the provided random data, on exchange, and invalid coins are rejected.

This mechanism still allows chosen text attacks, but it makes them expensive because invalid coins can't be exchanged, so every chosen coin core costs at least one unit of currency.

Note the one unit of currency should not have a value which is too small, or else the attack would be cheap.



Distributed mint

A group of organizations / individuals can get together and create a (federated) mint, and issue one kind of digital cash. Each member of the federation has equal legal rights, within the federation, and is considered trustworthy, by the other members, to sign coins.

However, this trustworthiness is (and must be) limited. No single member can issue digital coins which can be redeemed. In order for a coin to be redeemable, it must be signed by all members of the federation.

This mechanism not only protects the currency from insider attacks and from corrupt members of the federation, but it also protects the currency from the compromised computers of the members. It is impossible for a single member of the federation to forge (redeemable) coins because a valid (redeemable) coin must be signed by all members of the federation.

When a user makes a spend request to the mint, he must give some coins he has in order to obtain others (with different properties). Each coin he gives must be sent to all members of the federation.

Each member verifies that each coin he receives was signed by all members (himself included). Finally, he marks the received coin as spent, and signs the coin which is to be sent back to the user.

The disadvantage of a distributed mint is its cost: the mint needs a different computer for every member, and users need to be able to access, through the Internet, the computers of all members and must wait for all to respond with the signed coins.







License | Contact