TrustNote Technical Whitepaper

TrustNote Institute of Technology
i
FAST ∙ SCALABLE ∙ DEVELOPER FRIENDLY
Technical White Paper
May 2018

Overview
Today’s block chain technologies face many challenges such as network congestion, high transaction
fees, and long delay in transaction confirmation. TrustNote seeks to address these problems by building
the world-leading public Directed Acyclic Graph (DAG) ledger which is minable, capable of handling
high concurrent transactions yet still maintain quick transaction confirmation. TrustNote is focused on
creating an easy-to-use, decentralized, low-level digital token block chain that leverages declarative
Smart Contracts with enhanced expression capability, while empowering users to create and publish
digital tokens without having to write complex Smart Contracts. TrustNote has an extensible wallet that
provides security and rich API interfaces for digital tokens, block chain games and social networks,
which allowing new innovative ideas to run smoothly on the block chain network and making user
friendly block chain applications accessible to everyone. This document introduces TrustNote’s
technical characteristics, user scenarios, and detail about token issuance and so on. For more in depth
information about materials included in this document, please visit
https://github.com/trustnote/document.
Disclaimer
TrustNote Institute of Technology hereby declares that: The current package is experimental and a
work-in-progress, and you are using TrustNote at your own risk. TrustNote also declares that we might
change (add/remove packages) without informing the users. In addition, because of the existence of
“private equity” scams targeting crypto-currency investors, TrustNote hereby declares that participation
in crypto-currency investment through unauthorized trading channels should always take precautionary
measures against such risks. Neither TrustNote Institute of Technology nor the TrustNote Development
Team take responsibility for any consequences of investments via unauthorized trading channels.
Finally, we declare that, TrustNote White paper can be only accessed from:
https://github.com/trustnote/document
https://trustnote.org/
We do not guarantee the faulty or misleading data available in documents downloaded from any other
website rather than two official websites introduced above.
Contact Us
Business Enquiries: foundation@trustnote.org
Technical Support: community@trustnote.org
© 2018 TrustNote Institute of Technology. All rights reserved.

Contents
1. BACKGROUND........................................................................................................................... 1
2. WHAT IS TRUSTNOTE?.......................................................................................................... 2
2.1 KEY FEATURES ................................................................................................................................... 2
2.2 DIRECTED ACYCLIC GRAPH............................................................................................................... 3
2.3 COMPARISON ...................................................................................................................................... 4
3. DATA STRUCTURES ................................................................................................................ 5
3.1 UNIT .................................................................................................................................................... 5
3.2 MESSAGE TYPES................................................................................................................................. 6
4. CONSENSUS..............................................................................................................................11
4.1 NODES ...............................................................................................................................................12
4.2 UNIT INTER-REFERENCE ................................................................................................................13
4.3 MAIN CHAIN .....................................................................................................................................13
4.4 TRANSACTION CONFIRMATION.......................................................................................................14
4.5 TRANSACTION FEES AND MINING REWARD..................................................................................15
4.6 TRUSTME-POW..............................................................................................................................16
4.7 TRUSTME-BA..................................................................................................................................17
4.7.1 Design Goals.............................................................................................................................17
4.7.2 Final Consensus and Tentative Consensus...................................................................18
4.7.3 Lottery Algorithm ..................................................................................................................19
4.7.4 Byzantine Agreement ...........................................................................................................19
5. SMART CONTRACT................................................................................................................20
6. TRUSTNOTE PLATFORM AND APPLICATIONS ............................................................24
7. ISSUANCE AND DISTRIBUTION.........................................................................................27
8. REFERENCES............................................................................................................................28

Page 1 of 29
1. BACKGROUND
For about 10 years, since January the 3rd
, 2009, Bitcoin has been operating safely, a miracle in the
history of computer network technology. The success of Bitcoin unlocked the doors to the future
of the world’s economy for digital crypto-currencies; a new world full of imagination. Satoshi
Nakamato creatively proposed the Blockchain - a chained data structure based on hash functions -
and succeeded in building a well-operated, decentralized peer to peer network which opened the
new era of digital crypto-currencies. Blockchain technologies are developing fast, driving change
across many industries, sparking innovation and creativity.
Blockchain has provided a decentralized trust mechanism and has become a brand-new paradigm
and key methodology in data protection and data value exchange. Now in its booming period,
blockchain is constantly being integrated with various technologies, various scenarios are also
being explored in terms of how to utilize the technical characteristics of blockchain, blockchain
applications have been expanded from data tamper resistance and data value exchange to digital
tokens and social-networking arenas. The growing number of blockchain user scenarios pose many
challenges for blockchain technology, demanding stronger security, higher transaction concurrency,
and shorter transaction acknowledgment delay.
In Bitcoin's blockchain, all the data blocks are aligned in one continuous chain, but due to the
limitations on block size and consensus mechanism, the amount of concurrent transactions is
limited and transaction confirmations are slow, which resulting in the rise of transaction fees and
frequent trading congestions. To address these issues, the Bitcoin developer community has come
up with solutions such as increasing block size, segregated witness, and lightning networks, but
none of them is perfect. Those solutions either just ease the problem, or sacrifice security or
consistency, and none of them have reached full agreement within the community. The recent
emergence of multiple bitcoin forks, has heated up the debate even further.
The structure of the ‘traditional’ blockchain is the bottleneck that hinders the technology from
improving its concurrency. More efficient forms of distributed ledger technology are being sought
and a solution which combines Directed Acyclic Graph (DAG) and blockchain (hereinafter referred
to as "DAG-ledger") was proposed. The DAG-ledger has no concept of blocks, so there is no limit
to the size of the blocks. In addition, DAG-ledger uses a new form of transaction verification which
referencing the old transaction for transaction confirmation. This allows minor temporary
differences between the users’ ledgers, to achieve the goal of preventing transaction obstruction by

Page 2 of 29
weakening the consistency of the entire network in a short period. The larger the network is and
the greater the transaction volumes are, the shorter the transaction confirmation delay is.
IOTA and Byteball both developed their own public DAG-ledgers in 2015 and 2016 respectively,
to accommodate high-frequency trading scenarios. However, the downside is that although DAG-
ledger supports high-frequency trading, in the case of low-frequency trading, the old transaction
cannot get enough new transactions to verify and reference, resulting in the old transaction not
being confirmed in time, in extreme cases the transaction may never get confirmed. To address this
problem, IOTA proposes a temporary centralized actor called coordinator, which is used to protect
the network when the volume of transactions is low, however IOTA does not disclose the design
details of such coordinator; Byteball introduces twelve witnesses, implementing transaction
confirmation via witness attestation, although Byteball claims its users have the right to choose
their own witness, but the transaction quoting rules make it very difficult for users to change
witnesses if they choose to do so. TrustNote resolved all these issues by proposing a robust and
innovative design.
2. WHAT IS TRUSTNOTE?
TrustNote is a minable public DAG-ledger with an innovative, two-tier consensus mechanism
designed for new applications such as digital tokens issuance, blockchain games and social
networks. Its digital token is called “TTT”. TrustNote's goal is to be Fast, Scalable, and Developer
Friendly. TrustNote has a light architecture and intelligent contract system that supports lightweight
application extensions and micro wallets. Even more, TrustNote supports high concurrency
transactions, which results in fast transaction confirmation, and makes development and
deployment of distributed application (DApp) much easier. Last but the best, TrustNote platform
allows new innovative ideas to run smoothly on the ledger and making user-friendly DApps
accessible to everyone. For more detail about TrustNote Infrastructure and Fundamental protocols
please, visit TrustNote Tech Stack.
2.1 Key Features
Two-tier consensus mechanism, a minable public DAG-ledger.
Supports high concurrency transactions, benefits from fast transaction confirmation.
Supports advanced declarative Smart Contracts.
Token issuance system.

Page 3 of 29
Cryptographic Algorithm: BLAKE2, BIP32-Ed25519 (For more in depth information about
TrustNote Cryptographic Algorithms please, visit TrustNote-TR-01 Report).
Multi-platform wallet, light wallet, micro wallet, support third-party extensions.
2.2 Directed Acyclic Graph
A Directed Acyclic Graph (DAG), is a finite directed graph with no directed cycles. It consists of
finitely many vertices and edges, with each edge directed from one vertex to another, such that
there is no way to start at any vertex V and follow a consistently-directed sequence of edges that
eventually loops back to V again. The use of the DAG data structure to store ledger data is
gradually grabbing more developers’ attention. Projects like IOTA and Byteball have successfully
established stable public-ledgers using DAG, the feasibility of a DAG-ledger is proven.
In TrustNote terms, transactions are viewed as messages. Various types of messages are supported,
multiple messages can be combined into a data block which is called a “Unit”, and a DAG is formed
by inter-referenced Units. Since each Unit must reference multiple previous Units, there is no need
to spend more computing power and time for solving the consensus problem, nor need to wait for
the completion of strong inter-node data synchronization, and because there is no need to assemble
multiple Units into blocks, the performance of concurrent transactions is considerably improved
and the confirmation delay are reduced to minimum.
Figure 2-1 DAG Graph
TrustNote uses the following technique to solve the double-spending problem1
. First, try to find a
Main Chain (MC) starting from Genesis Unit on the DAG and assign indexes to the Units that
located on the MC, the Genesis Unit’s index is 0, and so on. Second, for those Units that do not
located on the MC, define their indexes equal to the first MC Unit references this Unit. Eventually,
every transaction on the DAG has an index. If two transactions try to use the same output, we just
need to compare the value of their indexes named Main Chain Index (MCI). The Unit with a smaller
index is valid, the Unit with a larger index is invalid, and thus it solves the double-spending problem.
1
double-spending is a problem unique to digital currency in which the same single digital token
can be spent more than once

Page 4 of 29
For example, when double-spending occurs (as shown in figure 2-2), after the MCIs are assigned
to each transaction, we can determine the transaction whose MCI is 7 is valid, the other transaction
whose MCI is 9 is rejected.
Figure 2-2 Main Chain (MC)
For security concerns, unlike Bitcoin’s blockchain which is guaranteed by the massive computing
power of the network, DAG based TrustNote relies on the fast advance of transactions and the
uncertainty of the relationship between the transactions as the "firewall", which leaves the entire
system looks too lawless to be attacked. TrustNote benefits from a two-tier consensus mechanism
and an innovative TrustME Consensus Algorithm. Those Super Nodes that participate in the
TrustME consensus and contribute to the healthy expansion of DAG-ledger will get the mining
reward.
2.3 Comparison
Standing on the shoulders of giants, absorbs the advantages of existing blockchain projects and
addresses their major issues, a more prosperous TrustNote platform becomes possible. A
comparison of current well-known DAG-ledgers (IOTA and Byteball) with TrustNote is shown in
Table 2-1.
Table 3-1 DAG-ledgers Comparison
IOTA Byteball TrustNote
Token IOTA Byte TTT
Consensus
Mechanism
PoW Cumulative Weight 12 Witnesses
Decentralized TrustME
Consensus Mechanism
Smart Contract No Declarative Contract
Advanced
Declarative Contract
Reward No
Transaction Reference
and Attestation
Transaction Reference and
Mining
Nodes
Full Node
Light Node
Full Node
Light Node
Super Node
Full Node
Light Node
Micro Node
Transaction Fee No Yes Yes
Double Spending PoW Weight Comparison
Main Chain
Sequencing
Main Chain Indexing
Low-frequency
Trading
Centralized Coordinator
Weak Centralized
Attestor
TrustME Attestor

Page 5 of 29
3. DATA STRUCTURES
3.1 Unit
When a Node initiates a transaction or sends a message, it creates a new data block called a "Unit"
and broadcasts the Unit to its peers. A Unit may contain multiple messages of various types, each
Unit contains the following information:
Header: The hash value of the previous Unit (parent).
Messages: A Unit contains one or more messages, there are various types of message,
and each message type has its own unique data structure.
Signatures: A Unit contains one or more users’ signatures.
Address: A user can have multiple addresses; the addresses are generated with BIP-0044
algorithm.
Definition of each Unit’s field is shown in table 3-1.
Table 3-1 Field Definition of Unit
Field Name Definition Remarks
version TrustNote protocol version number e.g. ‘1.0’
alt Token identification e.g. ‘1’
messages Message array for more information please see 2.2
authors Author array Address array of the Unit’s author/authors
parent_units Parent Unit’s hash array Hash values of the Unit’s parent/parents
The message’s field stores the actual data of the Unit, it is an array of one or more messages.
TrustNote supports various types of messages which are distinguished by the app field.
Table 3-2 Field Definition of messages
app Message type
e.g. “payment” or “text”, for more information please
see 2.2
payload_location
Location of the
message body
“inline” indicates the message body is stored in the
current message; “uri” indicates the message body is
retrievable from a URL address; “none” indicates there
is no message body
payload_hash
Hash value of the
message body
Payload Message body
Various message types are used to kept different data
format, e.g. a transaction message includes various
number of input and output
payload_input Message input array
Includes the hash value of the Unit who generated the
message, message index, output index etc.
payload_output Message output array
Includes addresses of recipients, amount of transaction
and etc.

Page 6 of 29
3.2 Message Types
TrustNote supports various message types which can be further extended if needed, different types
of messages are used to store different data formats interpretable by different parsing rules.
Different types of TrustNote message are recognizable by the message’s app field.
Mine solution (app = PoW-Equihash)
“PoW-Equihash” message is generated by Super nodes, PoW messages are used to store the
Equihash result and determine the Attestors for each consensus round. If a Unit contains a PoW
message, then this unit is a PoW unit. Even more, the priority of Attestors in each consensus round
is determined based on the sequence of stabilization of PoW units. The contents of PoW message
includes: consensus round’s number, seed, difficulty, Equihash solution and Attestor reward
address. For more information about the super nodes, PoW Unit and working mechanism, please
read the TrustNote-TR-2018-02 report.
messages:[{
app: ' PoW-Equihash ',
payload_location: ' inline ',
payload_hash: ' hash of payload ',
payload: {
round: ' round number ',
seed: ' string of seed ',
difficulty: '',
solution: '',
attestor_address: ' Wallet Address of Node '
}
}]
Attestation (app = TrustME)
No Nodes other than the Attestors can generate “TrustME” messages, TrustME messages are used
to store the Attestation results which super Nodes have. If Unit contains a TrustME message, then
this Unit is a TrustME Unit. The contents of TrustME message includes: consensus round’s number,
PoW unit hash, priority of the Attestor and Attestation reward (Coinbase) of (i-2)th
Stable
Consensus Round. For more information about the TrustME Unit, how to get attested and working
principals, please visit the TrustNote-TR-2018-02 report..

Page 7 of 29
messages:[{
app: 'TrustME',
payload_location: 'Inline',
payload_hash: 'Hash of Payload',
payload: {
round: 'Round Number',
PoW_solution: 'The PoW Unit Hash’,
priority: 'Priority of Attestor',
coinbase of (i - 2)th round：[
{address: ‘...’, amount: 21 MN},
{address: '...', amount: 19 MN},
...
]
}
}]
Transaction (app = payment)
“Transaction” messages are used to hold tokens’ transactional information. More than one input
and output can be included in a transaction message. For user defined assets, it is necessary to
specify the hash value of the Unit which defines the asset. A standard transaction message is as
follows:
messages:[{
app:'payment',
payload_location:'inline',
payload_hash:'hash of payload',
payload:{
inputs:[{
unit:'...',
message_index:0,
output_index:0
}],
outputs:[
{address:'...',amount:1200},
{address:'...',amount:2800}
]
}
}]

Page 8 of 29
Text (app = text)
“Text” messages are used to hold arbitrary string data.
messages:[{
app:'text',
payload:'any text'
}]
Structured Data (app = data)
“Structured Data” messages are used to store arbitrary structured data.
messages:[{
app:'data',
payload:{
any structured data
}
}]
Data Feed (app = data_feed)
“Data Feed” messages are sent by trusted third parties to trigger Smart Contract.
messages:[{
app:'data_feed',
payload:{
'data feed name':'...',
'another data feed name':'...'
}
}]

Page 9 of 29
Address Definition Change (app = address_definition_change)
“Address Definition Change” messages are used to update the address definition while retain the
old address.
messages:[{
app:'address_definition_change',
definition_chash:'...'
}]
Asset Definition (app = asset)
“Asset Definition” messages are used to define new digital assets.
messages:[{
app:'asset',
payload:{
cap:1000000000,
is_private: true,
is_transferrable: true,
auto_destroy: false,
fixed_denominations: false,
issued_by_definer_only: true,
cosigned_by_definer: false,
spender_attested: false,
attestors:[...]
}
}]
Definition of each field is shown in table 3-3.
Table 3-3 Field Definition of Asset Definition message
cap
Maximum amount of assets which can
be defined
is_private
Indicates whether the exchange of
assets is private or public
is_transferrable
Indicates if the asset can be transferred
between third parties while bypassing
the asset definer
If set as “false”, the asset definer
must be either the sole sender or
the sole receiver of each transfer

Page 10 of 29
auto_destroy
Indicates if the asset should be
destroyed when it is sent to the definer
fixed_denominations
Indicates if the asset can be sent in
arbitrary integer amount, or in fixed
denominations like traditional currency
or coins, e.g. 1, 2, 5, 10, 20, etc.
issued_by_definer_only
Indicates if the asset can only be defined
by the definer himself
cosigned_by_definer
Indicates if every transfer must be
cosigned by all asset definers
Useful for regulated assets
spender_attested
Indicates if the spender of the asset must
get attested before he spends. If he
happens to receive the asset but it is not
yet been attested, he must get attested by
one of the listed attesters before
spending the asset
Useful for regulated assets
attesters
The list of attesters’ addresses
recognized by the asset definer (only
when spender attested is set as “true”)
The list can be later-on updated by
the definer, by sending an
“asset_attestors” message
denominations
Lists every supported denominations
and total amount of each denomination
Used for fixed_denominations
assets only, not shown in the
example
transfer_condition
Defines the condition when assets are
allowed to be transferred. The syntax of
this definition is the same as address,
except that it cannot reference any
attestation data, such as “sig”
Usually there are no restrictions
except those already defined by
other fields
issue_condition
Same as transfer_condition but for issue
transactions only
Asset Attestors (app = asset_attestors)
“Asset Attestors” messages are used by asset definers to update the Attestors of the asset.
Poll (app = poll)
“Poll” messages are used to initiate a poll.
messages:[{
app:'poll',
payload:{
question:'...',
choices:['A','B']
}
}]

Page 11 of 29
Vote (app = vote)
“Vote” messages are used for initiating a vote.
messages:[{
app:'vote',
payload:{
unit:'hash of the unit where the poll was defined',
choice:'A'
}
}]
4. CONSENSUS
TrustNote adopts a two-tier consensus mechanism comprising “base consensus” and “TrustME
consensus”. The base consensus, also known as “DAG consensus”, requires new transaction Units
sent by Nodes verify the previous units by referencing them. The Attested consensus, or “TrustME
Consensus”, requires that the sequences of Non-TrustME Units be rigorously determined by
TrustME Units generated by the Attestors. Such two-tier consensus mechanisms can improve
transaction throughput and reduce delay in transaction confirmation, thus effectively solving the
problem of Excessive Bifurcation and double-spending.
For a more robust TrustNote ecosystem, two TrustME consensus schemes are developed. Initially,
TrustNote uses a Proof of Work (PoW) based scheme called TrustME-PoW; in the future,
TrustNote will adopt a Byzantine Agreement (BA) based scheme called TrustME-BA. No matter
which scheme is used, any Super Node participating in the consensus will receive a reward in the
form of TTT if they are selected as Attestor Node.
Under the TrustME-PoW scheme, Super Nodes getting the attestation authority by proving their
superior computing power; under the TrustME-BA scheme, a pseudo-random algorithm is used to
select Attestors among Super Nodes. In both scenarios, TrustME Units issued by Attestors always
comply with the Unit Inclusion rules, and do not affect the existing references between other Units.
Only after a TrustME Unit becomes a stable Unit on the Main Chain, it could finally justify that an
Attestor has contributed to TrustNote positively, and thus receive the Attestation reward. In
addition, both schemes encourage fair participation of all super nodes, TrustME consensus

Page 12 of 29
mechanisms seems to be fairer, more trustworthy, and safer than the centralized and semi-
centralized schemes.
4.1 Nodes
TrustNote supports four types of Nodes2
: Super Node, Full Node, Light Node and Micro Node.
The comparison of these Nodes is shown in table 4-1.
Table 4-1 Comparison of Nodes
Super Node Full Node Light Node Micro Node
ledger full ledger full ledger light ledger N/A
transaction √ √ √ commissioned
DAG consensus √ √ indirect ×
TrustME-PoW √ × × ×
TrustME-BA √ × × ×
Hosting Micro Node √ × × ×
deployment
Mining Systems
Cloud Host
Server/Workstation
PC
Cloud Host
Server/Workstation
PC
Smartphone
Tablet PC
MCU
Smart Card
TrustNote has a peer to peer network similar to bitcoin, each Node can select a random set of peer
Nodes to propagate messages. To ensure the messages cannot be changed, each message is signed
by the private key of its original sender, other Nodes must validate the signature before forwarding
the message. To avoid message forwarding loop, one Node does not forward the same message
twice.
To qualify as a TrustNote Super Node, the following requirements must be met:
Resource: Has good internet bandwidth, large storage space and enough computing
power, ideally with public IP address.
TTT: Holds certain number of tokens to pay the unit fee for PoW units and TrustME units
it generates.
Credibility: Has a good reputation on the network in submitting valid Units.
A super node must generate the deposit contract and pay it to start its activity on the network, the
deposit will be returned to the super node defined address as soon as the silent-locking time would
end. Super Node can generate the PoW unit and receive Attestation power and become an Attestor
by fitting in certain conditions. Attestors will get an Attestation Reward by sending TrustME Units
2
Each device in TrustNote network is considered as “Node”.

Page 13 of 29
and earn Attestation fees as well. For more information about the network topology, nodes
taxonomy and so on, please, see TrustNote-TR-2018-02.
4.2 Unit Inter-Reference
Each Unit in TrustNote should reference multiple Units that have no Parent-Child relationship with
each other, the new Unit will preferentially reference the Units with more Parents. When following
a Parent Unit in its Child Unit’s direction, we would see many forks if a Unit is referenced by many
Child Units. A certain number of Parent Units will merge into one if these Parents are referenced
by the same Children.
The purpose of referencing a Parent Unit is to establish orders among the Units. Before referencing
a Parent Unit, a Node needs to validate the Parent Unit. This validation process involves checking
whether the signature is valid or not, whether the reference is legal or not, etc. TrustNote does not
require strong synchronization between Nodes, different Nodes may see temporarily inconsistent
DAGs (it only differs in unstable units). But this does not undermine the Parent-Child relations that
has already been established among the Units, and it may only result in the Parent Units having
multiple Children. TrustNote supports high transaction throughput with low network latency
simply because TrustNote does not enforce strong data synchronization among Nodes.
To minimize the number of garbage Units generated in the DAG, a transaction fee must be paid
when any Node submits a new Unit. The transaction fee is divided and paid to:
The Node(s) who generate newer Unit and reference this Unit as Parent.
The Attestor who attested the Unit.
If a Unit is referenced by multiple Child Units, the Node who sends the Child Unit with the smallest
hash value will get the referencing fee. In addition, to qualifying the rewards, the Main Chain Index
(MCI) of the Child Unit must equal or be slightly greater than its Parent’s MCI, this restriction
encourages Nodes to reference the most recent Parent Unit as quickly as possible and as much as
possible so they can get more referencing fees, thus helping the DAG to get fast convergence and
reduce the number of forks. For more in depth information about the unit Inter-referencing, parents’
selection algorithm and so on please, see TrustNote-TR-2018-02.
4.3 Main Chain
To choose a single chain along Child-Parent links within the DAG, and then relate all Units to this
chain. All the Units will either lie directly on this chain or be reachable from it by a relatively small

Page 14 of 29
number of hops along the edges of the graph, this single chain is called Main Chain (MC). If we
build two MCs from two different Childless Units follow the same rule, the two MCs will
completely overlap with each other when and after the two MCs intersect at some point. The worst-
case scenario is that two MCs intersect at the Genesis Unit. Although Nodes are independent from
each other when generating new Units, and there is not any possible coordination. Thus, we still
expect the intersection of the MCs to be as close to the Childless Unit as possible.
Once a Unit has selected an MC, it can establish an index for two conflicting Units that haven’t
been indexed. First, indexing the Units that located on the MC, the index for the Genesis Unit is 0,
the index for the Genesis Unit’s Child on the MC is 1, and so on, until all Units lying on the MC
are indexed. For those Units not located on the MC, we can always find the first Unit located on
the MC and reference the Unit directly or indirectly, thus assigning a MCI to each Unit.
Consequently, given two Units, the Unit with a smaller MCI must be generated earlier. If the MCIs
of two Units happen to be the same and these two Units are in conflict, the Unit with the smaller
hash value is considered the valid one. TrustNote will keep all double-spending Units including
those deemed to be invalid.
The process of building the MC applies the Parent Selection Algorithm recursively. By
participating in the TrustME consensus, Attestors will send TrustME Units. By comparing the
number of TrustME Units among the available paths, the Parent Selection Algorithm will pick-up
one of the Parent Units as the "Best Parent Unit". For different Nodes, the MC building processes
are completely independent and only rely on the DAGs that each Node sees. Starting from a DAG’s
Childless Unit, following the path of the Best Parent Unit, a Node can build an MC through to the
Genesis Unit. For more information about Best parents' selection, Main Chain selection and so on,
please, see TrustNote-TR-2018-02.
4.4 Transaction Confirmation
As new Units are created, each Node keeps track of its current MC, as they are going to create a
new Unit for every valid Childless Unit. Current MCs may be different for different Nodes because
they may see different sets of unstable Units. The current MC will constantly change itself as new
Units arrive. However, certain parts of the MC that are old enough, will remain unchanged.
When traveling back, all MCs will come to some point, this point and any previous Units are stable
and won’t be changed by the arrival of new Units. In fact, the Genesis Unit is a natural initial stable
point. Assuming we have built a current MC based on the current set of unstable Units, and there

Page 15 of 29
are some Units that located on this MC that were previously believed to be stable, this means that
all future MCs believe they will meet the same stable Units and travel back along the same path.
If we can find a way of advancing this stable point forward in the opposite direction of the Genesis
Unit, then we should be able to prove the existence of such stable point by Mathematical Induction.
Those Units referenced by this stable point will get a definite MCI, and all messages contained in
these Units will also get confirmed. For more information about Transaction Confirmations, please,
see TrustNote-TR-2018-02.
4.5 Transaction Fees and Mining Reward
The transaction fee must be paid for confirmation and storing the transaction on the network. The
node, proposed the transaction, calculates the unit fee based on the number of bytes generated and
pay it instantaneously. The transaction fee is divided into two parts:
60% Referencing Fee
40% Attestation Fee
The Referencing fee will be obtained by the child of the Unit (This indicates that users can earn
TTT as they are generating new Units, by referencing a Childless Unit).
In TrustNote, the growth of DAG-ledger and the TrustME consensus are asynchronous. At the end
of each consensus round, top eighteen Super Nodes will be selected and they will be given the
authority to submit the TrustME Units. Before the MC becomes stable, there is no way to decide
which TrustME Units located on the MC, or to evaluate the effectiveness of the TrustME Units’
references. After each consensus round, and when every TrustME Unit issued by all Attestor
becomes stable, the amount of Attestation Reward for each Attestor can be determined. The
Attestation Fee will be added to the attestation bonus pool of the current consensus round. The
Attestors (on the current consensus round) who their corresponding TrustME Units are located on
the MC will receive the Attestation Fee (The share of each of them will be determined by the
number of the TrustME Units they generated on the MC in the current round).
Sending TrustME and PoW Units also needs to pay the transaction fee. The calculation of
transaction fee is the same as sending ordinary Units. Since TrustME Units usually containing more
information and taking up more storage space than ordinary Units, so its transaction fees are a bit
higher, thus this encouraging other Units to reference the TrustME Units.
TrustME consensus is carried out periodically with a certain number of Attestors who will be
selected for each round. Each time when the TrustME consensus is achieved, the first TrustME

Page 16 of 29
Unit generated by the current round’s Attestors must contain the list of Attestation Rewards for the
(i-2)th
consensus round. In the same consensus round, TrustME Units generated by other Attestors
no longer contain the Attestation Reward, instead they validate and reference the first TrustME
Unit to confirm the Attestation Reward of (i-2)th
consensus round. By doing so, the capabilities of
Attestors are weakened, thus preventing malicious Super Nodes from disturbing the Attestation
Reward income of Attestor of (i-2)th
consensus round, by obtaining the attestation authority
multiple times. For more information about rewards calculation, Coinbase message and so on
please, visit TrustNote-TR-2018-02.
4.6 TrustME-PoW
TrustME-PoW is a consensus mechanism which selects a small number of super Nodes as Attestors
using proof of work at each round and determines the priority of Attestors accordingly. The
TrustME-PoW consensus algorithm is executed every 5 minutes, each time when a consensus is
reached, eighteen Super Nodes will be selected as Attestors. These Attestors have the authority to
send TrustME Units and are rewarded accordingly.
TrustME-PoW is based on the Equihash algorithm, using BLAKE2 as the underlying hash function,
to reduce the unfair advantages of ASIC mining, and to encourage equitable participation from
more Super Nodes, thus making the probability distribution of Super Nodes becoming Attestor
more reasonable. The input of the Equihash algorithm include Current Round’s Number, Seeds,
the Difficulty Factor and etc. The Current Round Number begins at 0, incrementing by 1 after each
round. The Seeds of each round of consensus are calculated from the Seeds of the last round of
consensus and the consensus results, which can be retrieved publicly and verified. The Difficulty
Factor is calculated from the average computing power of the whole network, and the average time
interval of consensus is controllable by adjusting the Difficulty Factor.
TrustME Units must comply with the previously mentioned Unit inter-reference rules. The
TrustME Unit can only reference unstable Unit and must validate the Units it references, and the
correctness of the "Child-Parent" relationship, until the stable MC unit is verified. TrustME Units
are encouraged to reference multiple Best Parent Units that are not stable yet, thus to accelerate the
stabilization of the Units and promote DAG-ledger’s forward advancement and convergence.
Only when the TrustME Unit becomes the Unit on the MC, the corresponding attestation reward
can be obtained. In a consensus round, the TrustME Units on the MC calculate their proportion of
current consensus round’s attestation reward according to the number of effective references.

Page 17 of 29
When each TrustME Unit becomes the MC Unit and stabilizes, the TrustME Unit’s effective
references are calculated. For more in depth information about TrustME-PoW and related topics,
please visit TrustNote-TR-2018-02.
4.7 TrustME-BA
TrustME-BA is a consensus mechanism based on Verifiable Random Function (VRF) and
Byzantine Agreement (BA) algorithm, it randomly selects a small number of Super Nodes as
Attestors and determines the priority of the Attestors.
TrustME-BA is executed once every minute, and every time when a consensus is reached, a number
of Super Nodes will be selected as Attestors in random. Attestors have the authority to send
TrustME Units which must comply with DAG consensus’ Parent-Child inter-reference rule. Once
the TrustME Unit sent by the Attestor Node stabilizes on the MC, the Attestors will get the
attestation reward. When transactions are active and new Units continued to be generated, Attestors
will receive their Attestation rewards in a short time. When the transactions are less active or even
in the worst cases when there is no new Units been generated in the current BA round, Attestor
Node will receive its attestation reward after their TrustME Units become stable MC units.
4.7.1 Design Goals
TrustME-BA consensus mechanism is designed to achieve the following two goals:
Security
With significant probability, all Super Nodes will agree on the set of selected Attestor Nodes, which
means when most of the honest Super Nodes accept a consensus result, then any consensus
processes in the future can be traced back to this consensus result. TrustME-BA assumes:
Honest Super Nodes hold more than two thirds of total TTT in circulation.
Attackers can participate in consensus and receive the appropriate rewards.
The rationale for this assumption is that in order to attack TrustME-BA successfully, attackers must
invest enough TTT tokens. TrustME-BA assumes an attacker can control a certain amount of target
Super Nodes, but he cannot control a large quantity of Super Nodes to hold more than two thirds
of total TTT in circulation.
Robustness

Page 18 of 29
Beyond Security goals, TrustME-BA assumes network reachability to rigorously determine the
priorities among Attestor Nodes. This goal is that all Super Nodes can reach a consensus on a new
set of Attestor Nodes selected within one minute. To establish a robust platform, TrustME-BA
makes a strong synchronization assumption that all honest Super Nodes send messages to most of
other honest Nodes within a known time frame. This assumption acknowledges that an attacker
may control some of the honest Super Nodes, but he cannot control the entire network in a large
scale nor divide the network.
4.7.2 Final Consensus and Tentative Consensus
TrustME-BA has two types of consensus status:
Final consensus
Tentative consensus
When a Super Node reaches final consensus, it means that any other Super Nodes also reached
final consensus. In other words, Super Nodes in the same round must agree on the same consensus
result (tentative consensus), regardless of the strong synchronization assumption. Tentative
consensus means that some Super Nodes may have reached a tentative consensus on other TrustME
Units, and no Super Node has reached the final consensus. All TrustME Units must directly or
indirectly reference the TrustME Units that were generated before, which ensures the security of
TrustME-BA.
There are 2 cases where TrustME-BA may reach tentative consensus. In the first case scenario
(with low probability), if the network is strongly synchronized, an attacker may, let TrustME-BA
reaches tentative consensus. In this case, TrustME-BA will not reach final consensus, and will not
confirm that the network has strong synchronization. But after a few rounds, it is highly probable
that the final consensus will be reached. In the second case, if the network is weakly synchronized
and the entire network is compromised by the attacker, in such case TrustME-BA can reach
tentative consensus and selects different sets of Attestor Nodes, multiple consensus forks are
formed. This will prevent TrustME-BA from reaching final consensus, because the Super Nodes
are divided into different groups, and the groups do not agree with each other. In order to start the
activity again, TrustME-BA will be executed periodically until the disagreement is resolved. Once
the network returns to strong synchronization status, final consensus will be reached in a short
period of time.

Page 19 of 29
4.7.3 Lottery Algorithm
The lottery algorithm is constructed on the basis of a Verifiable Random Function (VRF) that
selects a random subset of Super Nodes based on the weightings of each Super Node participating
in the TrustME-BA consensus. The probability of a Super Node being selected is approximately
the same as the ratio of its own weighting to total weighting. The randomness of the lottery comes
from the VRF and a publicly verifiable random seed. Each Super Node can verify whether it is
selected using the random seed.
Definition of VRF: Given an arbitrary string, the VRF outputs the hash value and the result of the
proof.
< ℎ𝑎𝑠ℎ, 𝜋 > ← 𝑉𝑅𝐹𝑠𝑘(𝑠𝑒𝑒𝑑||𝑟𝑜𝑙𝑒)
The hash value (hash) is uniquely determined by the private key (sk) and the given string
(seed||role), hash is not distinguishable from a random number without knowing the sk. The result
of the proof π enables those Nodes who know the public key corresponding to the sk can verify
whether hash is associated with seed or not. seed is randomly selected and publicly available, and
the seed of each round is generated from the seed of previous round. The lottery algorithm supports
role assignment, such as selecting participants at a certain point during the consensus process.
All Super Nodes execute the lottery algorithm to determine whether they are authorized Attestors.
The selected Super Nodes broadcast their lottery results to other Super Nodes through the P2P
network. Note in order to defend against a Sybil attack, the probability of selecting a Super Node
by lottery is directly proportional to the Super Node's own weighting. A Super Node with a high
weighting may be selected multiple times, for which the lottery algorithm will report the number
of the Super Node been selected. If a Super Node is selected multiple times, it will be treated as
multiple different Super Nodes.
4.7.4 Byzantine Agreement
The Byzantine Agreement (BA) negotiates and decides the attesting priority for each selected Super
Node and provides such proof. There are several steps that need to be taken to reach an agreement
and the BA algorithm will be executed multiple times. Each negotiation starts with a lottery and
all Super Nodes check if they are selected to participate in the current BA; the participants broadcast
a message containing the choice of attesting priority; then each Super Node initializes the BA

Page 20 of 29
algorithm with the set of Attestor Nodes they collected. These steps are repeated until there are
enough participants to reach consensus at a given step. The above steps are not synchronized
among the Super Nodes, and each Super Node immediately checks the result of the new
participant’s selection after the previous steps end.
An important feature of the BA algorithm is that participants do not maintain its private state except
saving the private keys, therefore, the participants can be replaced after each step to reduce the
attack to the participants. When the network is strongly synchronized, the BA algorithm ensures
that if all the honest Super Nodes are initialized with the same content, final consensus can be
reached with very few steps. In the case of a strongly synchronized network, if there is a small
number of attackers, all honest users can still reach final consensus within limited steps.
5. SMART CONTRACT
TrustNote has non-Turing-complete declarative Smart Contracts designed to interpret the
expectations of the contracts, to support Boolean operations while increasing the support for
variable operations, contract data access and it does not support stacks and jump instructions.
Therefore, it does not only retain the benefits of a declarative contracting language such as being
easy to understand, and having strong security, furthermore enhances the expression of the
contracting language. TrustNote also improves the storage capabilities for Smart Contracts’
internal data, hence greatly improving the support to complex application scenarios. Comparing
with Turing-complete Smart Contracts (e.g. Solidity), TrustNote enjoys the advantages of low
complexity, light weight and high performance smart contracts, while making it easier to write the
contracts with less probability of making errors.
There is no “account” in TrustNote, TTT is stored in the form of Unspent Transaction Output
(UTXO) at the address of a tamper-resistant distributed ledger. In TrustNote Smart Contracts, an
address is defined as a Boolean expression that its value can be “true” or “false”. If the signature
provided by the transaction is valid and generated by the private key corresponding to this public
key, the result of this expression is equal to “true”, otherwise it will be evaluated as “false”. All
expressions in a Smart Contract eventually result in a Boolean value, and multiple Boolean
expressions can be combined using Boolean operations. For example, the following definition
requires two signatures:
["and", [
["sig", {pubkey: "one pubkey"}],

Page 21 of 29
["sig", {pubkey: "another pubkey"}]
]]
To spend funds from the address equal to the hash of the above definition, two signatures must be
provided. As you have noticed, we use JSON to construct the language expressions, this allows us
to use existing, well-supported, well-optimized JSON parsers without having to create a new one.
The "Or" operation can be used to request the signature from one of the listed public keys.
["or", [
["sig", {pubkey: "laptop pubkey"}],
["sig", {pubkey: "smartphone pubkey"}],
["sig", {pubkey: "tablet pubkey"}]
]]
The above expression is useful when you want to control 3 devices from the same address, these
devices may be your computer, cell phone, and tablet.
Operations can be nested:
["and", [
["or", [
]],
["sig", {pubkey: "smartphone pubkey"}]
]]
A definition can require a minimum number of members in a large collection must be true, see the
2-of-3 signature below for example:
["r of set", {
required: 2,
set: [
["sig", {pubkey: "smartphone pubkey"}],
]
}]
The above expression implies the security and reliability requirement of any two signatures. If one
key is missing, the address is still usable, and the definition can still be modified to set a new value
for the missing third key.

Page 22 of 29
Also, different entries can be given different weightings, of which a minimum requirement is set:
["weighted and", {
required: 50,
set: [
{weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },
{weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },
{weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },
{weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
]
}]
A definition can reference other addresses:
["and", [
["address", "ADDRESS 1 "],
["address", "ADDRESS 2"]
]]
Delegates signing to other addresses is useful for building shared control address (addresses
controlled by multiple users). This syntax gives users the flexibility of changing the definition of
their own address, without bothering other users.
A sub-definition enables transactions to be jointly signed by other addresses.
["cosigned by", "ANOTHER ADDRESS"]
A very useful operation can be used to query the data previously stored in TrustNote:
["in data feed", [
["ADDRESS1", "ADDRESS2", …],
"data feed name",
"=",
"expected value"
]]
If there is at least one message that is already stored in the database and has "data feed name" equal
to "expected value", the calculation results of the operation are “true”. The data feed sent to the
distributed database must be from a trusted third-party data source (oracle) whose addresses are
"ADDRESS1", "ADDRESS2", ... The oracle on the chain is a very powerful thing and we call
them “on-chain oracles”.
For example, this address definition represents a binary option.

Page 23 of 29
["or", [
["and", [
["address", "ADDRESS 1"],
["in data feed", [["EXCHANGE ADDRESS"], ["EURUSD", "+", "0.200"], ">", "1.1500"]]
]],
["and", [
["address", "ADDRESS 2"],
["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]
]]
]]
The above expression relies upon two oracles, one is the euro/dollar exchange rate, and the other
is the release time. Initially, both parties prepare funds for the addresses defined by this expression
and provide them with their respective share of funds; then, if the euro/dollar exchange rate
announced by the exchange address plus 0.200 ever exceeded 1.150, address 1 takes away all the
funds. Before 1st October 2016, and after the timestamp issued by the oracle, if the above-
mentioned condition does not happen, address 2 takes away the entire funds.
In another example, a consumer buys goods from an online merchant who they didn’t trust, if the
goods are not sent to him and he wants a refund, the consumer can pay the money to a shared
address defined as follows:
["or", [
["and", [
["address", "MERCHANT ADDRESS"],
["in data feed", [["FEDEX ADDRESS"], "tracking", "=", "123456"]]
]],
["and", [
["address", "BUYER ADDRESS"],
["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]
]]
]]
This definition relies on all tracking numbers issued by the FedEx oracle. If the goods are
dispatched, the merchant can unlock the funds according to article 1. If the goods are not dispatched
before the agreed date, the consumer can take back his money.
A definition can also include enquires to the transaction itself. For example, it can be used to
program restricted orders on a distributed market. Assumes a user want to buy 1200 units of asset,
but he won’t pay anything more than 1000 Notes (tokens), and he don’t want to be sitting online
waiting for the seller. What he would like to do is simply post an order onto the market so it will

Page 24 of 29
get executed when the matching seller arrives. He can create a restricted order, sending 1000 Notes
to the address defined by the following expression:
["or", [
["address", "USER ADDRESS"],
["and", [
["address", "EXCHANGE ADDRESS"],
["has", {
what: "output",
asset: "ID of alternative asset",
amount_at_least: 1200,
address: "USER ADDRESS"
}]
]]
]]
The first “or” alternative allows the user to get back his Note and cancel his order whenever he
wants. The second alternative commissions the market and authorizes it to spend money, provides
another output on the same transaction to pay least money for 1,200 units’ alternative asset to the
user's address. The market will publish the list of orders, allowing sellers to discover the list of
orders, make a transaction that can exchange the assets, and co-sign with the market.
6. TRUSTNOTE PLATFORM AND APPLICATIONS
Issuing and trading tokens are one of the key applications in blockchain technology, but from a
practical point of view, trading any tokens must be supported by low-level wallet software, and the
wallet software must be upgraded when a new type of token is issued, or new transaction types are
added, because the old wallet may not support new tokens or new features. Ethereum is a very
good platform which supports issuing new tokens, defining transaction types, etc., however writing
Smart Contracts for Ethereum requires specialized expertise which is not easy, Turing-complete
Smart Contracts appear to be too heavy and error-prone for many simple asset-based applications
such as issuing and trading tokens. "The DAO Attack" incident is not by accident, the security of
Smart Contracts and the ease of writing applications need more attention, the recent “CryptoKitties
congestion” incident also echo the evidence that Ethereum's transaction performance needs to be
further improved.
The TrustNote Development Team is committed to moving forward along the roadmap established
in the early stages of the project. Driven by technological innovation and supported by the open-

Page 25 of 29
source community, TrustNote will keep focus on creating an easy-to-use, decentralized, low-level
blockchain allowing new innovative ideas to run smoothly on the blockchain network, making user
friendly blockchain applications accessible to everyone.
Figure 6-1 Roadmap
Main Chain and the Multi-Platform Wallet: Build the Main Chain, develop basic version of
wallet and release it to the public, and token issuance;
Open Source: TrustNote is an open-source project and will be hosted on Github. The first
Github release is scheduled on Q1 2018. A development team will be set up including
TrustNote employees and community developers. Every developer can contribute to the
project and the changes will be submitted by the development team upon code review;
Developer Community: Communicate with developers, receive questions and bug reports,
publish software releases, technical articles and roadmaps, integrate the most advanced
blockchain technologies by interacting with the world blockchain development community;
Wallet Evolution:
Multi-platform: Use cross-platform language Node.js for development, support multiple
platforms such as Windows, Mac OS, Linux, Android, iOS, Chrome, Firefox, ensure
safety usage of wallet inside web browser;
Micro-wallet: TrustNote team is committed to develop the wallet for Internet-of-Things

Page 26 of 29
(IoT) including micro-wallet protocols and micro-wallet application clients for IoT
devices. Rust, a concurrent and efficient system programming language is selected to
develop micro-wallet protocols and micro-wallet clients. It could fundamentally resolve
the problems exists on IoT devices, such as lack of computing and storage resources, and
inability to complete autonomous value exchange between devices etc., to ultimately
empower IoT devices with blockchain technology.
Crypto-Token Platform:
Customized token issue, distribute, trade, destroy, manages the entire life cycle of crypto-
token;
Decentralized Token exchange, registration free, supports anonymous transactions;
Support Bitcoin, Ethereum, Litecoin, Dash and many other mainstream crypto-currency
wallets;
Unify Token Wallet (TrustNote wallet) manages user issued assets, the transaction
consumes TTT, the actual transaction costs equal to the bytes the transaction consumed;
Two-layer consensus mechanism ensures security while supports fast transaction
confirmation. The higher the concurrency is, the shorter the time of transaction
confirmation is;
Support third-party application extensions, asset-based application scenarios can be
created using Smart Contracts and data provided by trusted third-party. App extensions
can be downloaded from the wallet application market.
The crypto-token platform focuses on creating a decentralized platform for creating, issuing and
operating crypto-tokens. Users can easily customize their personal crypto-token and launch crowd
funding or ICOs without the need to write sophisticated Smart Contracts, thus democratizing the
access to the crypto-token issuance world. Users can also securely manage Bitcoin, Ethereum,
Litecoin and other mainstream crypto-token wallets through the corresponding crypto-token
gateways. A unified entrance for crypto-token wallet software across operating systems and
platforms are provided, and there is no need to switch between wallet software anymore.

Page 27 of 29
Figure 6-2 Architecture of Crypto-Token Platform
Typical Application Scenario:
Virtual Assets: Game equipment, live-streaming reward;
Conditional Payment: Knowledge payment, API calls, decentralized insurance;
Cryptographic Matching: Predictive market, Charity, etc.;
Off-Exchange Trading (Over-the-Counter): Token Exchange;
Social Trading: Group red envelopes, group collection;
Resource Sharing: Make full use of idle resources.
7. ISSUANCE AND DISTRIBUTION
TrustNote’s crypto-currency is called “TTT”, and “Note” is the unit of TTT, often specified
in Mega Notes (MN);
Total Issuance: 1,000,000,000 (109
) MN, fixed supply;
Initial Offering: 500,000,000 (5×108
, 50% ratio) MN, distributed by means of “coin to coin”
exchange;

Page 28 of 29
Total Attestation Rewards: 500,000,000 (5×108
, 50% ratio) MN, Attestation Rewards are
available for miners who participate in the TrustME consensus;
The Main Chain (MC) supporting PoW mining is expected to launch on Q4 2018, while users
can download the mining client and apply to become a Super Node, Super Nodes can get
attestation authority by participating in the MC consensus and then get Attestation Rewards
by issuing valid TrustME Units;
The Attestation Reward Policy allocates 6.79% of Total Attestation Rewards for the first year,
after which the yearly allocated Attestation Rewards decays year by year according to Figure
7-1. Of these, 90% of Attestation Rewards are allocated to the Super Nodes who provide valid
TrustME Units, 10% of Attestation Rewards are allocated to TrustNote Foundation to support
community operations, project incubation, and rewards to contributors etc.
Figure 7-1 Attenuation Chart of Attestation Rewards
TrustME-PoW reaches consensus at about every 5 minutes per round, with about 100,000
rounds each year, the total amount of Attestation Rewards allocated for each round equals
Attestation Rewards * 90% + Attestation Fees.
In 1st
year, Attestation Reward for each round is about 323.04 MN;
In 2nd
year, Attestation Reward for each round is about 262.39 MN;
In 3rd
year, Attestation Reward for each round is about 232.34 MN.
8. References
[1] Bitcoin Computation Waste, http://gizmodo.com/the-worlds-most-powerful-computer -
network-is-being-was-50403276. 2013.
[2] Bitcoin wiki. Proof of Stake. http://www.blockchaintechnologies.com/blockchain-
0.00%
1.00%
2.00%
3.00%
4.00%
5.00%
6.00%
7.00%
8.00%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
RATE
YEAR

Page 29 of 29
applications. As of 11 Aug 2017.
[3] Coindesk.com. Bitcoin: A Peer-to-Peer Electronic Cash System.
[4] http://www.coindesk.com/ibm-reveals-proof-concept-blockchain-powered-internet -things/
As of 11 Nov 2017.
[5] Ethereum. Ethereum. https://github.com/ethereum/. As of 12 Nov 2017.
[6] IOTA. IOTA. https://github.com/iotaledger/. As of 10 Nov 2017.
[7] Byteball. Byteball. https://github.com/byteball/. As of 10 Sep 2017.
[8] Bernstein, Daniel J, et al. High-speed high-security signatures. Journal of Cryptographic
Engineering 2.2(2012), 77-89.
[9] M. Castro and B. Liskov. Practical Byzantine Fault Tolerance. Proceedings of the Third
Symposium on Operating Systems Design and Implementation, New Orleans, Louisiana,
USA,1999, pp. 173–186.
[10] Biryukov, Alex, and D. Khovratovich. Equihash: Asymmetric Proof-of-Work Based on the
Generalized Birthday Problem. Network and Distributed System Security Symposium 2016.
[11] Gilad Y, Hemo R, Micali S, et al. Algorand: Scaling Byzantine Agreements for
Cryptocurrencies. The Symposium 2017, 51-68.
[12] C. Decker and R. Wattenhofer. Information Propagation in the Bitcoin Network. 13-th IEEE
Conference on Peer-to-Peer Computing, 2013.
[13] D. Dolev and H.R. Strong. Authenticated algorithms for Byzantine agreement. SIAM
Journal on Computing 12 (4), 656-666.
[14] A. Kiayias, A. Russel, B. David, and R. Oliynycov.. Ouroburos: A provably secure proof-of-
stake protocol. Cryptology ePrint Archive, Report 2016/889, 2016. http://eprint.iacr.org
/2016/889.
[15] S. King and S. Nadal. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake, 2012.
[16] S. Micali, M. Rabin and S. Vadhan. Verifiable Random Functions. 40th Foundations of
Computer Science (FOCS), New York, Oct 1999.

TrustNote Technical Whitepaper

More Related Content

What's hot (20)

Similar to TrustNote Technical Whitepaper (20)

Recently uploaded (20)

TrustNote Technical Whitepaper