Aidos Kuneen— A Blockless and Anonymous Cryptocurrency for the Post-Quantum Era —

Aidos Developer Aidos Foundation

January, 2018Version 0.04 (DRAFT)

AbstractIn this white paper we introduce a new cryptocurrency, Aidos Kuneen. Aidos Kuneen has been developed to deliver a fast,anonymous, blockless, decentralized and scalable solution for post-quantum era transfers with zero fees.

Aidos Kuneen employs a mechanism known as iMesh, within iMesh all transactions are directly referenced by one anotherin order to form a Directed Acyclic Graph (DAG) structure.

The inclusion of ‘SPECTRE’ allows full-nodes to determine which transactions are legitimate within the DAG structureand to reject those that are not. In addition, SPECTRE provides resilience against any attackers who may happen to gaincontrol of up to 50% of the network’s computational power.

To ensure continued security in the post-quantum era, Aidos Kuneen utilises the hash-based signature ‘XMSS’. XMSSprovides for both a small signature and a small public key size which in turn reduces network load.

In order to provide anonymity within the network, Aidos Kuneen employs AKShuffle. AKShuffle incorporates the post-quantum, zero-knowledge proof ‘ZKBoo (ZKB++)’, this allows for truly anonymous transfers throughout the entirenetwork.

To allow Aidos Kuneen to service the expected future growth of the ‘IoT’ sector we introduce an innovative new co-operative Proof of Work mechanism known as coPoW. coPoW allows a number of senders within the network to co-operatively perform the necessary Proof of Work in order to confirm transactions on the network, thus reducing thephysical processing requirements of any one sender.

Finally, we provide a simulation of the number of leaves in iMesh and we further determine the minimum number ofreference transactions required in order to converge the DAG and deliver fast confirmation times, whilst still havingminimal effect on the transaction size.

Copyright c©2017–2018 by Aidos Developer and Aidos Foundation.

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE HELD LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITHTHIS DOCUMENT, OR THE USE OF OR OTHER DEALINGS WITH THIS DOCUMENT.

This work is licensed under a Creative Commons Attribution 4.0 International License.http://creativecommons.org/licenses/by/4.0/

1

Aidos Kuneen— A Blockless and Anonymous Cryptocurrency for the Post-Quantum Era —

Contents1 Introduction 3

2 Related Works 4

3 Signature Scheme 43.1 WOTS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 XMSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 iMesh 64.1 SPECTRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.2 AKConsensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Proof of Work 9

6 Co-operative Proof of Work 9

7 AKShuffle 10

8 Network 11

9 Leaves within iMesh 11

10 Future Plans 13

11 Conclusion 13

Appendix A Results of Simulation — Number of Leaves Nleaves 15

Appendix B Results of Simulation — Growth of Ndescendant 16

List of Figures1 Generation of the WOTS+ public key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Signing with the WOTS+ private key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 WOTS+ Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Key generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 The auth path for XMSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 iMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 An example of the voting procedure within a simplified DAG structure. . . . . . . . . . . . . . . . . . . 78 Statements and finalisation of transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Cuckoo Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 An example of how AKShuffle operates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011 Aidos Kuneen network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112 Leaves within iMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113 λin = 1 transaction per minute, Nre f = 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514 λin = 1 transaction per minute, Nre f = 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515 λin = 1 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516 λin = 5 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517 λin = 10 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518 λin = 1 transaction per minute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619 λin = 1 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620 λin = 5 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621 λin = 10 TPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2

1 IntroductionBitcoin, the once obscure cryptocurrency introduced bySatoshi Nakamoto [1] in 2008, has now begun to drawmuch wider attention from both the general public andgovernments alike. Within the Bitcoin network, trans-actions are written into ‘blocks’, these blocks are thencryptographically validated by powerful computers knownas ‘miners’ using a Proof of Work (PoW) system. Oncea block has been validated it is then appended to the endof a continually growing chain of blocks aptly named‘the block-chain’. Miners are subsequently rewarded forsuccessfully validating a block by means of the transactionfees paid by senders who transact on the Bitcoin network.

Currently, blocks are added to the blockchain at a rateof approximately one every 10 minutes. The transactionscontained within the blocks consist of both input and outputaddresses, with the inputs themselves being the outputs ofprevious transactions — this provides an auditable historyof all past Bitcoin transactions within the network. In orderto prove ownership, transactions are signed by the addressowner with an Elliptic Curve Digital Signature Algorithm(ECDSA).

However, in recent years a number of problems have beenidentified with the Bitcoin implementation, including:• Limited Scalability

Within the core Bitcoin code, the maximum block sizeis restricted and blocks are unable to store transactionsonce this limit is exceeded. This in turn leads to a scal-ability problem when many transactions are broadcastsimultaneously with many of them being unable to beincluded in the current block.

• High Transaction FeesSenders are required to pay a transaction fee in or-der to incentivise the miners to include their transac-tion in a block. If Bitcoin usage continues to growand the price of Bitcoin increases, the relative valueof the fee will also increase. It no longer makes senseto send small transactions via the Bitcoin network asthe fee could easily exceed the value of the Bitcoin be-ing transacted. This forces senders to use complicatedschemes to send small value transactions (e.g. micro-payment channels).

• Poor Resistance Against Quantum ComputersAs of 2017, the development of quantum computersis still in its infancy. However, experiments have al-ready been carried out in which quantum computa-tional operations were executed on a small number ofquantum bits. Furthermore, Google has reported its in-tent to commercialize quantum technologies within thenext five years [11]. At the same time, according toShor’s algorithm [10], all algorithms based on the dis-crete logarithm problem (including ECDSA as used inBitcoin), can be easily solved with a sufficiently pow-erful quantum computer.

• Limited AnonymityThe auditable nature of Bitcoin means that in orderto spend Bitcoin, the spending transaction must refer

back to the founding transactions that came before it,these founding transactions are open to the public. Assuch, anyone is free to track the flow of BTC from ad-dress to address.

In order to address these issues, we introduce a new cryp-tocurrency, Aidos Kuneen. The Aidos Kuneen network,known as iMesh, is based on Directed Acyclic Graph (DAG)technology. In iMesh, transactions are directly referred toby other transactions and as such there are no blocks, andby extension, no block-chain. The confirmation of a trans-action is determined by the number of other transactionswhich vote for the transaction. In iMesh, we are able toachieve the benefits of scalability while completely remov-ing the requirement for miners, which subsequently re-moves the need for the associated transaction fees that wereonce required in order to incentivise mining.

Adios Kuneen has been specifically designed to provide:• Increased Scalability

In iMesh, one performs relatively simple PoW com-putations to confirm the transaction. After the trans-action is broadcast to the network, the transaction isstored into iMesh immediately. Hence, there is no needto wait for one’s own transaction to be stored. Addi-tionally there is no limitation to the size or numberof transactions that can be stored at a time. The moreiMesh grows, the greater the number of transactionsthat become involved. This means that the confirma-tion time of any single transaction will reduce as thenetwork matures.• Zero Fees

As one is no longer required to pay any transaction fees(owing to the fact that there are no miners), one is freeto transact with any amount, no matter how small with-out requiring any special knowledge or techniques.• Post-Quantum Resistance

In Aidos Kuneen we have specifically chosen a hash-based signature which provides strong post-quantumsecurity. There have been a number of different sig-nature architectures developed to provide resistance tofuture quantum based computer hardware, includingRing-LWE, Lattice and hash-based methods. However,the majority of these are not practical for our purposesdue to their large key and signature sizes. For exam-ple, the key sizes of Ring-LWE and Lattice based sig-natures weigh in at a number of kilobytes. This meansthat if we were to employ one of these methods for ex-ample, we would be forced to use long alphanumericaddress strings which are not conducive to usage bythe non-technical, general public. For a cryptocurrencythat is intended for widespread daily use this is com-pletely unsuitable.

As such, we focus our attention on the family ofhash-based signature methods instead. Some hashbased functions such as ‘SPHINCS’, provide us withthe ability to reuse the same public key multipletimes, which is a step in the right direction. How-ever, SPHINCS also suffers from the same large pub-lic key size (around 1 kilobyte) as the other meth-ods, again making it unsuitable for our application.

3

Eventually, the ‘eXtended Merkle Signature Scheme’(XMSS) was identified as being the ideal balance ofhuman usability and small key size. XMSS allows usto repeatedly utilise the same public key a large num-ber of times (1000 times or more). However, unlikeSPHINCS, XMSS has a lightweight public key of only32 bytes and a signature key size of approximately3 kilobytes. By utilising XMSS we also benefit from2128 bit post-quantum security [12].

• Strong AnonymityIn order to achieve anonymity, we utilize the postquantum, zero-knowledge, non interactive (ZKNI)proof ‘ZKBoo’ as presented in [7]. ZKBoo allows oneto transact freely across iMesh, without the need to re-veal one’s address to either the receiver or to the widernetwork.

2 Related WorksMonero1, Bytecoin2 and Zcoin3To achieve anonymity, both Monero and Bytecoin use‘ring signature’ methods as discussed in CryptoNote [13].Ring signature methods rely on a signature which utilisesa novel trapdoor function (e.g. public key encryption),unfortunately though, this feature is not found in anyof the available hash-based signature methods. Zcoinutilises a zero-knowledge, non interactive proof called ‘zk-SNARKs’, however, zk-SNARKs is not quantum secure,owing to the fact that it uses pairing-based cryptography4.

CoinJoin5Another potential option for providing anonymity, wouldbe to use ‘CoinJoin’ or one of its variants (e.g. ‘CoinShuf-fle’). However, CoinJoin requires the presence of activeparticipants at the same time one intends to send coins.This requirement could prove to be a handicap in the earlystages of adoption when the Aidos Kuneen userbase is stillsmall.

IOTA6

IOTA is a DAG based, fee-less, IoT focussed cryptocur-rency.IOTA is unique in that it makes use of ternary based signa-tures rather than standard binary. This is due to the fact thatternary based systems are theoretically more computation-ally efficient than binary based systems. In Aidos Kuneenwe have chosen to utilise traditional binary based signa-tures in order to fully utilize existing CPU features (such asSIMD instructions and dedicated SHA extensions). This de-cision was made because we believe that current generationdigital processors are already sufficiently fast and efficientenough to meet our requirements, with some IoT orientedprocessors already containing dedicated circuits for SHA-2based hash processing, e.g. ARM processors7. We also be-

1http://monero.org/2https://bytecoin.org/3https://zcoin.io/4post-quantum Zcash (https://github.com/zcash/zcash/issues/805)5https://en.bitcoin.it/wiki/CoinJoin6https://iota.org/7https://static.docs.arm.com/ddi0501/f/DDI0501.pdf

lieve that at least in the short to medium term, binary basedsystems will continue to remain the dominant form for con-sumer grade hardware.

IOTA’s confirmation process, as outlined in IOTA’s whitepaper, counts only the number of referring transactions (de-scendant transactions), we notice that as the total numberof leaves in the DAG increases (as will occur naturally),the percentage of these leaves to which descendant trans-actions refer will decrease. This means that attackers couldpotentially grow their malicious transactions faster than thenetwork. To combat this we introduce a confirmation pro-cess based on SPECTRE as presented in [9]. In SPECTREone does not only count the number of descendant transac-tions, but one also counts the number of other transactionswhich subsequently vote for the transaction. Hence, even ifthe leaves do diverge, it is difficult for an attacker to growthe confirmations of their malicious transactions.

Within the SPECTRE voting process, we still require fasterDAG convergence for rapid confirmations. The white paperas presented by the IOTA team does not specifically clarifythe convergence behaviour of the DAG, rather the white pa-per simply states that ‘One expects that the L(t) (total num-ber of leaves) remains stable’. As such, in Section 9, weadditionally simulate the behavior of leaves within iMeshin order to ensure that the DAG converges.

3 Signature SchemeAs previously mentioned, Aidos Kuneen employs XMSSas described in the RFC draft of IETF [2] as its signa-ture algorithm. XMSS itself is based on the earlier workof the Winternitz One Time Signature (WOTS+). WOTS+is a hash based signature scheme designed for single useonly, XMSS builds upon this work and delivers a mech-anism which makes it possible to sign multiple messageswith a single key.

3.1 WOTS+

Figure 1: Generation of the WOTS+ public key

Figure 1 demonstrates how a public key is generated. Inorder to generate a public key, one initially generates aseries of 67 character strings consisting of 32 byte (256bit) random binary data which becomes the private keyPriv j , j = 1 . . . 67. Then, each Priv j is hashed with theSHA-256 algorithm for a total of 15 passes. While hash-ing, each Priv j is XORed with a value from a PRF (Pseudo

4

Random Function). This XOR operation is employed to re-duce the signature size while maintaining the same securitylevel. The output of these operations becomes the publickey Pub j , j = 1 . . . 67 which is also a 67 character stringconsisting of 32 byte binary data.

Figure 2: Signing with the WOTS+ private key

Figure 2 illustrates how the message is signed. When sign-ing, one calculates a 256 bit hash H (msg) of the origi-nal message, and a corresponding 12 bit checksum fromH (msg). Next, a series of 4 bit, 67 character binary stringsNi , i = 1 . . . 67 are produced from the H (msg) and thechecksum. Each of the Priv j values are then hashed for Ni

times and XORed with the same values as used for Pubj , toproduce the signature Sigj , j = 1 . . . 67.

The checksum is used to prevent attacks from maliciousmessages. For example, if there were no checksum and anattacker were to create a message whose hash were 000. . . 0, i.e. Ni = 0, i = 1 . . . 64, then the signature would beequal to the private key and thus the private key would beexposed.

Figure 3: WOTS+ Verification

Figure 3 illustrates how the signature is verified. In order toverify a signature, a verifier first calculates Ni , i = 1 . . . 67using the same procedure for signing as explained above.Next, each Sigj is hashed (15 − Ni) times and XORed withsame values as were used to produce Pub j . The output ofwhich yields Pub′j , j = 1 . . . 67. This is then checked toconfirm that it equals the signer’s public key Pubj , j =1 . . . 67.

3.2 XMSSFigure 4 demonstrates how the public key for XMSS is gen-erated.

Figure 4: Key generation

In short, XMSS builds a tree known as a ‘Merkle Tree’, togather all public keys into one single key. This then allowsone public key to be reused many times.

Initially, one must generate 2h WOTS+ private keysPrivi j , i = 1 . . . 2h , j = 1 . . . 67 and the correspondingWOTS+ public keys Pubi j , i = 1 . . . 2h , j = 1 . . . 67(h is the height of Merkle Tree). Then, 2h number of‘ltrees’ are generated. ith (i = 1 . . . 2h) ltree is gen-erated from Pubi j , j = 1 . . . 67. One receives the roothash of the ith ltree by hashing WOTS+ public keys (i.e.H (Pubi1 |Pubi2 | . . . |Pubi67)). The root hash of ith ltree be-comes the ith leaf in the Merkle Tree. This operation is thenrepeated 2h times to fill all remaining leaves of the MerkleTree. Finally, the root hash of the Merkle Tree is calculatedby hashing together the leaves of the Merkle Tree (i.e. rootsof the ltrees). This root hash becomes the XMSS public key.

When signing, one simply selects one of the unused privatekeys and its corresponding public key. Next, one calculatesthe WOTS+ signature. The XMSS signature is the WOTS+signature with an ‘auth path’. The auth path is an additionalpiece of binary data used to calculate the root hash of theMerkle Tree (i.e. the XMSS public key).

5

Figure 5: The auth path for XMSS

With reference to Figure 5, we desire to select private key#3 for signing. A verifier can calculate node #3 from thesigner’s signature. However, in order to determine node #12the verifier will first need to determine node #4, this meansthat the auth path must include node #4. In the same manner,in order to determine node #31’s root hash (i.e. the XMSSpublic key), the signer also requires nodes #11 and #22 tobe included within the auth path. Thus, in order to performthe verification, the verifier must posses the WOTS+ signa-ture and the node values along the auth path (i.e. the valuesof nodes #4, #11 and #22). This will allow the verifier tocalculate the root hash of the Merkle Tree and determine ifthe root hash is equal to the XMSS public key.

Note that:

• Signers must record which private keys are used. In or-der to accomplish this we use the Logarithmic MerkleTree Traversal scheme as presented in [16] to provideefficient traversal with minimal storage cost.

• The public key consists of 32 × 2 bytes (the root hashof the Merkle Tree and the seed of the PRF). There isonly one PRF seed, as all pseudo random values canbe generated from a single PRF. We include the seedas a part of the signature such that the public key sizebecomes 32 bytes.

• The signature key size is approximately 3 kilobytes.

• The SHA-256 hash provides strong preimage resis-tance (i.e. an attacker is unable to guess the input fromthe output of the hash), thus it is difficult to guess theprivate key from the public key, even when using quan-tum based hardware.

Additionally, note that we are able to reuse the same publickey a number of times if h (the height of the Merkle Tree) isincreased (although this requires more time to generate thepublic keys during the initial stage).

Table 1: Merkle Tree height, estimated time for key gener-ation per CPU core, and intended users of XMSS

height #keys key generation user

10 1,024 a few seconds one time andnormal users

16 65,536 a few minutes companies20 1,048,576 ≈ 30 minutes big companies

As Table 1 illustrates, there are 3 height levels for theMerkle Tree within Aidos Kuneen. Users who desire tochange addresses for each payment or who transact lessthan 1000 times with the same address are able to useheight=10, reducing the impact of generating public keys.Heavy users such as corporate entities or merchants, whotransact more than 1000 times with one public key, woulduse either height=16 or height=20.

Note: We have chosen not to use XMSS MT , as detailedin [2]. Although XMSS MT means we do not need to gen-erate all the public keys simultaneously, the signature sizeis much larger than that of XMSS, weighing in at around 40kilobytes.

4 iMesh

4.1 SPECTREWhen a sender sends a transaction, he includes some of thetransactions previously sent by others. Figure 6 illustratesthe DAG structure of these transactions which we refer to asiMesh. When sending, the sender selects some of the leavesin iMesh (i.e. transactions which are not currently referredto by any other transactions) and determines whether or notthe parent transactions of these leaves are valid. After de-termining the parent transactions are valid the leaves areincluded in the senders transaction.

Figure 6: iMesh

Unlike block-chain based networks such as Bitcoin, wherea block refers only to the preceding block, a single trans-action in a DAG refers to many other transactions withinthe DAG. With block-chain technology, the chain grows ina linear sequence (i.e. one block at a time), whereas withina DAG the interlinked nature of the transactions allow it togrow simultaneously in all directions, thus leading to supe-rior scalability compared to block-chain based systems.

However, this interlinked nature is not without its draw-

6

backs when it comes to conflicting transactions. For exam-ple, assume Alice’s address holds a total of 10 coins. Shesends 10 coins to Bob in transaction T1, and then withoutthinking she sends 10 coins to Cathy in another transactionT2. Alice has inadvertently attempted to spend the samecoins twice (this is known as a ‘double spend’) and as aresult these two transactions are now in direct conflict. In ablock-chain based system, once one of the conflicting trans-actions has been written into a block, the other will be neverstored, (i.e. if T1 receives at least one confirmation beforeT2, then T2 will be rendered invalid). On the other handwhen there are conflicting transactions (highlighted in redin Figure6) within iMesh, it is difficult to determine whichis valid. To solve this problem, Aidos Kuneen adopts thevoting mechanism as presented in ‘SPECTRE’ [9].

Figure 7: An example of the voting procedure within a sim-plified DAG structure.

In SPECTRE, one counts the number of voters for each ofthe conflicting transactions. Figure 7 shows the voting pro-cedure. As we can see, transactions X and Y are in con-flict. Transaction X and transactions 6–8 vote for transac-tion X, as they only see X in their past, and not Y. Similarly,transaction Y and transactions 9–11 vote for transaction Y.Transaction 12 votes according to the majority of the votesfrom the other transactions (except for transactions 10, 11and 12). All transactions from 1–5 vote for transaction X asthey see more X voters than Y voters. As a result, the totalnumber of X voters is greater than Y voters, therefore X isaccepted as the legitimate transaction and Y is rejected.

The rules regarding the SPECTRE voting procedure aresummarised as follows:

1. Transactions which only have transaction X as the par-ent can only vote for transaction X. (transactions 6–8and 9–11)

Honest transactions gain votes over transactions thathave been secretly withheld by dishonest parties, ashonest nodes continue to add new transactions thatsubsequently vote for the honest transaction.

2. Transactions which have both X and Y as a parent(transaction 12) vote for which ever one has the ma-jority of voters.

This system guarantees majority amplification, asthese transactions add votes that reinforce previous de-cisions.

3. Transactions which do not have both transactions Xand Y as parents vote for which ever has the majorityof voters (transaction 1–5).

This rule allows amplification of the votes of parentsof transaction X (transaction 1–4). This is necessaryto counter a ‘pre-mining attack’ scheme, i.e. the at-tacker builds blocks and withholds them from the net-work. Due to the fact that honest transactions tend tohave a greater number of ancestor transactions, an hon-est transaction should receive more votes by means ofrules 1 and 2.

Note: SPECTRE is resilient against attackers with up to50% of the network’s total computational power, and notthe traditional 33%, as is demonstrated in [9].

Additionally, in iMesh receivers must also wait for theirtransaction to be confirmed by a sufficient number of othertransactions (much like waiting for a number of ‘confirms’in Bitcoin) prior to spending. Reference [9] provides guid-ance on how long receivers should wait before trusting anew transaction. For comparison, let’s assume that we willwait for 5 confirmations before accepting a payment onthe Bitcoin network. Let’s also assume that an attacker hasmanaged to gain control of 30% of the total hash powerin the Bitcoin network. The possibility of success of suchan attack is 17.8%[1]. Similarly, in iMesh with the SPEC-TRE voting scheme employed, once a transaction (Tx A)has received approximately 130 referrals the probability ofa fraudulent (intentionally conflicting) transaction (Tx B)being accepted as legitimate in place of Tx A has reducedto 17.8%. As the iMesh network grows and the frequencyof transactions increases, the waiting time required for atransaction to be verified as legitimate by the network willdecrease (i.e. the larger the network grows the faster it be-comes). Conversely, when the network is small, the waitingtimes are very long, the network hash power is also likelyto be quite small and this is an opportunity that an attackermay attempt to exploit. In order to prevent this potentialattack vector, we introduce a mechanism known as ‘AK-Consensus’ (as discussed in Section 4.2), to confirm trans-actions between trusted full-nodes while iMesh is still in itsinfancy.

In the voting scheme, senders have an incentive to refer toas many transactions as they can due to the confirmationspeed of the sender’s transaction being directly related tothe number of referring transactions. If a sender were torefer to only a small number of transactions, the receivercould potentially reject the payment as it would take a sig-nificant amount of time for the transaction to be validatedand for the receiver to receive the coins.

It must also be noted that if there are many leaves withiniMesh, the possibility in which any one leaf is referred toby a new transaction would reduce. To combat this we needto carefully consider how many transactions should be re-ferred to by any one single transaction. We will explore thisissue in greater detail within Section 9.

7

4.2 AKConsensusAs mentioned in the previous section, we must assume thatduring iMesh’s infancy period an attacker with access tosufficient resources could realistically command the major-ity of the total network hash power. It is for this reason thatwe are therefore unable to fully trust the SPECTRE consen-sus mechanism during the early stages of network growth.Thus we must introduce ‘AKConsensus’, a temporary sys-tem which utilises a Federated Byzantine Agreement (FBA)based on the ‘The Ripple Protocol Consensus Algorithm’along with a semi-trusted model as detailed in [18], in or-der to validate transactions until such time as the SPECTREconsensus mechanism can take over.

Within the Ripple Protoco,l the FBA process is used in or-der to confirm the validity of all transactions. A similar pro-cess, referred to as ‘AKConsensus’ has been adopted forAidos Kuneen, however, it should be noted that the im-plementation of this process within Aidos Kuneen differssignificantly from that of Ripple. With AKConsensus inplace, a group of trusted nodes periodically review a ran-domly selected transaction from within iMesh. If this groupof trusted nodes reaches an agreement on the validity ofthis transaction, the transaction becomes known as a ‘State-ment’, and now serves to act as a milestone within the net-work.

The process of consensus is as follows:

1. Each full-node defines the addresses of trusted nodeswithin their trusted list.

2. One of the full-nodes selects a transaction for reviewand broadcasts it to the trusted nodes within theirtrusted list. This transaction is now referred to as a‘Candidate Statement’.

3. Each trusted node initialises T to 50%.

4. Each trusted node reviews the legitimacy of the Can-didate Statement based on its local history.

5. If a trusted node deems the Candidate Statement to belegitimate, it then broadcasts a ‘yes’ vote to the full-nodes by which it is referenced. If the Candidate State-ment is deemed to be fraudulent it is subsequently dis-carded.

6. If a full-node does not receive a minimum of T% of‘yes’ votes from the nodes on its trusted list within acertain period, the Candidate Statement is discarded.

7. Each trusted node increases T = T + 10%.

8. Step 5. is repeated

9. The final round requires a minimum of T = 80% of afull-node’s trusted nodes in agreement in order to ac-cept the the Candidate Statement as being legitimateand elevate it to the status of Statement.

Note: In order to be accepted as a Statement, a CandidateStatement must have a valid transaction structure and mustexist within iMesh.

Figure 8: Statements and finalisation of transactions

Figure 8 illustrates how Statements act as milestones forother transactions. Full-nodes regard Statements as an “ab-solute truth” and any conflicting transactions are discardedlocally by each full node. Subsequent transactions that arereferred to by a Statement become known as FinalisedTransactions.

The numbered transactions in Figure 8 show how transac-tions are finalised by the Statements that reference them,e.g. the transactions designated with #2 are finalised byStatement #2.

The rules employed by AKConsensus in order to determinethe validity of conflicting transactions are as follows:

• The transaction which is finalised by the youngestStatement is deemed to be valid, and all others are con-sidered to be invalid.

• If conflicting transactions are finalised by the sameStatement, the transaction which possesses the oldertime stamp is deemed to be valid.

• If both transactions possess the same time stamp, thetransaction which has the smaller hash is deemed to bevalid.

AKConsensus requires a minimum of 80% agreement be-tween trusted nodes in order to accept a Candidate State-ment, and by extension, 20% or more in order to reject aninvalid Candidate Statement.

While it is acknowledged that the introduction of AKCon-sensus does directly contradict Aidos Kuneen’s ultimate vi-sion of a completely decentralised cryptocurrency, AKCon-sensus, for the reasons outlined previously, is accepted to bea “necessary evil” until such time as the network has ma-tured to the point where it is capable of resisting attack onits own. Additionally, Aidos Kuneen believes very stronglyin providing a completely fee-less product to its user base,the presence of AKConsensus allows the realisation of thisvision from day one, with no need to resort to alternative,‘incentivised’ mechanisms for early network protection.

8

5 Proof of WorkWhen sending a transaction, senders must first perform‘Proof of Work’ (PoW), similar to that which is performedby miners in the Bitcoin network. The mandatory perfor-mance of PoW prior to sending a transaction is necessary inorder to protect iMesh from DDoS attacks via spam transac-tions and double spend attacks (as previously discussed). Inaddition, PoW is used to distribute the computational work-load of validating transactions between all participants inthe network. This ensures that the network does not becomeconstrained by the limitations in processing capabilities ofa handful of ‘masternodes’, but instead remains completelyfree to scale as required. During the PoW operation eachtransaction is assigned a length L, of 32-bit integer fieldsknown as a ‘nonce’. The value of this nonce is set such thatthe hash of the block will contain a leading run of zeros andform a series of ‘Cuckoo Graphs’ with cycle length L (as isdiscussed in more detail below). The leading run of zeroesdetermines the time required for the PoW operation and hasbeen chosen to produce an average PoW time of 5–10 min-utes.

For PoW operations, Aidos Kuneen implements the CuckooCycle as discussed in [14]. The Cuckoo Cycle arises by theinsertion of keys into a ‘Cuckoo Hashtable’ which naturallyleads to the cyclic formation of random bipartite graphs.A Cuckoo Hashtable consists of two identical tables, eachwith a unique hash function which maps a key to a tablelocation (this provides two possible locations for each key).Upon arrival of a new key, its table location is first deter-mined. If both possible locations are currently occupied byexisting keys, then one is extracted and inserted into itsalternate location (potentially displacing yet another key).This process is subsequently repeated until either a vacantlocation is identified, or a predetermined number of itera-tions is reached. This process leads to the formation of cy-cles in what is referred to as a ‘Cuckoo Graph’. The CuckooGraph is a bipartite graph with a node at each location, andan edge for every inserted key, connecting the two locationsat which the key can reside.

Figure 9: Cuckoo Graph

The first diagram in Figure 9 illustrates the directed CuckooGraph on N = 8 + 8 nodes after edges (2, 15), (4, 9), (8, 5),(4, 15), (12, 11), (10, 5) and (4, 13) are added. In order toadd the 8th edge (10, 11), we follow the paths 10→ 5→ 8and 11 → 12 to find the different roots 8 and 12. Sincethe latter path is shorter, we reverse the path to 12 → 11such that we can add the new edge as (11 → 10), resultingin the middle diagram. In order to add the 9th edge (10,13) we now find the path from 10 to be the shorter one, sowe reverse the path and add the new edge as (10 → 13),resulting in the right diagram. When adding the 10th edge(8, 9), we find the paths 8→ 5→ 10→ 13→ 4→ 15→ 2

and 9→ 4→ 15→ 2 with equal roots. In this case, we cancompute the length of the resulting cycle as 1 plus the sumof the path lengths to the node where the two paths join. Inthe diagram, the paths join at node 4, and the cycle lengthis computed as 1 + 4 + 1 = 6.

The Cuckoo Cycle has been chosen as the PoW function foriMesh, due to the following reasons:

• We anticipate significantly higher daily transactionvolumes compared to that of Bitcoin, this is due to thefact that unlike Bitcoin, the fee-less nature of AidosKuneen means the economic disincentive against fre-quently sending small transactions is removed. Thus,Aidos Kuneen requires a very fast verification method.

• Unlike other typical PoW algorithms such as Cryp-tonight or Scrypt which are typically quite resourceintensive, full-nodes are able to verify the validity ofnonces much faster when utilising the Cuckoo Cycle.

• Unlike Bitcoin, in which PoW is performed only onthe blocks themselves, in Aidos Kuneen PoW must beperformed for each individual transaction. As there aresignificantly more individual transactions than thereare blocks, Aidos Kuneen therefore requires morepower to perform PoW verification. Thus, it is essen-tial that a highly efficient means of verification, suchas the Cuckoo Cycle is employed.

• In order to prevent an attacker from being able to prop-agate fraudulent transactions throughout the network,specialist hardware such as ASICs and FPGAs shouldnot provide any advantage. As the PoW time is mainlydominated by memory access speed, specialist pro-cessing hardware is essentially rendered ineffective.

The following Cuckoo Cycle parameters will be used forPoW operations:

• cycle length L = 20 (To minimize the size impact ontransactions).

• number of nodes N = 225 (To provide memory usageof around 128MB).

• easiness N/M = 100%, (M: number of edges) (To pre-vent optimizations by edge trimming).

6 Co-operative Proof of WorkTo cater specifically for IoT devices (whose performanceis typically quite low), we introduce a novel co-operativeProof of Work mechanism known as coPoW. By utilisingcoPoW, the network is able to group a number of unver-ified transactions together into a single, larger transactionknown as a ‘Batch’. This allows the senders of the individ-ual transactions within the Batch to effectively pool theircomputational power into validating the Batch as a unit,rather than just their own individual transactions. coPow ef-fectively acts like a decentralised version of a Bitcoin min-ing pool and allows large numbers of lower powered de-vices to interact directly with the network as if they were asingle, much more powerful device.

9

coPoW functions as follows:

1. A sender wishing to participate in coPoW broadcasts arequest to network via a full-node.

2. Others who wish to participate or are already perform-ing coPoW respond to the request.

3. The sender joins the coPoW group

4. If the group is not yet established a process of leaderselection is performed, if the group is already estab-lished then the new device receives the identity of theexisting leader.

5. The sender sends his transaction to the leader who thenmixes it with the transactions from all the other partic-ipants to form a Batch.

6. All senders commence PoW on the Batch.

7. The sender periodically sends the result of their ‘PoWfor proof’ (which meets the requirement for the ‘targetfor proof’) to the leader.

8. The sender periodically receives the PoW results fromother parties via the leader.

9. If any of the parties submit incorrect results they areejected from the group.

10. If any of the parties fail to submit their results within aset period of time, the leader ejects that party and thendelivers a restart command to all remaining parties.

11. The process continues until one of the parties success-fully solves for the ‘final hash’, after which PoW iscompleted and the group is disbanded.

Parties participating in a coPoW group must periodicallysend some of their PoW results to the leader to prove thatthey are actively participating in the group. This preventsfree-loading by parties who join the group but do not intendto actively contribute. The target for proof threshold is setsuch that the hash is less complex than the final hash, this isimportant to ensure that devices with limited computationalcapacity are able to successfully meet the target for proofwithin the required time period. The target for proof itselfcan be variable. For example, target for proof = final tar-get ×2−5 could be adopted for groups of low capacity IoTdevices, and the target for proof = final target ×2−2 couldadopted for normal desktop PCs.

For added anonymity, participants in a coPoW group havethe option to utilise the Tor network for all communicationsbetween themselves and the group.

7 AKShuffleFor increased anonymity we employ AKShuffle. WithinAKShuffle we utilize a zero-knowledge, non-interactive(ZKNI) proof for anonymous transactions. By utilisingZKNI, one can prove that their value satisfies a set of func-tions without the need to reveal their secret key. For exam-ple: Alice has input x and key k for an encryption functionfk (x), and shares y = fk (x) with Bob. Bob wants to knowif Alice really has key k, but Alice doesn’t want to reveal hersecret key to Bob. By employing ZKNI, Alice can prove to

Bob that she really has key k without ever actually havingto reveal the key itself.

Aidos Kuneen utilizes ‘ZKBoo (ZKB++)’ as presentedin [8] as its ZKNI mechanism. ZKBoo requires only the useof a hash and an AES encryption function which has beenshown to be quantum secure [17].

Figure 10: An example of how AKShuffle operates

With reference to Figure 10, the operation of AKShuffle isdescribed as follows:

Any user who desires to shuffle their tokens simply sendsthem to an AKShuffle address. The shuffle address is anoutput of the encryption fkmy (xmy ) with key kmy , wherekmy is the secret key and xmy is the public input. If atany point the user desires to withdraw their shuffled to-kens they simply create a transaction which sends the to-kens to their normal address PKmy2 (i.e. their XMSS publickey). The transaction contains the user’s AKShuffle addressfkmy (xmy ) along with other user’s AKShuffle addressesfk1 (x1), fk2 (x2) . . . fkn (xn ) as input addresses. This meansthat nobody knows which address has actually been used forthe withdrawal. In order to prove ownership the user com-pletes the ZKNI proof by proving they know kmy such thatone of the AKShuffle addresses listed as an input equalsfkmy (xmy ). The transaction also includes the user’s pub-lic input xmy in order to prevent to the reuse of the shuf-fle address. It is also important to point out that the useris required to withdraw the full amount that they originallydeposited, the system will not allow partial withdrawals ofthe user’s balance as reuse of a shuffle address is strictlyforbidden in order to maintain anonymity.

Note: Transactions used for AKShuffle and transactionsuser for normal payments are completely different. AK-Shuffle (ZKBoo) is used only for shuffling one’s tokens. Assuch, one cannot use AKShuffle to send tokens directly toanother user. This is due to the fact that the signature size ofZKBoo is quite large, weighing in at around 500 kilobytesfor 5 inputs.

10

8 Network

Figure 11: Aidos Kuneen network topology

As illustrated in Figure 11, the Aidos Kuneen network iscomprised of a series of full-nodes who communicate ina P2P fashion. Clients can either connect directly to thesefull-nodes or to their own full-node via API. Clients are ableto send API requests in order to broadcast their transactionsto the network (this is usually performed automatically bythe wallet application). Between full-nodes, transactions aresent and received using an efficient serialization (e.g. msg-pack8) in order to reduce packet sizes.

In order to ensure anonymity between public full-nodes andclients we utilise the Tor network. This is essential as full-nodes may otherwise receive sensitive information such astheir clients’ IP addresses along with the clients’ transac-tions.

It is important to note that Tor is not employed for com-munications between full-nodes. This is due to the fact thatrouting traffic via the Tor network introduces an unavoid-able element of delay into inter-nodal communications, andefficiency between full-nodes is a critical aspect of the speedof the entire Aidos Kuneen network. Additionally, there islittle need to enforce anonymous communication betweennodes, this is due to the fact that even if the initial client-to-node connection were not secured with Tor, the initialreceiving node does not transmit any sensitive informationabout the client when it relays the transaction to the othernodes.

Unfortunately however, Tor is not quantum secure. Though,Tor does have the advantage of being a well established,trusted network with a large number of participants. We be-lieve that for the short term at least, the strong anonymityprovided by the Tor network is an excellent fit for Ai-dos Kuneen. We will continue to investigate other potentialmethods of providing quantum-resistant anonymity as theybecome available.

Table 2 lists the basic packet commands for the AidosKuneen network.

8https://msgpack.org/

Table 2: Basic Packet Commandscommand description

ping ping to another nodepong response of pingfind_node request node inforesp_node response node infersreq_transactions request transactions con-

tentsresp_transactions respond transactions con-

tentsreq_leaves request leaves’ hashesresp_leaves respond leaves’ hashesinvent invent new transaction

hashack_invent ack of inventinvent_copow invent that a node is

searching for coPoWgroup

ack_copow ack of invent_coPoWfind_value reserved for future use.store_value reserved for future use.

9 Leaves within iMeshAs mentioned previously in Section 4, the speed of confir-mation depends heavily on the number of leaves, Nleaves ,in iMesh. This is due to the fact that as the number of leaveswithin iMesh increases, the probability that a new transac-tion will refer to any one leaf reduces.

There are a number of scenarios in which the number ofleaves could conceivably increase, as illustrated in Fig-ure 12:

Figure 12: Leaves within iMesh

The first scenario is that an attacker might seek to slowdown iMesh by intentionally referring to non-leaf transac-tions. This would have the effect of adding additional, un-referenced leaves to the DAG, thus decreasing the overallefficiency of the entire network.

In order to combat this situation we could set Nre f ≥ 3 tohelp prevent attackers from increasing the number of leaves

11

indiscriminately. If we combine this with the fact that an at-tacker can only add one new leaf per transaction, we willfind that (provided the attacker does not control more than50% of the total network hash power) honest transactionswill rapidly reference the attacker’s new leaves, thus inte-grating them into the DAG and preventing the uncontrolledgrowth of unreferenced leaves.

In a similar situation to scenario one, an attacker may seekto spam the network by broadcasting a large number of verylow (or even zero value) transactions to either himself or anaccomplice in an attempt create a large number of leavesin a short amount of time, thus causing confirmation timesto significantly increase. This is easily prevented by the ex-isting requirement to complete PoW for every transaction,regardless of the value being transacted.

In the third scenario, one transaction T1 could enter intoiMesh while another, T2, is still in the process of being vali-dated (i.e. still undergoing PoW) and has not yet appeared iniMesh. Thus T1 and T2 may actually both be referring to thesame reference transaction. This scenario is not necessarilythe result of malicious intent, in fact, it could be expected tooccur quite frequently during normal network operation.

To solve this problem, we could increase the number of re-ferring transactions for any one transaction, Nre f , in orderto decrease Nleaves (i.e. to converge iMesh). However, thishas the undesirable side effect of increasing the transactionsize. As such, we need to determine the optimal Nre f valuein order to converge iMesh, while still seeking to maintaina small transaction size.

To this end, we will now present a simulation of the behav-ior of iMesh.

Firstly, we assume the process of incoming transactions canbe modelled by a Poisson flow, the size of a transaction |T x |is given by (constant+32×Nre f ) bytes, and the time to com-plete PoW can be modelled by an exponential distribution.So, let λin equal the rate of the Poisson flow and 1/λpowequal the expected time to complete PoW. Therefore, wecan say that on average, users will produce transactions atrate of λin and will complete PoW in 1/λpow . Note: Thetransaction rate includes PoW time 1/λpow .

While a user is performing PoW, other users will be gener-ating new transactions and these transactions will likely in-clude some of the same reference transactions as the trans-action currently undergoing PoW. The fact that Nre f (t) de-pends on Nre f (t − t ′) (i.e. the status in the past) makes itdifficult to solve for Nre f directly. Hence, it becomes nec-essary to simulate the behaviour of Nre f .

Algorithm 1 shows the algorithm used to simulate the num-ber of leaves in iMesh. We take 1/λpow = 10 minutes andsimulate with Nre f = 2,4,8,16,32 across the followingrates of input transactions λin :

1. λin=1 transaction per minute (This models the earlydays of iMesh when the user base is small)

2. λin=1 TPS (transaction per second)

3. λin=5 TPS (This is the peak transaction speed in theBitcoin network as occurred in May 2017)

4. λin=10 TPS

Algorithm 1 Simulation of the number of leaves withiniMesh

INPUT Nre f : number of directly referring transactionsINPUT Tsim : number of iterationsINPUT λin : rate of incoming transactionsINPUT λpow : time to complete PoWOUTPUT: number of leaves

time = 0 //current timepow_t xs = {} //transactions which are undergoing PoWt xs = {} //transactions in iMeshwhile time < Tsim do

step⇐ an exponentially distributed value at rate λintime ⇐ time + step

//add a new transaction to the transaction list//with a period to complete PoW.make new transaction tnewtnew .is_lea f ⇐ trueleaves ⇐ select random Nre f leaves in t xstnew .leaves ⇐ leavespow_time ⇐ an exponentially distributed value at rateλpowtnew .pow_time ⇐ time + pow_timeappend tnew to pow_t xs

//handle transactions whose PoW has finishedfor all t in pow_t xs do

if t.pow_time ≤ time thenremove t from pow_t xsappend t to t xsfor all l in t.leaves do

l .is_lea f ⇐ f alseend for

end ifend forcount t such that t.is_lea f = true in t xs and print it

end while

Figures 13 ~ 17 in Appendix A show the results of the sim-ulation. The result of Nre f = 8,16,32 for λin = 1 transac-tions per minute are not included as these results essentiallythe same as those of Nre f = 4.

From these results, we can see that the number of leavesNleaves decreases in proportion to the increasing value ofNre f . Even when λin = 1 transaction per minute, Nre f = 2is not enough to fully converge the DAG, (Nleaves is around3 ~ 26), and Nre f ≥ 4 is better (Nleaves = 1 ~ 18). Further-more, when we look at the other λin values, we notice thatNre f = 2 is considerably worse than the other Nre f val-ues. For example, at λin = 5 TPS, Nleaves � 3800 whenNre f = 2, Nleaves � 500 when Nre f = 8. Therefore, it isclear that we should NOT use Nre f = 2 if we assume trans-actions enter into iMesh at same speed as Bitcoin. The timeto converge DAG is below 3000 seconds (50 minutes) forall values of Nre f except Nre f = 2 when λin = 10 TPS.

It should also be mentioned that as |T x | exhibits simple lin-ear behaviour and doubles with each increase in the value ofNre f , from a purely transaction size focused point of view,we should seek to minimise the Nre f value.

We also simulate how the number of transactions,Ndescendant , which refer directly and indirectly to any onetransaction grow for each of the cases mentioned previ-ously. Figures 18 ~ 21 in Appendix B illustrate these results.

12

In these figures, the x-axis shows the number of transactionswhich enter into iMesh (after iMesh has become stable).The y-axis shows Ndescendant (the number of descendanttransactions) for one random transaction. The graph wouldbecome a diagonal (linear) line if Ndescendant were to growat an ideal rate. When λin = 1 transaction per minute, thegraphs of all Nre f are almost diagonal. But, as λin in-creases, Ndescendant reduces. For example, when λin =5TPS, Ndescendant does not increase diagonally even after25000 transactions (25000 × 0.2 seconds � 1.39 hours onaverage) at Nre f = 2. When Nre f = 8 and after 4000 trans-actions (4000 × 0.2 seconds � 13.3 minutes on average),Ndescendant starts to increase linearly.

As such, we believe that the best course of action is to allowNre f to remain as a variable. Nre f = 8 will be adopted atthe initial setting, due to the fact that even if iMesh wereto grow to λin = 5 TPS (which is the maximum TPS inBitcoin), Nre f = 8 still allows iMesh converge at around#leaves=500. Additionally, as previously discussed, settingNre f = 8 ≥ 3 will help to prevent attackers from increasingthe number of leaves indiscriminately.

As iMesh continues to grow we will review the value of theNre f variable in order to maintain optimal network perfor-mance.

10 Future PlansThe following plans are intended to be integrated into theAidos Kuneen network in the future:

1. Distribute transactions between nodes to allow for in-creased scalability (i.e. a single full-node does not holdall transactions within the network but instead queriesother nodes in the network as required)

2. Implement a Kademlia based scheme for Tor-likeanonymity, post-quantum security and distributed peerdiscovery.

3. Implement a more sophisticated ZKNI algorithm in or-der to reduce transaction sizes.

11 ConclusionIn this white paper we have presented the new cryptocur-rency Aidos Kuneen.

Aidos Kuneen employs iMesh, where all transactions are di-rectly referred to one another in order to form a DAG struc-ture.

To prevent double spending we utilize ‘SPECTRE’ to de-termine the legitimacy of all transactions.

We employ the hash-based signature ‘XMSS’ as the signa-ture scheme for post-quantum resistance.

For anonymity we introduce AKShuffle which utilisesthe zero-knowledge proof ‘ZKBoo (ZKB++)’ for post-quantum security.

To cater for the future growth of the IoT sector we intro-duce a novel cooperative Proof of Work mechanism called

coPoW, which allows low powered devices to combinedtheir resources and perform PoW as a group.

Finally, we provided a simulation of the number of leaveswithin iMesh, and the expected behaviour of the network asthe network grows.

Table 3: Aidos Kuneen: Technical Specifications

Ticker ADK

Total Supply 25,000,000 ADK

Minimum Unit 0.00000001 (10−8) ADK

PoW Algorithm Cuckoo Cycle

Anonymity AKShuffle (post-quantumzero knowledge proof) andTor

Consensus Algorithm SPECTRE

Distributed Ledger iMesh (transaction DAG)

Signature Scheme XMSS (post quantum hashbased signature)

Usage Finance, Banking, Digi-tal Commerce, IoT Micro-payments

13

References[1] Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008.

[2] Crypto Forum Research Group, draft-irtf-cfrg-xmss-hash-based-signatures-10 XMSS:Extended Hash-Based Signa-tures, 2017.

[3] Serguei Popov, The tangle, 2017.

[4] Sheldon M. Ross, Introduction to Probability Models. 10th Edition, 2012.

[5] Sergio Demian Lerner, DagCoin: a cryptocurrency without blocks, 2015.

[6] Johannes Buchmann, Erik Dahmen, Andreas Hülsing, XMSS — A Practical Forward Secure Signature Scheme Basedon Minimal Security Assumptions, 2011.

[7] Irene Giacomelli, Jesper Madsen, Claudio Orland, ZKBoo: Faster Zero-Knowledge for Boolean Circuits, 2016.

[8] Melissa Chase, David Derler, Steven Goldfeder, Claudio Orlandi, Sebastian Ramacher, Christian Rechberger, DanielSlamanig, Greg Zaverucha, Post-Quantum Zero-Knowledge and Signatures from Symmetric-Key Primitives, 2017.

[9] Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar, SPECTRE: Serialization of Proof-of-work Events: Con-firming Transactions via Recursive Elections, 2016.

[10] Peter W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Com-puter, 1995.

[11] Masoud Mohseni, Peter Read, Hartmut Neven, Commercialize early quantum technologies, 2017.

[12] PQCRYPTO, Post-Quantum Cryptography for Long-Term Security, Initial recommendations of long-term securepost-quantum systems, 2015.

[13] Nicolas van Saberhagen, CryptoNote v 2.0, 2013.

[14] John Tromp, Cuckoo Cycle: a memory bound graph-theoretic proof-of-work, 2014.

[15] Anton Churyumov, Byteball: A Decentralized System for Storage and Transfer of Value.

[16] Michael Szydlo, Merkle Tree Traversal in Log Space and Time, 2004.

[17] PQCRYPTO, Post-Quantum Cryptography for Long-Term Security, 2015.

[18] David Schwartz, Noah Youngs, Arthur Britto, The Ripple Protocol Consensus Algorithm, 2014.

14

Appendix A Results of Simulation — Number of Leaves Nleaves

Figure 13: λin = 1 transaction per minute, Nre f = 2

Figure 14: λin = 1 transaction per minute, Nre f = 4

Figure 15: λin = 1 TPS

Figure 16: λin = 5 TPS

Figure 17: λin = 10 TPS

15

Appendix B Results of Simulation — Growth of Ndescendant

Figure 18: λin = 1 transaction per minute

Figure 19: λin = 1 TPS

Figure 20: λin = 5 TPS

Figure 21: λin = 10 TPS

16