Tangram Design: Value Transfer

Published in

Tangram

6 min readMar 14, 2019

This is the first installment in a series of explainers that will gradually explore the details of the Tangram implementation. These articles will build on topics around Tangram’s design and development and encourage discussion moving forward. Today we will touch on three specific areas, and delve deeper into these and other topics in the future.

Addresses
Key exchange model
Coin minting

Addresses are a very prominent feature of cryptocurrencies. Typically comprised of a long series of alphanumeric characters, they act as a repository for coins while enabling simple sharing of value with other users. For example, Alice simply needs Bob’s address and in no time sends some coins Bob’s way from her own address. This transaction is registered on the blockchain and will usually carry the sending and receiving addresses involved. As owners of their own coins, Alice and Bob will use these addresses to “talk” to each other. However, they will not enjoy privacy because of the nature of this transaction. Several ways to mitigate this lack of privacy have been proposed for traditional blockchains: mixers, aggregated cash systems, ring signatures or zero knowledge-proofs. In this blog post, we highlight how Tangram follows this privacy-focused trend by employing robust cryptographic schemes for value transfer — including a key exchange protocol and commitment schemes — which render direct connections between addresses unnecessary.

Key exchange model

Tangram does away with the ubiquitous From- and To- addresses, employing instead a key exchange model which still allows a convenient and secure sharing of value between sender and receiver. Coins are not embedded or held ‘in’ any address; instead they carry specific attributes which define them, and render them individually identifiable on the Tangram network. Associated with a master key, they are now objects from which unique properties can be derived.

Let’s use a simple Alice and Bob example for when a transaction takes place (transaction taking place for the very first time).

Coins travelling on the Tangram network go with their own attributes which are a function of their owner’s (Alice’s) master key and a few other derived functions. Alice must prove coin ownership by providing proof of the same sequence of key generation associated with the master key. Once she has sent the coins, a redemption key, which consists of two secret keys, is derived and shared with Bob.

We can illustrate this process with a coin that originally possesses the following attributes:

Alice retrieves the redemption key and passes it to Bob, namely a “hot release”:

Bob, in possession of this redemption key, can now use it to claim the sent coins. To ultimately change ownership, the coins must go on to assume the attributes of Bob’s own master key. In executing this transaction, the use of link addresses becomes unimportant. While Alice may have indeed used a toAddress in sending value to Bob, it doesn’t form a direct part of the relay. Instead, the relaying link is created at the instant of transaction using a Diffie-Hellman key exchange whereby, in addition to a redemption key, Alice sends a message which is a function of the hash of Bob’s public key. The message is then decrypted on Bob’s side using Bob’s own key that only he knows. Therefore, even with knowledge of Bob’s address, it would still be impossible to ascertain how much value he holds.

Coin minting

A Zero-knowledge proof is used to pass the coin to Bob without revealing Alice’s master key. Upon reception, Bob will step the hash chain forward. That is, using the attributes of the previous coin, he will derive a new redemption key, which in addition to his own master key, is used to change the attributes of the coin:

The attributes of the coin are then changed by applying this redemption key and Bob’s own master key.

Once Bob moves the chain forward, Alice is unable to retrieve or “take back” the coin because Alice’s version, stamp and master key will no longer match the new attributes. It is as if an entirely new coin has been minted.

Bob now has to prove that he is the rightful owner of the coin(s) Alice has sent. Proving ownership requires that Bob has indeed “inherited” the coin and that no value was printed out of thin air. This proving process happens in two important places: within the wallet, and on the Tangram nodes.

In the wallet, Tangram systematically does a “coin swap”:

Here, Bob builds the sequence from the redemption key received from Alice by utilizing the lookup coin and the new coin Bob will be adding to the hash chain. Next, the node needs to verify and pass through these attributes, i.e. validate and prove that Bob is indeed the owner. We’ll call this the “coin pass” phase:

It is necessary to check that Bob has correctly built the new coin and that it validates and matches the sequences within the hash chain:

Once the coin is validated and marked as “true”, the transaction can be stored in Tangram’s CLi wallet (Vault) and the new coin is “generated”. The chain moves forward, creating a valid sequence of attributes associated with the transaction from Alice to Bob.

In summary, each time a user receives a coin in her wallet as part of a transaction, it takes on new attributes in order to reflect the change in ownership. A new coin is “minted” into existence at the receiver’s end, while the previous one is destroyed. It is important to note that no value is created or lost in the process. For users to “claim” these coins in the wallet, they will need to prove that they own or have rightly inherited the coin

You can read more about this process in CoinService.cs in the newly released wallet code.

CLi light-wallet

Transactions on the Tangram network are authorized and validated by the nodes. Because coins are uniquely verifiable, double spends are easily identifiable by the nodes and are discarded accordingly. Along with the nodes, the wallet makes up the suite of Tangram interactors. The recently released CLi light wallet is the first iteration in what is expected to be a series of Tangram wallets to come. The wallets may connect to any other available node, and may switch nodes as they wish. Wallets do not have to download the full ledger hosted by full nodes, as they only maintain reference to the coins owned by the individual and only handle some services where full nodes handle all services pertaining to the network. Sending and receiving information between wallets and nodes occurs over the Tor network, a private global network which enables anonymous communication. The primary purpose of Tangram wallets is to keep track of owner’s coins, serve as a utility for communication with other users via the nodes, and for the creation or minting of coins.

Interested in helping?

Tangram is looking for a talented, experienced, and hands-on core engineer. You will be designing, building, and implementing the core systems behind Tangram’s end-to-end solution of safeguarding sensitive information and data.

If you’re interested give us a shout out on any of the below channels or get in touch with core or community managers.

We look forward to hearing from you!

Check out Tangram’s latest CLi release and development here:

https://github.com/tangramproject/Cypher

Last update:

https://medium.com/tangram-tgm/development-update-open-source-cli-light-wallet-new-components-and-vulnerability-patch-progress-68f949837bb5