Tangram: An Introduction

December 19, 2018

1

Contents

1 Note 6

2 Abstract 7

3 About Tangram 8

3.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Design Goals 9

5 A Note on Tangram’s Privacy and Transparency Model 10

6 Overview 10

7 Transaction 12

8 How a transaction is made 12

8.1 masterKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8.2 toAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8.3 Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8.4 Encrypted memo field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

9 Anatomy and lifecycle of a transaction 13

10 Transaction validation 13

11 Hash-based payments 14

11.1 Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

11.2 Blake2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

12 Coin generation 14

13 Offline transactions 14

13.1 Phases of generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

13.2 Coin(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

14 Redemption Key 16

15 Notification Address 16

16 Merkle DAG 16

16.1 Hash-based scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2

17 Tangram Protocol: zk-PoS Consensus 18

17.1 Zero-knowledge Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

18 PoS-Conditions 21

18.1 Slashing Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

18.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

19 Network 21

19.1 Basic concepts of a gossip protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

19.2 Tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

19.3 Tor Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

20 Ledger 23

21 Nodes 23

22 Wallet 24

22.1 Balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

23 Proof-of-Work 25

24 Storage 25

24.1 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

25 Privacy 25

25.1 Privacy of balances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

25.2 Privacy of amounts / transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

25.3 Sealed Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

25.4 Somewhat Homomorphic Encryption (SWHE) . . . . . . . . . . . . . . . . . . . . 26

26 Transaction unlinkability 26

27 Security & Attack Vectors 27

27.1 Double-spending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

27.2 Transaction Flooding / Flood Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 27

27.3 Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

27.4 Majority Attack (51% attack) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

27.5 Denial of Service (DoS) attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

27.6 Malicious code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

27.7 Nothing-At-Stake Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

28 Miscellaneous 29

28.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

28.2 Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

28.3 Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3

28.4 Incentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

28.5 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

29 Applications 30

29.1 Wallets / Account(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

29.2 Simple Smart Policy Escrow (Contract) . . . . . . . . . . . . . . . . . . . . . . . . 30

30 Conclusion 32

31 Acknowledgments 33

32 Notes and Further Reading 34

33 Future Considerations 35

References 36

4

List of Figures

1 Privacy and Transparency Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Anatomy of a transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Authentication procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Merkle DAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Hash based scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Broadcast for N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 SWIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5

1 Note

*This document will evolve and is subject to updates and changes based on feedback, research,

empirical evidence and analysis. The definitions herein are not intended to be comprehensive or

final. Changes between the original paper and Tangrams’ current implementation will be indicated

in green.

6

2 Abstract

A rapid shift from traceable and non-private peer-to-peer transactions has become increasingly

prevalent in blockchain, next-generation distributed ledgers, and many other applications. Many

individuals and organizations are now discussing the need for a private and/or anonymous ap-

proach. Here we propose a solution which will provide a secure networking platform to enable

private, non-traceable transactions, with on-chain unlinkability, and complete fungibility. Our ap-

proach utilises a blockchain coupled with a Merkle DAG structure for immutable balances at the

time when transactions take place. All user amounts are stored on the ledger, cemented without

ever displaying the balance in plaintext or knowing the sequence of blocks generated from individ-

ual accounts. The ledger provides proof of the user amounts within the network as it builds after

every transaction. This provides transparency of available coins and total coin supply within the

network, as well as providing multi-layered verification and anonymity for consensus. All amounts

and values are broadcast to all other nodes through a gossip based approach within the mixing

network, Tor. While nodes can leave and join the network and clusters at any given time, the

ledger provides proof of coin authorship and ownership. A zero-knowledge Proof of Stake consen-

sus protocol within the network enables trustless transfer of value. This system meets the design

principles of privacy, speed, simplicity, robustness, quality, and low operating cost. Satisfaction of

these criteria lays the groundwork for long-term scalability and future innovation.

Keywords: anonymity, applications, cryptocurrency, distributed ledger technology, financial

privacy, hash-based payments, network application, proof-of-stake, zero-knowledge

7

3 About Tangram

Tangram is a global project that aims to inspire, mobilise, and empower a new generation of free,

fast, and secure digital payments and services. By combining cutting-edge open-source engineer-

ing, compelling user experiences, and branding, we’re working to create the world’s most private

distributed ledger network. Our network and platforms are built with security that is not only use-

ful for governments, financial institutions, and multinational corporations, but also yields zero-risk

and zero-compromise solutions for the everyday individual.

3.1 Privacy

By creating a highly-sophisticated and infinitely-scalable digital payment system that enables busi-

ness, investors, and individuals to make secure and untraceable transactions with unprecedented

speed, while unlocking the unique opportunity presented by the digital age, to take greater control

of their own financial security and wellbeing.

3.2 Technology

The technologies will ensure private transactions remain private, and will eventually grow to a

point where we can support smart contracts, data storage, and communications; starting with a

desktop wallet that offers the banked and unbanked a safe place to spend, share, and store a digital

currency that has enhanced privacy and encryption features.

3.3 Research

With strong commitment to research and development means that we are constantly looking for

new innovative ways to enhance online security, with the long-term ambition of establishing a

revolutionary network of integrated financial and communication-based products, services, and

partnerships that enable individuals, businesses, and investors serve and advance privacy as a

universal human right.

3.4 Education

We believe education is important, especially that based on open-source technology. It provides a

powerful platform to engage, share and connect with thousands of people across the globe. We aim

to provide an authentic and supportive research-based educational practice which enables learning,

teaching and partnering with those that believe in the same goals.

8

4 Design Goals

The following are Tangram’s broad design goals:

• Privacy: create a private distributed ledger technology that is provably impervious to re-

identification attacks.

• Speed: perform verified transactions in under ten seconds.

• Cost: ensure that no fees are associated with transaction execution.

• Security: minimize vulnerabilities, network complexity, and maximize resilience.

• Censorship Resistance: enable anyone to freely and discretely access and utilise the net-

work.

• Transparency: allow for simple verification and auditing of the total coin supply.

• Scalability: support rapid growth and performance improvement as the number of nodes

increase.

• Simplicity: provide applications and APIs that are easy to use, maintain, and evolve.

• Robustness: maintain network function even if the majority of nodes go offline.

• Hardware Independence: allow anyone to be able to send and validate transactions on

any device.

• Quantum Secure/Safe: support future enhancements to address privacy and security risks

related to quantum computing.

9

5 A Note on Tangram’s Privacy and Transparency Model

Many DLT solutions today only allow for verification of coins if a vulnerability is known, such that

a larger-than-stated amount of coins – or even ongoing minting of additional coins is difficult to

detect. To address this specific risk, and to maintain ongoing public trust, Tangram’s total supply

is always verifiable to ensure that all coins are visible in the ledger and can be accounted for.

With Tangram, anyone is able to verify the total supply, and any major exploits such as coin

“minting” will be immediately evident.

All coins are associated with a masterKey. These coins cannot be linked to an individual.

An individual’s total balance cannot be determined, as each coin carries different amounts, never

leading back to an individual’s final balance or transaction history.

Figure 1: Privacy and Transparency Model

6 Overview

The following overview is intended to give a concise summary of the ideas behind the solution,

for an audience already familiar with blockchain-based cryptocurrencies such as Bitcoin. It is

presented as a general overview, not a precise technical description, and is not part of a normative

protocol specification.

All coins associated with an individual are also associated with the masterKey. Individual

balances and transactions from the sender and receiver in Tangram are private. Values of coins are

made transparent, essentially similar to Bitcoin where the total supply at any given time in the

Tangram protocol and/or network is auditable. Balances (which are always considered as ‘data-at-

rest’) are encrypted using a two-level homomorphic encryption scheme, Somewhat Homomorphic

Encryption (SWHE). The owner of the balance is able to encrypt their balance with a ‘true’ value

or a ‘false’ value by creating two separate keys. By default, the ‘false’ balance is set to zero.

All transactions in Tangram are carried out privately, without the balance, value (amount),

sender, or receiver being visible to third parties. A sender must define four properties in order for

10

the transaction to be committed, verified and confirmed. These properties are as follows:

• masterKey

• Notification Address (Base 58)

• Amount

• encryptedMemofield

Once all four properties have been defined by the sender, the transaction is encrypted with an

ephemeral key and the recipient’s public key, and then sent to the messagePool for the receiver to

take ownership of the coins. For this to occur, a redemptionKey must be generated by the sender

and is packed within the sealed box. Once a redemptionKey has been received, the following takes

place:

1. Check if coins exist on the ledger.

2. redemptionKey is used to encode the new coins properties.

3. The coins are then verified through a zero-knowledge proof.

4. New coins are generated once a transaction has been sent, verified and confirmed.

A transaction includes computationally sound zero-knowledge proofs and hashes, which prove that

all of the following hold true (except with insignificant probability):

For each input;

• there is a revealed secretKey with the same value as the input,

• prover authorizes the secretKey of the coins,

• the coins commitments are computed with correctness,

and for each output;

• there is a revealed value commitment of the same value as the output coins,

• redemptionKey is computed correctly,

• it is infeasible for any coin to have exactly the same properties as any other.

During the sendPayment function, an explicit coin(s) check is included to verify that the amount

being sent is valid and proven to be the sender’s. (No balance check is required.)

In addition, various measures are used to ensure that the transaction cannot be modified or

tampered with either while the transaction is in transit or ‘at rest’ with the receiver or third

party. Aside from zero-knowledge - Proof of Stake, the transaction is validated when the following

requirements have been met:

1. notificationAddress and its contents are those defined by the sender for the receiver.

11

2. redemptionKey and its properties match for both the sender and the receiver.

3. The coins and their contents are consistent with those in the Merkle Tree.

4. Receiver encodes the coins with the two secrets shared by the sender.

5. Ownership is only transferred once the receiver has proof that the coins are valid, owned (by

the sender), and verified (zero-knowledge-proof).

The properties of the coins inherently prevent double-spending. Each coin on the ledger has these

properties which are unique to the coin, and attempting to spend a coin twice without revealing

the secretKeys would reveal to other nodes that the coin and its properties already exist or invalid,

thereby invalidating and ignoring the transaction.

7 Transaction

The term ”transaction” is used in Tangram to refer to the data transferred object when sending

data from an external “account” which contains:

• masterKey: used to generate, pass ownership, and secure stack of coins.

• toAddress: the recipient of the coins.

• amount: amount to transfer from the sender to the recipient.

• encryptedMemofield: optional user data field, which can be used to insert some form of

proof of association of sender.

8 How a transaction is made

An individual executes a transaction (send) on the client (wallet) side and defines all the prop-

erties that a coin generates as outputs. Thus, the actual computation behind the transactions is

performed by the individual (sender), and the traces forming the transaction already contain the

output objects, return parameters, and the information required to validate the coins through the

network and its algorithm. This design pattern is related to traditional optimistic concurrency

control.

The following are input fields needed for an individual to send value:

8.1 masterKey

masterKey is created from an Argon2 function and thereafter mixed with several properties to

create the associated subKeys. subKeys are then hashed using Blake2b.

8.2 toAddress

An address is a public key which is encoded to a base58 string.

12

8.3 Amount

Stack of coins which are associated with an individual’s masterKey. An individual can have multiple

stack of coins with different values associated, which make up an individual’s account balance.

8.4 Encrypted memo field

An optional data field named “encrypted memo field” is made available to the sender of a transac-

tion. The encrypted memo field is present in every transaction, and is always exactly 64 bytes long,

which is equivalent to 64 characters. If the encrypted memo field does not use the full data field

(64 bytes), the remaining bytes will be padded with the ISO/IEC 7816-4 padding algorithm. [1] If

the sender does not input any data (text) within the encrypted memo field, the memo will be sent

with random values (prior to encryption).

Padding is necessary for privacy, so that when an observer tries to decipher the contents of the

encrypted memo field, there is no obviously discernible difference; no patterns from transaction to

transaction; and the data being transmitted is consistent with that of others.

The encrypted memo field is only visible to the recipient, as the sender encrypts using the

recipients publicKey (pK). Only the recipient can decrypt the encrypted memo field.

9 Anatomy and lifecycle of a transaction

As described above, the following figure visualizes the transaction lifecycle of a sendPayment for a

given input, along with the properties for each step of the send process.

Figure 2: Anatomy of a transaction

10 Transaction validation

Execution and validation of transaction(s) are done locally. The signed transaction is submitted

to your local Tangram node. Local and validating node(s) will validate the signed transaction to

ensure it has been signed by the sender.

Validation procedure for sendPayment:

13

• Verify coins

– Verify Hint

– Verify Keeper

– Verify Principle

– Verify Stamp

• Verify notificationAddress

• Verify zero-knowledge proof

11 Hash-based payments

Hash-based payments are simply a payment system consisting of hashes. The algorithms which

are incorporated are Argon2 for the masterKey derived function and proof-of-work, and Blake2b

to secure the Merkle DAG.

11.1 Argon2

Argon2 is a password-hashing function that summarizes the state of the art in the design of

memory-hard functions, and can be used to hash passwords for credential storage, key derivation,

or other applications. [2]

11.2 Blake2b

BLAKE2 (also known as Blake2b) is a cryptographic hash function which is faster than MD5,

SHA-1, SHA-2, and SHA-3, yet is at least as secure as the latest standard SHA-3. BLAKE2 has

been adopted by many projects due to its high speed, security, and simplicity. [3]

12 Coin generation

Any coin(s) received are “challengeable” on the client side. A challenge is referred to as a response

from the server side which questions the client side, asking for proof as to whether the sender has

the requested properties and amount.

The sequence of the coins has a subset that constitutes a serial number defined by an amount

with a secured random key, and thereafter execution of a zero-knowledge proof.

13 Offline transactions

A receiver is able to claim their coin through many channels, as mentioned previously. One of the

ways in which this integrates well with the Tangram network is that the receiver is able to claim

their redemptionKey through the messagePool and thereafter feed this within their client (wallet).

This enables the individual to decrypt the data, and because the redemptionKey provides zk-proof

14

of the coin, it may index the ledger download the data needed to take ownership, and then the

challenge will proceed.

13.1 Phases of generation

All coins are generated within the genesis block. Stack of coins are associated with an individual’s

masterKey, which (again) is a key derived function. If any subKeys are compromised, it does not

lead back to any other subKeys or the masterKey itself. The remaining attributes of the coin are

used to derive key functions to create hashes on top of hashes, which enable the coin to go through

a process of storage and incorporation into the Merkle DAG. If any coin is not authentic and does

not have the necessary property requirements during the phases of the ( get) and ( set) functions,

the coins are disregarded, and the ownership and authorship of the coins in question are invalid

and ignored. masterKey provides the need to prove that you are the owner and also that the coins

are authentic.

13.2 Coin(s)

To authenticate ownership of the coins, the individual must provide the Hint, Keeper, Principle,

Stamp (zero-knowledge-prover), Amount (which is associated with your masterKey) and Serial

(which is derived from the amount and masterKey). The procedure of ownership and authenticity

needs to be zero-knowledge verified on the server side.

Below describes the authentication procedure for sending a coin(s):

Figure 3: Authentication procedure

All coins are associated with the masterKey, and the unique properties and fields are also derived

from it. Creating associated hashes for each property, the properties provided in conjunction,

creates these unique one-time hashes. Ownership must be demonstrated by providing proof of

the same sequence, generation of the derived keys, and hashes in order for verified zk-proof of

ownership is associated with a particular masterKey.

Each Principle within an execution of a sendPayment is always a different key (unique) during

the ownership transfer of the coins. This provides for a multi-layered security and authentication

process to verify coins author and ownership.

15

14 Redemption Key

Each redemptionKey is derived from the masterKey, which creates two subKeys. Both subKeys

are used for the receiver to take ownership of the coins that have been sent. Once an individual

has received the coins, the coins are encoded with the individual’s masterKey.

Two properties make up a redemptionKey:

• Proof of coins - amount and serial.

• Two secretKeys, encoded by the masterKey.

15 Notification Address

A notificationAddress occurs when a SendPayment has been executed. The purpose of the no-

tificationAddress, is so that the receiver is able to receive coins from a publicKey (pK) that the

receiver has created. This is considered as a sharedKey amongst the sender and receiver. This

increases the level of anonymity between the sender and receiver.

Sample:

1 var notificationAddress = cryptography.GenericHashWithKey(Utilities.

BinaryToHex(bobPk.ToArray()), sharedKey);

Code Snippet 1: A notificationAddress in code

16 Merkle DAG

The underlying structure of the network, the Merkle DAG, is a network of interrelated hashes which

secure a Merkle Tree structure. Furthermore, the structure is based on the data of coins, which

increases privacy and introduces the necessity of fungibility and sharding. There are embedded

DAGs within the architecture as well; for example, assuming 256 “chains” within each chain, an

individual is able to store, transfer and accept amongst other chains - this creates a chain-within-

chain network.

Separation of chains increases the possibility of sharding based on dynamic variables and caters

to optimisation for load balancing.

A simplistic representation of a Merkle DAG structure. Although the interpretation of the lines

as straight, and linkability seems assumed; this is not necessarily the case, yet all transactions do

indeed always flow forward temporally.

16

Figure 4: Merkle DAG

17

16.1 Hash-based scheme

Hash-based scheme refers to cryptographic hash functions, particularly the cryptographic hash

functions employed by Argon2 and Blake2b; each output is unique to a given input.

Figure 5: Hash based scheme

• V defines the version number of the coin

• A defines the amount associated with the coin

• P defines the proof that the coin is the owner’s and is authentic

• H defines the generation once a sendPayment has been executed

• K defines the key to the coin for an individual to take ownership and association with the

masterKey

17 Tangram Protocol: zk-PoS Consensus

The Tangram Protocol utilizes a decentralized consensus algorithm capable of meeting the privacy,

security, speed, and scalability requirements for the network, namely zero-knowledge Proof of Stake

through staking and voting dissemination. The goal of zero-knowledge Proof of Stake is to allow

a receiver direct proof of ownership of the coin being sent without involving a trusted third party

in the protocol. Tangram Protocol has properties that dynamically define the quorum. We follow

a leaderless Practical Byzantine Fault Tolerant (BFT) consensus similar to Blockmania. [4]

We randomly select n nodes to form a group of n random validators to form the consensus group,

these n validators will determine their ‘stake’ in order to join the voting and validation procedure.

When ‘staking’, the nodes selected and proved to have x coins defined to be ‘staked.’ There ‘stake

is locked and the redemptionKeys for each validator are submitted to an ‘escrow’/ messagePool.

‘Stake’ can also be delegated (stake cannot be used or spent by the delegated party), their weight is

determined for each n nodes based on the amount of ‘stake’ which is verified through a commitment

scheme using Shnorr protocol. Once the epochs have been received and stored within the node,

the stored transaction is signed using the privateKey of the receiver (Only receiver is able to sign)

while a coin’s properties need to exist and be valid in the sequence in which they were produced

18

in order to be proved. The zk-proof will then return ‘true’ for the property of the coins. Once

signed, validators will broadcast to other group(s) within the network.

With respect to Practical Byzantine Fault Tolerance (PBFT) the abstract events exchanged

are pre-prepare, prepare, commit, view-change and new-view (there are no messages relating to

check-pointing). Each node must maintain a state per decision it needs to reach: namely, a current

view number view n. The initial view number is zero and the message sets are empty. [4]

Figure 6: Broadcast for N

Every node can include the following messages:

View change (vc): Triggered upon a logical or physical time-out, for no advancement and

contains the latest events.

New view (nv): When view change is triggered, the state moves to new view with all view

change events.

View number (vn): A list of input messages in n and output messages out n

Pre-prepare (pp): For when a block is created.

Prepare (p): Defined when pre-prepare and view are triggered to accept.

Count for prepare (c): Resulting once a pre-prepare message is created and forwards to all

nodes (by random).

Commit messages (cm): Nodes that receive the prepare messages first, issue a commit

message to other nodes

Deliv: Delivery decision being received.

19

17.1 Zero-knowledge Proofs

We use Schnorr Protocol for Non-interactive Zero-Knowledge Proofs to allow for values not being

revealed, during ‘staking’ and value transfer. The Schnorr protocol is an example of a Sigma

protocol, which has the following properties:

Completeness: if the statement is true, the honest verifier (that is, one following the protocol

properly) will be convinced of this fact by an honest prover.

Soundness: if the statement is false, no cheating prover can convince the honest verifier that

it is true, except with some small probability.

Zero-knowledge: if the statement is true, no cheating verifier learns anything other than this

fact. This is formalized by showing that every cheating verifier has some simulator that, given only

the statement to be proved (and no access to the prover), can produce a transcript that ”looks

like” an interaction between the honest prover and the cheating verifier. [5]

Usage of the coin(s) properties will be made to verify and prove, hiding the elements that link

and trace a coin either to a sender and / or a receiver.

The protocol is a three-step protocol between the prover (P) and verifier (V). Which follows

the below:

• P -> V: commitment

• V -> P: challenge

• P -> V: response (proof)

The protocol is defined for a cyclic group of order n.

The prover commits to a random private value v, chosen in the range [1, n-1]. This is the first

message commitment = G * [v].

The verifier replies with a challenge chosen at random from [0, 2ˆt - 1].

After receiving the challenge, the prover sends the third and last message (the response) resp

= (v - challenge * a) mod n.

The verifier accepts if the prover’s public key, P, is a valid public key. It means that it must

be a valid point on the curve and P * [h] is not a point at infinity, where h is the cofactor of the

curve.

The prover’s commitment value is equal to G * [r] + P * [challenge] [6]

1 testSchnorrNIZK :: IO Bool

2 testSchnorrNIZK = do

3 −− Setup

4 let curveName = Curve25519

5 basePoint = Curve.g curveName

6 keyPair@(pk, sk) <− genKeys curveName basePoint −− Prover

7 proof <− Schnorr.prove curveName basePoint keyPair −− Verifier

8 pure $ Schnorr.verify curveName basePoint pk proof

Code Snippet 2: An example of the Schnorr protocol for Non-Interactive Zero-Knowledge Proofs

looks as follows:

20

The Schnorr implementation in Tangram will use Curve25519.

18 PoS-Conditions

The algorithm (consensus) is as follows and operates in epochs of r rounds each ; *a secure

commitment scheme is used for transaction(s), each contains a zk-proof which verifies

the amount using a random group of n validators:

18.1 Slashing Conditions

If the ‘stake’ of the validator is discovered to be malicious (i.e. certain set conditions are contra-

vened), the ‘stake’ will be distributed to the n random validators which participated during the

consensus process based on their weight of ‘stake’.

Note: in systems such as Ouroboros, [7] nodes are associated with some ‘stake’ which may

be an arbitrary value, however needs to follow the model of being unforgeable and transferable.

Decisions on consensus are based on the amount of ‘stake’, a node possess, and in such cases are

all probabilistic guarantees.

18.2 Performance

Upon going live with the Tangram network, performance will be measured by the number of

transactions and finality of consensus being reached.

19 Network

Tangram uses a gossip protocol to manage memberships and events of nodes organized in an

arbitrary way. The organization of the nodes is referred to as the network topology. Our topology of

choice is based on “SWIM: Scalable Weakly-consistent Infection-style Process Group Membership

Protocol”. [8] As such, the gossip protocol is used for membership, disseminating relevant meta-

data, transactions, and consensus amongst nodes in the network.

Any n nodes are free to join and leave a membership list/pool. Some nodes may even fail to

respond to requests or disseminate data.

Join process: When a member wishes to join the network, join messages are broadcasted and

group members within a cluster who are listening for join messages reply.

Leave process: The same procedure takes place when newly members join or members who

voluntarily leaves.

Failed process: Once Alice has detected that Bob is failed, she notifies her membership

list/pool. The members within this group delete Bob from their membership list.

N nodes periodically broadcasts to other nodes at random and disseminate accordingly, and

issue information at regular intervals. N nodes that broadcast, also listen to requests (reqs) from

all other n nodes within the network and respond with any events requested (ping-req), essentially,

all nodes gossiping events.

21

19.1 Basic concepts of a gossip protocol

There are two important components in the SWIM protocol:

1. Failure Detection Component, that detects failures of members

2. Dissemination Component, that disseminates information about members that have re-

cently either joined, left the group, or failed.

Both components work together sequentially in order to ensure four key characteristics meet the

composition of failure detection protocols.

1. Strong Completeness: crash-failure of any group member is detected by all non-faulty

members

2. Speed of failure detection: the time interval between a member failure and its detection

by some non-faulty group member

3. Accuracy: the rate of false positives of failure detection;

4. Network Message Load, in bytes per second generated by the protocol.

Furthermore, we introduce the usage of Off-the-Record Messaging Protocol. OTR assumes a

network model which provides in-order delivery of messages, but that some messages may not get

delivered at all (for example, if the user disconnects). There may be an active attacker, who is

allowed to perform a Denial of Service attack, but not to learn the contents of messages. [9]

We use OTR for communication between nodes and when events are propagated within the

network using gossip protocol.

19.2 Tor

We integrate the Tor Onion Service Protocol (formerly known as “hidden services”) at the trans-

port layer to secure and improve anonymity of the network traffic between the nodes in Tangram.

Ultimately this circumvents others learning an individual’s location (IP address) while using Tan-

grams network. By default, obfs4 will be active and all nodes and wallets utilise Tor proxy.

19.3 Tor Load Balancer

Tangram utilises the free, open-source Tor network based shell script called SPLITTER. This

script configures and applies a systematic chain of free open-source solutions which work together

to obfuscate traffic correlation analysis and increase the difficulty of statistical attacks within the

Tor network. It also assists with related de-anonymization techniques, while ensuring a better

performance for the Tor network and its users. [10]

22

Figure 7: SWIM

20 Ledger

The Tangram Ledger is in many ways similar to the Bitcoin blockchain from a design goals per-

spective, although there are many differences that define the structure and configuration. With

regard to transactions, the primary difference from all other currency blockchains and DAGs; is

that Tangram does not store transactions, only coins.

21 Nodes

Nodes are network servers composing the infrastructure and can be considered as processing plants.

Nodes are able to join, leave and process events from within their own cluster, or the entire network.

Wallets must be attached to nodes in order for payment confirmation to propagate across the

network. It is important to note that nodes only process wallet transactions, but never do the work

of the wallet. Their usage is purely to provide the link between coins verification and the ledger.

Accounts/wallets pre-compute and provide the node with all the information needed to process the

required data to be added to an individual’s masterKey, also providing the zero-knowledge proof

23

and verification.

22 Wallet

Wallets are external to nodes and emit transactions that need to be agreed upon. Wallets may

connect to any node within the network that they are aware of or that is made visible to the public.

The Tangram Command Line interface (CLi) wallet uses HashiCorp’s Vault Enterprise, which

is completely free and open source to manage, secure and control your keys and data. HashiCorp

Vault Enterprise is Federal Information Processing Standard (FIPS) 140–2 Compliant.

The following features have been integrated in Tangram’s CLi wallet:

• Unseal vault.

• Create wallet.

• Create addresses associated with wallet (identifier).

• Get a list of addresses associated with the wallet (vault).

• Check wallet balance.

• Transfer TGMs from sub-addresses or external addresses.

• Set the node which your wallet communicates with (either one you own (recommended), or

one owned by a third party.

• Exit and seal the vault.

• Help - get a list of available commands in the Tangram CLi wallet.

The Wallet utilizes two types of Vault policies, a wallet service policy, and a wallet user policy.

The wallet service policy is utilized by the wallet to allow the user to create new wallets and give

a list of existing wallets; it can be thought of as a “management” policy. The wallet service policy

does not have access to a user’s wallet or any secrets thererin. When a new wallet is generated a

user is created and a wallet user policy is attached to it, the wallet user policy gives the user access

to their wallet “secrets.” When a user authenticates with their credentials Vault will give them an

authentication token which has a “lease” associated to it. The user can access their Wallet data

while the lease is not expired. Once the lease is expired, the user will not be able to access their

wallet data and will need to re authenticate with their wallet credentials.

22.1 Balance

Defines the amount of coins associated with your masterKey and relevant subKeys / “addresses”.

Balance is kept within the Tangram CLi wallet and is never readable or present on the ledger.

24

23 Proof-of-Work

Hashcash like proof-of-work is used for spam protection and short computational operations.

To determine the proof-of-work difficulty for transactions, we have coupled below variables

which may be tweaked where necessary:

1. Cost of time: which defines the amount of computation realized and therefore the execution

time, given in number of iterations.

2. Memory consumption and cost: which defines the memory usage, given in kibibytes.

3. Parallelism of proof-of-work: which defines the number of parallel threads

4. Random string: which is generated by the node.

24 Storage

The size of each transaction is 390 bytes. The data length / size for each event is listed below

*table will be updated on further events:

Name Length (bytes)

masterKey 64

Coin 390

redemptionKey 300

Cipher 446

encryptedMemofield 64

24.1 Speed

Empirical analysis will be done, once a live network has been released with real-world statistics.

The following speeds will be taken into consideration and updated in this document:

• Transaction

• Confirmation Zero-knowledge (prover and verifier)

• Node synchronisation

• Broadcasting

25 Privacy

The mere use of one-time subKeys (which are generated from your masterKey) by businesses,

organisations and other entities accepting payments provides a greatly increased level of privacy.

25

25.1 Privacy of balances

The balance of an individual’s account is never revealed nor is it visible on the ledger. Balances

are encrypted at all times. Balances are only ever needed to allow an individual to view, rather

than the entire balance verification or validation needing to take place when sending a transaction.

25.2 Privacy of amounts / transactions

Amounts that are transacted are not combined or displayed as a single transaction send, nor are

the sender and receiver revealed to a third party observer. What can be observed by the public

on the ledger, is stack coins being transacted and ownership being changed.

25.3 Sealed Box

The role of sealed boxes is to anonymously send messages to a recipient given its public key.

Only the recipient can decrypt these messages, using its private key. While the recipient

can verify the integrity of the message, it cannot verify the identity of the sender. A message

is encrypted using an ephemeral key pair, whose secret part is destroyed immediately after the

encryption process. Without knowing the secret key used for a given message, the sender cannot

decrypt its own message later. [11]

Sealed boxes leverage the crypto box construction (X25519, XSalsa20-Poly1305).

X25519: X25519 is an elliptic curve Diffie-Hellman key exchange using Curve25519. It allows

two parties to jointly agree on a shared secret using an insecure channel.

XSalsa20-Poly1305: XSalsa is used for secret-key authenticated encryption and secret-key en-

cryption. Poly1305 is used for one-time authentication.

25.4 Somewhat Homomorphic Encryption (SWHE)

Tangram’s implementation utilizes SWHE, a leveled homomorphic encryption scheme that effec-

tively addresses the challenges of functionality and efficiency in real-world applications. While

supporting robust transactional security, this approach also lays the foundation for eventual con-

version to enable a four-level homomorphic encryption scheme which has the potential to provide

additional functions within Tangram and other real-world applications built on-top of Tangram,

and the eventual transition to full homomorphic encryption.

Somewhat Homomorphic Encryption is used to encrypt the balance of an individual’s account

(never be visible in plaintext) and how much their masterKey stores.

CLi wallet comes with two privateKeys associated with their balance. One key holds a ‘false’

balance, by default the ‘false’ balance is zero, and the second privateKey holds a ‘true’ balance,

which is the actual balance associated with the wallet or masterKey.

26 Transaction unlinkability

Understanding privacy implications such as transaction linkability will be helpful for users inter-

ested in maintaining maximum control over the visibility of their transaction(s) and storing of

26

their coins.

Transactions where Alice sends to Bob, the direct linkability with the coins transfer is broken,

and an individual is able to transfer coins to another without linkability appearing on the ledger.

An individual is able to “walk” the ledger without leaving links to the previous owned coins.

27 Security & Attack Vectors

In the history of Bitcoin and blockchain, there have been a number of incidents, some more

malicious or problematic than others. Each distributed ledger technology project, especially those

built from scratch, brings new challenges and attack vectors, both known and not yet known.

No software, least of all a distributed network, is unconditionally safe or secure, whether that

be the public key cryptography, consensus, protocol or algorithms. Tangram has been designed

to be safe to use and secure for given threat models. The model however can differ in reality and

only be answered with empirical evidence once the software and network are live.

Tangram relies, among other things, on public key cryptography and hash algorithms and thus

may be vulnerable to more known attacks described below. We describe the known attack vectors

in both traditional blockchains and 2nd to 4th generation ‘blockchains’, along with how Tangram

has mitigated these risks as best as possible.

27.1 Double-spending

[Definition] Double-spending is a potential flaw in a digital cash scheme in which the same single

digital coins can be spent more than once.

The properties of the coins are there to prevent double-spending. Each coin on the ledger is

unique and attempting to spend a coin twice and without revealing the secretKeys would reveal

to other nodes that the coins and its properties already exist and invalid, which would cause the

attempted coin spend to be rejected.

27.2 Transaction Flooding / Flood Attack

[Definition] A flood attack is the process of sending thousands of transactions to ”flood” the

messagePool and subsequently delaying other transactions.

Currently rate-limiting prevents transaction flooding, coupled with the proof-of-work function

and fingerprint restriction, which pairs an IP address with a public-key, has a significant deflation-

ary impact on spam.

27.3 Sybil Attack

[Definition] In a Sybil attack, the attacker subverts the reputation system of a peer-to-peer

network by creating a large number of pseudonymous identities, using them to gain a dispropor-

tionately large influence.

Types of Sybil attacks:

• Routing.

27

• Tampering with voting.

• Fair Resource Allocation.

The Tangram protocol makes this attack more difficult in the following ways:

• Completely isolating malicious node(s) from the network.

• Staking and weight associated with staking amount.

• Fingerprint mapping an arbitrary number of public-keys per IP address.

27.4 Majority Attack (51% attack)

[Definition] The ability of someone controlling a majority of the network to revise transaction

history and prevent new transactions from confirming and reaching finality.

In Bitcoin and other PoW blockchains, a 51% attack refers to hash rate; whereas in PoS, specific

to Tangram, in order to achieve a 51% attack, they would need to stake 51% of the network’s ‘stake’.

27.5 Denial of Service (DoS) attacks

[Definition] A cyber-attack in which the perpetrator seeks to make a machine or network re-

source unavailable to its intended users by temporarily or indefinitely disrupting services of a host

connected to the network.

Consensus is done randomly through every round by randomly selected validators. In order for

a DoS attack to succeed, the malicious actor would need to control a large portion of the network.

Nodes enforce per fingerprint and global API rate limits. Nodes that are rejected by their

pairwise member are encouraged to find a new random node to ensure progress.

27.6 Malicious code

[Definition] Malicious code is the term used to describe any code that is intended to cause

undesired effects, security breaches or damage to a system.

If two hash-schemes are found to be malicious or conflicting, one belonging to an honest indi-

vidual and one belonging to a dishonest individual, they would be isolated concurrently and be

verified for inconsistency and go through an audit procedure between random validators.

Scheme Correctness is achieved if the problem generation algorithm produces values that enable

an honest individual to compute encoded output values that verify successfully and correspond to

the evaluation of those inputs. On the other hand, a verifiable computation scheme is secure if a

malicious individual cannot convince the verification algorithm to accept an incorrect output for

a given function and input x. In zk-proof, if completeness is unable to be attained, correctness is

impossible.

28

27.7 Nothing-At-Stake Problem

[Definition] A situation where an individual loses nothing when acting or behaving maliciously

and by doing so, stands to gain by acting in such a manner.

The introduction of stake slashing mitigates the nothing-at-stake problem. It could be argued

that this will not force all nodes to behave altruistically but rather maliciously.

Security Vulnerabilities and Bugs

From the outset, development of Tangram has been engineered with security as a critical

priority. Although no system can be completely secure, every system can be continuously improved

towards that goal.

28 Miscellaneous

28.1 Hardware Requirements

The below hardware specifications are categorised into one (until recommended requirements can

be detailed):

Minimum requirements:

Disk

Space

Down-

load

Up-

load

Memory

(RAM)

System Operating System

Mini-

mum

(TBC) 5MBps 2MBps 512MB Some ARM-based

chipsets

Windows 7/8.x

Mac OS X

Linux

28.2 Mining

There is no mining capabilities such as with Bitcoin and other first generation blockchain tech-

nologies.

28.3 Fees

There are no fees required to transact by or with individuals, business and organisations utilising

the Tangram network or software.

28.4 Incentive

The incentive to running a node is for those who are altruistically motivated in upholding and

supporting a privacy conscious network. Although nodes that commit a sender’s coins and/or

transactions never reveal anything about the sender or receiver, to maximize privacy consider

owning and running your own node. Furthermore, by ‘staking’, if any malicious or dishonest node

is confirmed and valid, the ‘stake’ amount will be distributed amongst the nodes that were selected

to join the consensus.

29

28.5 Units

TGM (tans), which serves the purpose of providing a mechanism for value of transfer, the denom-

inations are as follows:

Unit Abbreviation Decimal Scientific Notation

tan TGM 1 10−0

microTan miT 0.001 10−3

nanoTan naT 0.000000001 10−9

attoTan atT 0.000000000000000001 10−18

Currently “attoTan” will not display to client side (user interface) and may be used at a later

stage.

29 Applications

Tangram is targeting very specific industries short to mid-term. The first category of industry being

financial institutions and the applications that drive them. We believe that there is a fundamental

challenge facing today’s financial institutions: they’re slow and cumbersome, rooted in outdated

technology and methodologies.

The outset Tangram will provide users with more ways of managing, securing, storing, and

controlling their financial status(s).

29.1 Wallets / Account(s)

Create an account instantly that allows for financial freedom and full control of your finances. By

having an account on the Tangram network you can securely, privately, and almost instantly send

value anywhere in the world at any time. There are no minimum balance or fees which would

hinder anyone from creating an account and transacting.

Creating an account is simple:

1. Download the Tangram CLi wallet.

2. Enter a passphrase.

3. Save your masterKey.

29.2 Simple Smart Policy Escrow (Contract)

Multisignature (multisig) refers to a process requiring more than one key to authorize a transaction.

It is generally used to divide up responsibility for possession of bitcoins.10

Tangram allows for a simple ‘smart policy’ escrow that allows for a 2-of-3 (two parties) OR

3-of-3 (third party) multisig escrow service. A simple smart policy escrow example would be as

follows:

1. Alice wants to purchase a service or goods from Bob, however, does not trust Bob.

30

2. Alice sends her coins to Bob, however, she ‘locks’ the coins or provides Bob with a partial

redemptionKey until Bob provides her with the service or goods.

3. Bob needs to provide the service or goods before Alice or the third party releases the coins.

4. Once Bob has provided the service or goods, Alice or the third party is able to share the

second part of the secret for Bob to claim the payment.

*Further applications will be defined in the future.

31

30 Conclusion

Due to the design of the system, ultimately no wallet for storing coins is required which eliminates

the risk of accidental loss of coins. The framework is based on the concept of a hash-based scheme,

which allows for transfer of coins between individuals. Authorship and ownership are provable,

and thus solve the challenge of double-spending and other common issues. Finally, every transfer

of a coin provides complete anonymity to both the sender and the receiver.

32

31 Acknowledgments

We would like to acknowledge and thank everyone involved in the development and growth of the

project.

33

32 Notes and Further Reading

• The EU General Data Protection Regulation: https://eugdpr.org

• Vault by HashiCorp: https://vaultproject.io/

• Tor software for anonymous communication: https://torproject.org/

• Tor Onion Service Protocol: https://torproject.org/docs/onion-services.html.en

• Schnorr-nizk: https://github.com/adjoint-io/schnorr-nizk

• Nothing at stake problem: https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs#

what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed

• Hashcash: http://www.hashcash.org/

• Scalable, transparent, and post-quantum secure computational integrity: https://eprint.iacr

.org/2018/046.pdf

• Off-the-Record Messaging Protocol version 3: https://otr.cypherpunks.ca/Protocol-v3-4.1.1

.html

34

33 Future Considerations

Within the vast (and growing) industry of distributed ledger technology, we limit the scope of

Tangrams future considerations and arbitrarily list a path in the short-term to long-term. We

present some of these milestones for future research and development.

• Optimisations to throughput and scalability enhancements

• Smart Policies / Contracts

• Atomic swaps

• Pruning mechanismCross-chain interoperability

• Privacy preserving technologies (zk-STARKS and others)

• Encryption delegation mechanism(s)

• Inclusion for further mixing networks (I2p)

• Protocol and consensus enhancement and optimization patterns

• ML based network monitoring (for malicious actors) and more

35

References

[1] Libsodium documentation. Padding, 2018.

[2] Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich. Argon2: the memory-hard function

for password hashing and other applications, 2017.

[3] Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, and Christian Winnerlein.

BLAKE2: simpler, smaller, fast as MD5, 2013. Winnerlein, “BLAKE2: simpler, smaller, fast

as MD5.

[4] George Danezis and David Hrycyszyn. Blockmania: from Block DAGs to Consensus, 2018.

[5] Zero-knowledge proof.

[6] Adjoint. Schnorr Protocol for Non-interactive Zero-Knowledge Proofs, 2018.

[7] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A

Provably Secure Proof-of-Stake Blockchain Protocol, 2017.

[8] Abhinandan Das, Indranil Gupta, and Ashish Motivala. SWIM: Scalable Weakly-consistent

Infection-style Process Group Membership Protocol, 2002.

[9] Ian Goldberg. Off-the-Record Messaging Protocol version 3, 2013.

[10] renergr1nch. DcLabs SPLITTER, 2018.

[11] Libsodium documentation. Sealed boxes, 2018.

36