GNU Taler

GNU Taler is an elementary coin system.

The GNU Taler project devises a payment system founded on strong cryptography. Do not get this confused with Blockchain, which is more of a hype with rather light cryptography and mostly inherited properties from peer-to-peer networks.

GMU Taler is strong enough for running a digital government currency. But it can express anything as a Sensible Taler currency. The system recognises the various roles that come into play when managing currencies, and it develops software for each of them.

This project builds Sensible Taler currencies on GNU Taler by defining requirements and procedures for fully backed values, and allowing global exchange between institutions that share the same notion of value.

Generic GNU Taler

Once the currencies are defined and the GNU Taler coins minted, the system behaves mostly like a vanilla GNU Taler system, where:

• The user guide applies
• Parties hold a wallet
• Merchants run a Point Of Sale
• Exchanges relate to the underlying value
• Auditing is supported

The one special thing is that Sensible Taler defines currencies independent of the operations of Exchanges and Merchants. It is possible that disconnected islands each implement the same ideas. They are generally better off when these islands get connected, of course. And following the same Sensible Taler currency instructions should make it simple to bond through trust relations to enable consumers and merchants to find connective paths between their respective Exchanges.

Minting at the Exchange

The minting operations extend the Taler Exchange component via the standardised Taler Wire Gateway API. This is used by the Taler Exchange software to speak with backends that actually pass value via a variety of backend systems.

Independent of the precise backend for a particular Sensible Taler currency, it must live up to the following constraints:

• Before GNU Taler coins can be created, their underlying value must be deposited with the Exchange

  • Deposits may take the form of physical delivery of the underlying value
  • Deposits may take the form of handing over a title of ownership of the underlying value
  • Deposits may take the form of a transfer of the underlying value from an internal account
  • Deposits may take the form of mutual account deposits of the underlying value at a trusted peer
  • Deposits have not and will not be used as underlying value for GNU Taler coins may be returned

• Before paying out the underlying value, the same value in locally issued GNU Taler coins must be rendered useless

  • Paying out may take the form of physicial delivery of the underlying value
  • Paying out may take the form of handing over a title of ownership of the underlying value
  • Paying out may take the form of a transfer of the underlying value from an internal account
  • Paying out may take the form of mutual account deposits of the underlying value at a trusted peer
  • Coins must removed to claim the underlying value from GNU Taler before the paying out may take place

• A few complicating extra procedures may be feasible, but their net effect must never divert from the above:

  • Transactions that could fail may first lock the value from GNU Taler coins, provided they completely block the spending of this value and provided that the lock is only lifted if it is completely certain that the paying out is impossible to be used by the intended recipient or any other party, including internally
  • When transactions fail in more doubtful situations, for instance when a digitally signed title of ownership was sent but rejected, then the rejection must be equally strong and either carry a later timestamp or make a cryptographically strong reference to the rejected title of ownership, and this must be signed by the rejecting recipient
  • After allocating a transfer of ownership via FIX Trading, all reservations must have been made for an agreed-upon period of time, and the payment must not be rejected for such technical reasons; parties do well to avoid paying close to the timeout
  • Procedures may be formed that are equivalent to combinations of the above; a deposit may for example be immediately paid out; or deposits may be combined; or payouts may be combined

• The various changes must be stored to support auditing by other parties

Wallet pays Merchant

A party may need to purchase something, and implement that by passing along Sensible Taler currency in the form of GNU Taler coins. Before such coins can be spent, the underlying value must be deposited with the Exchange, and they must be deposited in the right wallet.

Whether a wallet is personal, or whether an organisation trades on behalf of multiple, can vary between the Sensible Taler currency. For Sensible Energy, it is possible that energy cooperatives trade for many customers, and need to pass individual's requested energy purchases into a shared wallet. For Sensible Bullion, a precious metal may normally be kept in an individual wallet, but they may collect into a wallet for the peer receiving the gold payment, if they agree with that as a form of delivery of the precious metal; they may later even any out disbalances later, via a bulk physical exchange such as a whole gold bar moving to the receiver's pallet within the same vault.

FIX Trading will not start trading unless it has a sufficient balance in the sending wallet. It will allocate a reserve in the wallet to avoid planning double spending (or concurrent manual spends that could jeapourdise the proper handling in FIX Trading.

As soon as FIX Trading concludes a deal, there is an obligation to conduct it on both ends. For the selling side, this creates an order via the Merchant Private API, just like a shop frontend would do. For the buying side, this creates a Wallet Paying Transaction that connects to the Merchant API and performs the GNU Taler payment.

After this has happened, the wallet spends coins into the merchant account, and the deal has been paid. The merchant in turn has the right to claim the underlying value from the Exchange, which was the place where the coins were created at the time the underlying value was deposited. The details of the Exchange process differ between the various Sensible Taler currencies, but the trading and payment system is pretty much the same.

Wallet internal trading

When the trading party groups supply and demand, it may combine internal orders and decide that they can be combined internally. This can be performed with a wallet-to-wallet transfer, known as P2P Push Payment between GNU Taler wallets.

This would follow the same rules, though possibly with simplified transaction logic. The reservation might for example be skipped if the internal trade can be atomically done. Of course a value cannot be spent more than once, and of course there must not be any conflict between internal and external trading.