Quantum Resistant Ledger (QRL)

info@theqrl.org

October 2016 (revised)

Abstract

Private digital monies must be secure against computing advances to achieve longevity. The design andissuance of a cryptocurrency ledger utilising hash-based digital signatures which are resistant to classicaland quantum computing attack is presented.

1 Introduction

The concept of a peer-to-peer internet ledger of value, recorded as a blockchain and secured by proof of workwas first reported in 2008[11]. Bitcoin remains the most widely used cryptocurrency to date. Hundreds ofsimilar cryptocurrency ledgers have been subsequently created but with few exceptions they rely on the sameelliptic curve public-key cryptography (ECDSA) to generate digital signatures which allow transactions tobe verified securely. The most commonly used signature schemes today such as ECDSA, DSA and RSAare theoretically vulnerable to quantum computing attack. It would be valuable to explore the design andconstruction of a quantum resistant blockchain ledger to counter the potential advent of a sudden non-linearquantum computing advance.

2 Bitcoin Transaction Security

It is currently only possible to spend (unspent transaction outputs) from a bitcoin address by creating atransaction containing a valid elliptic curve (secp256k1) signature from the private key (x ∈ N |x < 2256) forthat specific bitcoin address. If the truly randomly generated private key is kept secret or lost then no fundscan reasonably be expected to move from that address ever.The chance of a specific bitcoin private key collision is 1 in 2256. The probability of any bitcoin addresskey collision can be estimated using the Birthday Problem. The number of bitcoin addresses which must begenerated to result in a 0.1% chance of a collision is 5.4x1023[14].

However, when a transaction is signed then the ECDSA public key of the sending address is revealed andstored in the blockchain. Best practice is for addresses not to be re-used, but as of November 2016 49.58%of the entire bitcoin ledger balance is held in addresses with exposed public keys[1].

3 Quantum Computing Attack Vectors

RSA, DSA and ECDSA remain secure based upon the computational difficulty of factorisation of large in-tegers, the discrete logarithm problem and the elliptic-curve discrete logarithm problem. Shor’s quantumalgorithm (1994) solves factorisation of large integers and discrete logarithms in polynomial time. Therefore,a quantum computer could theoretically reconstitute the private key given an ECDSA public key. It isthought ECDSA is more vulnerable to quantum attack than RSA due to the use of smaller keysizes, with a1300 and 1600 qubit (211) quantum computer able to solve 228 bit ECDSA.

Public quantum computer development has not passed beyond 25 qubits or the factorisation of small num-bers (15 or 21). However, in August 2015 the NSA deprecated elliptic curve cryptography ostensibly based

1

upon quantum computing concerns. It is unclear how advanced quantum computing may be presently orthat any breakthroughs in this field will be publicised to allow cryptographic protocols in common usage inthe internet to be made post-quantum secure. With somewhat anti-establishment origins, bitcoin could finditself the earliest target of an adversary with a quantum computer.

If a significant quantum computing advance were to occur publicly, node developers could implementquantum-resistant cryptographic signature schemes into bitcoin and encourage all users to move their bal-ances from ECDSA-based addresses to new quantum-safe addresses. To mitigate the proportion of effectedaddresses it would be reasonable to disable public key recycling at the protocol level. Such a planned up-grade would also result in the possible movement of the 1 million coins belonging to Satoshi Nakamoto -with associated price volatility.

A less favourable scenario would be a silent non-linear quantum computing advance followed by a nu-anced quantum computing attack on bitcoin addresses with exposed public keys. Such thefts could have adevastating effect upon the bitcoin exchange price due to new heavy sell pressure and a complete loss ofconfidence in the system as the scale of thefts become known. The role of bitcoin as a store of value (’digitalgold’) would be very badly damaged with extreme consequences for the world. In this context the authorsbelieve it is reasonable to experiment with quantum-resistant cryptographic signatures in a cryptocurrencyledger and potentially create a backup value store in the event of a black swan.

4 Quantum-resistant signatures

There are several important cryptographic systems which are believed to be quantum-resistant: hash-basedcryptography, code-based cryptography, lattice-based cryptography, multivariate-quadratic-equations cryp-tography and secret-key cryptography. All these schemes are thought to resist both classical and quantumcomputing attack given sufficiently long key sizes.

Forward secure hash-based digital signature schemes exist with minimal security requirements that relyonly upon the collision-resistance of a cryptographic hash function. Changing the chosen hash functionproduces a new hash-based digital signature scheme. Hash-based digital signatures are well studied andrepresent the primary candidate for post-quantum signatures in the future. As such they are the chosenclass of post-quantum signature for the QRL.

5 Hash-based digital signatures

Quantum resistant hash-based signatures rely upon the security of a one-way cryptographic hash functionwhich takes a message, m and outputs a hash digest, h of fixed length, n. i.e SHA-256, SHA-512. Usinga cryptographic hash function it should be computationally infeasible to brute force m from h (pre-imageresistance), or brute force h from h2, where h2 = hash(h) (second pre-image resistance), whilst it should bevery hard to find two messages (m1 6= m2) that produce the same h (collision resistance).

Grover’s quantum algorithm may be used to attempt to find a hash collision or perform a pre-image at-tack to find m, requiring O(2n/2) operations. Thus to maintain 128 bit security, a hash digest length, n ofat least 256 bit must be selected - assuming a perfect cryptographic hash function.

Hash-based digital signatures require a public key, pk, for verification and a private key, sk for signinga message. Various hash-based one-time signatures (OTS) will be discussed regarding their suitability forinclusion as part of a blockchain ledger.

5.1 Lamport-Diffie OTS

In 1979 Lamport described a hash-based one-time signature for a message of length, m bits (usually theoutput of a collision resistant hash function). Keypair generation creates m pairs of random secret keys,

2

skmj ∈ {0, 1}n where j ∈ {0, 1}. i.e. the private key is: sk = ((sk10, sk11), .., .., (skm0 , sk

m1 )). Let f be a

one-way hash function {0, 1}n → {0, 1}n, with m pairs of public keys generated pkmj = f(skmj ), i.e. the

public key is: pk = ((pk10, pk11), .., .., (pkm0 , pk

m1 )). Signing involves bitwise inspection of the message hash to

select skj (i.e. if bit = 0, skj = sk0, bit = 1, skj = sk1), creating the signature: s = (sk1j , .., skmj ) which

reveals half the private key. To verify a signature, bitwise (j ∈ {0, 1}) inspection of the message hash checksthat (pkj = f(skj))

m.

Assuming that after Grover’s algorithm 128 bit security is desired, where message length is a fixed hashoutput from SHA256, m = 256 and n = 256, resulting in a pk = sk = 16kb, and a signature of 8kb for eachOTS used. A Lamport signature should be used only once, may be generated very quickly, but suffers fromlarge key, signature and by extension transaction sizes, making it impractical for a public blockchain ledger.

5.2 Winternitz OTS

For a message digest, M , of length, m bits, with secret and public keys of length, n bits, a one-way func-tion, f : {0, 1}n → {0, 1}n and a Winternitz parameter, w ∈ N |w > 1, the general idea of the Winternitzone-time signature is to apply an iterating hash function on a list of random secret keys, sk ∈ {0, 1}n,sk = (sk1, .., skm/w), creating chains of hashes of length, w − 1, ending with public keys, (pk ∈ N |{0, 1}n),

pkx = f2w−1

(skx), pk = (pk1, .., pkm/w).Unlike the bitwise inspection of the message digest in in the Lamport signature, instead the message is parsedw bits at a time to extract a number, i ∈ N, i < 2w−1, from which the signature is generated, sx = f i(skx),s = (s1, ..sm/w). With a growing w providing a tradeoff between smaller keys and signatures for increasedcomputational effort.[10].

Verification involves simply generating pkx = f2w−1−i(sx) from M , s and confirming the public keys match.

Using SHA-2 (SHA-256) as a one-way cryptographic hash function, f : m = 256 and n = 256, with w = 8

results in a pk = sk = s size of (m/w)n8 bytes = 1kb.

To generate pk requires f i hash iterations, where i = mw 2w−1 = 8160 per OTS keypair generation. At

w = 16 the keys and signatures halve in size, but i = 1048560 becoming impractical.

5.3 Winternitz OTS+ (W-OTS+)

Buchmann introduced a variant of the original Winternitz OTS by changing the iterating one-way functionto instead be applied to a random number, x, repeatedly but this time parameterised by a key, k, whichis generated from the previous iteration of fk(x). This is strongly unforgeable under adaptive chosen mes-sage attacks when using a pseudo random function (PRF) and a security proof can be computed for givenparameters[3]. It eliminates the need for a collision resistant hash function family by performing a randomwalk through the function instead of simple iteration. Huelsing introduced a further variant W-OTS+, en-abling creation of smaller signatures for equivalent bit security through the addition of a bitmask XOR inthe iterative chaining function.[6] Another difference between W-OTS(2011 variant)/ W-OTS+ and W-OTSis that the message is parsed log2(w) bits at a time rather than w, decreasing hash function iterations butincreasing keys and signature sizes.

W-OTS+ will now be briefly described. With security parameter, n ∈ N , corresponding to the lengthof message (m), keys and signature in bits, being determined by the cryptographic hash function chosen andthe Winternitz parameter, w ∈ N | w > 1 (usually {4, 16}), l is computed. l is the number of n bit stringelements in a WOTS+ key or signature, where l = l1 + l2:

l1 = d m

log2(w)e, l2 = b log2(l1(w − 1))

log2(w)c+ 1

A keyed hash function is used, fk : {0, 1}n → {0, 1}n | k ∈ {0, 1}n. In pseudocode:

fk(M) = Hash(Pad(K)||Pad(M))

3

Where Pad(x) = (x||10b−|x|−1) for |x| < b.

The chaining function, cik(x, r): on input of x ∈ {0, 1}n, iteration counter i, key, k ∈ K, and randomi-sation elements, r = (r1, .., rj) ∈ {0, 1}n∗j , with j ≥ i, is defined as follows:

Figure 1: W-OTS+ chaining function

Where:

ci(x, r) =

{x if i = 0;

fk(ci−1k (x, r)⊕ ri) if i > 0;

Figure 2: Example hash-chain generation

That is a bitwise xor of the previous iteration of ck and the randomisation element followed by fk on theresult, which is then fed into the next iteration of ck.

5.3.1 Signature key

To create the secret key, sk, l+w−1 n bit strings are chosen uniformly at random (with PRF), of which thefirst l make up the secret key, sk = (sk1, ..skl) and the remaining w−1 n bit strings become r = (r1, .., rw−1).A function key, k is chosen uniformly at random.

5.3.2 Verification key

The public key is:

pk = (pk0, pk1, .., pkl) = ((r, k), cw−1k (sk1, r), cw−1k (sk2, r), .., c

w−1k (skl, r))

Note that pk0 contains r and k.

5.3.3 Signing

To perform a signature: message, M , of length m, is parsed such that M = (M1, ..Ml1),Mi ∈ {0, w − 1}(creating a base-w representation of M).

4

Next the checksum, C, of length, l2, is calculated and appended:

C =

l1∑i=1

(w − 1−Mi)

Such that: M + C = b = (b0, ..bl)The signature is:

s = (s1, .., sl) = (cbik (sk1, r), .., cblk (skl, r))

5.3.4 Verification

To verify a signature b = (b1, .., bl) is reconstructed from M .

If pk = (cw−1−b1k (s1), .., cw−1−blk (sl)) then the signature is valid.

W-OTS+ provides a security level of at least n−w− 1− 2log(lw) bits[3]. A typical signature where w = 16using SHA-256 (n = m = 256) is ln bits or 2.1kb.

6 Merkle tree signature schemes

Whilst one-time signatures provide satisfactory cryptographic security for signing and verifying transactionsthey have a major drawback that they may only be used once safely. If a ledger address is based upon sometransformation of the public key of a single OTS keypair then this would lead to an extremely restrictiveblockchain ledger where all funds from a sending address would need to move with every single transactionperformed - or those funds would be at risk of theft.A solution is to extend the signature scheme to incorporate more than one valid OTS signature for eachledger address allowing as many signatures as OTS keypairs are pre-generated. A binary hash tree knownas a merkle tree is a logical way to achieve this.

6.1 Binary hash tree

The general idea behind a merkle tree is an inverted tree composed of parent nodes computed by hashingthe concatenation of child sibling nodes upwards in layers to the root. The existence of any node or leaf canbe cryptographically proven by computing the root.

A merkle tree is formed from n base leaves and has height to merkle root, h (n = 2h) - starting fromthe leaf hashes (layer 0) and counting upwards with each layer of nodes. Each leaf node is created in ourhypothetical ledger use-case by hashing a randomly pre-generated OTS public key. From the tree below itcan be seen that the node above each pair of leaf hashes is itself formed by hashing a concatenation of thechild hashes.

5

Figure 3: Merkle tree signature scheme example

This continues upwards through layers of the tree until confluence into the root hash of the tree, known asthe merkle root.

From the example tree in the diagram, taking the merkle root as the public key, four pre-computed OTSkeypairs can be used to generate four cryptographically secure valid one-time signatures. The merkle rootof the binary hash tree can be transformed into a ledger address (possibly by iterative hashing with anappended checksum). A full signature, S, of a message, M , for a given OTS keypair includes: the signature,s, the ots key number, n, and the merkle authentication path. i.e. for OTS keypair 0 (thus n = 0):

S = s, n, OTS public key 0, H1, H2, H5, H6, root

Given the OTS public key and leaf hash can be deduced from s, and parent nodes can be computed fromtheir children in fact this may be shortened to:

S = s, n, H2, H6, root

Where S is valid by verifying the OTS public key from s and M , then checking the hashes from the merkleauthentication path recreate a matching merkle root (public key).

6.2 State

Using the above merkle signature scheme (MSS) securely relies upon not re-using the OTS keys. Therefore,it is dependent upon the state of signatures or signed transactions being recorded. Ordinarily in real worldusage this would potentially be a problem, but an immutable public blockchain ledger is the ideal storagemedium for a stateful cryptographic signature scheme. A newer hash-based cryptographic signature schemecalled SPHINCS which offers practical stateless signatures with 2128 bit security was reported in 2015[2].

6.3 Hypertrees

A problem with the basic MSS is that the number of signatures possible is limited and all the OTS keypairsmust be pre-generated prior to calculation of the merkle tree. Key generation and signature time grow ex-ponentially with the height of the tree, h, meaning trees larger than 256 OTS keypairs becomes temporallyand computationally expensive to generate.A strategy to defer computation during key and tree generation and also extend the number of OTS keypairsavailable is to use a tree which is itself composed of merkle trees called a hypertree. The general idea is tosign the merkle root of a child tree with an OTS key from the leaf hash of a parent merkle tree known as a

6

certification tree.

Figure 4: linking merkle trees

In the most simple form (height, h = 2) a certification tree is precomputed with 21 OTS keypairs and whenthe first signature is required a new signature merkle tree (signature tree 0) is computed and signed by oneof the certification tree OTS keypairs. The signature tree is composed of n leaf hashes with correspondingOTS keypairs and these serve to sign messages as required. When each OTS keypair in the signature treehas been used then the next signature tree (signature tree 1) is signed by the second OTS keypair from thecertification tree and the next batch of signatures is possible.

A signature, S, of such a hypertree construction becomes slightly more complicated and would include:1. from the signature tree: s, n, merkle path, root2. from each certification tree: s (of child tree merkle root), n, merkle path, root

It is theoretically possible to nest layers of trees down from the certification tree to extend the originalMSS infinitely. Signature size grows linearly for each additional tree that is signed, whilst the hypertreesignature capacity increases exponentially.

6.3.1 Hypertree examples

To demonstrate how easily the MSS may be extended with a hypertree construction consider an initialcertification tree of height, h1 = 5, with 25 leaf hashes and associated OTS keypairs. The merkle root ofthis tree is transformed to generate a ledger address. Another merkle tree, a signature tree of identical size(h2 = 5, 25 leaves and OTS keypairs) is instantiated. 32 signatures are possible before the next signaturetree must be created. The total number of signatures possible is 2h1+h2 which in this case is 210 = 1024.

On a Macbook pro 2.7Ghz i5, 8gb ram creating OTS keypairs and a merkle certification tree for varioussizes yielded the following results (unoptimised python code, Winternitz OTS): 24 = 0.5s, 25 = 1.2s, 26 =3.5s, 28 = 15.5s. A hypertree consisting of initial generation of two 24 trees takes around 1s compared with15.5s for standard 28 MSS tree for the same signature capacity.

Increasing the depth (or height) of a hypertree continues this trend. A hypertree composed of four chained24 certification trees and a signature tree of size 24 is capable of 220 = 1, 048, 576 signatures with an addedcost to the signature size but a creation time of only 2.5s.

7

Figure 5: Hypertree construction

There is no requirement for a hypertree to be symmetrical and so if composed initially of two trees it couldlater be extended later by signing further layers of trees. Signatures from a ledger address would thereforestart small and eventually rise as the hypertree depth increased. Using a merkle hypertree to create andsign transactions from a ledger address is never likely to require > 212 transactions. Thus, the ability to signwith computational ease 220 times securely at a hypertree depth of h = 5 is more than sufficient.

6.4 XMSS

The extended merkle signature scheme (XMSS) was first reported by Buchmann et al. in 2011 and waspublished as an IETF draft last year[4][7]. It is provably forward secure and existentially unforgeable underchosen message attacks with minimal security requirements: a PRF and a second pre-image resistant hashfunction. The scheme allows extension of one-time signatures via a merkle tree with a major difference beingthe use of bitmask XOR of the child nodes prior to concatenation of the hashes into the parent node. Theuse of the bitmask XOR allows the collision resistant hash function family to be replaced.

Figure 6: The XMSS tree construction

The leaves of the tree are also not OTS keypair hashes but the root of child L-trees which hold the OTSpublic keys with, l pieces forming the base leaves. Winternitz OTS+ is used for the one-time signatures(though 2011 variant was first described).

8

Figure 7: XMSS construction [8]

The bit length of the XMSS public key is (2(H + dlogle) + 1)n, an XMSS signature has length (l+H)n, andthe length of the XMSS secret signature key is < 2n.

Buchmann reports performance with an Intel(R) i5 2.5 Ghz for an XMSS tree of height, h = 20, wherew = 16 and the cryptographic hash function used is SHA-256 (m = 256) of up to around a million signa-tures. With the same parameters and hardware, signing took 7ms, verification 0.52ms and key generation466 seconds. The security level achieved with such parameters was 196 bits for a public key size of 1.7kb,private key of 280 bits and signature 2.8kb. XMSS is an attractive scheme with the main drawback beingthe extremely long key generation time.

6.5 XMSS tree performance

Using an unoptimised python library constructed for a QRL testnode formation of a 4096 leaf XMSS tree(h=12) with all keys and bitmasks generated from a hash-based PRF took 32s on the same hardware de-scribed above (a Macbook pro 2.7Ghz i5, 8gb ram). This included generation via PRF of more than 8000bitmasks and over 300,000 sk fragments. A more efficient merkle tree traversal algorithm and the need toonly perform w−1 hashes per secret key chain function in WOTS+ rather than 2w−1 with WOTS contributeto the dramatic performance improvement over a conventional MSS.

A complete signature size of around 5.75kb was achieved in this construction (11.75kb hexadecimal stringencoding) including the: OTS keypair n, signature, XMSS auth route, OTS public key and the XMSS treepublic key (including PRF public key seed and the XMSS tree root).

For trees of various signature capacities generated using PRF and a random seed, the following performancewas obtained: (h=9) 512 4.2s, (h=10) 1024 8.2s, (h=11) 2048 16.02s.

9

7 Proposed signature scheme

7.1 Security requirements

In the design of the QRL it is important that the cryptographic security of the signature scheme is secureagainst classical and quantum computing attack both in present day and also future decades. XMSS usingSHA-256, where w = 16, offers 196 bit security with predicted safety against brute force computationalattack until the year 2164[9].

7.2 QRL signatures

An extensible stateful asymmetrical hypertree signature scheme composed of chained XMSS trees is pro-posed. This has the dual benefit of utilising a validated signature scheme and allowing generation of ledgeraddresses with the ability to sign transactions avoiding a lengthy pre-computation delay seen with giantXMSS constructions. W-OTS+ is the chosen hash-based one-time signature in the scheme for both securityand performance reasons.

7.3 Hypertree construction

7.3.1 Key and signature sizes

As the number of trees within a hypertree grows, key and signature sizes grow linearly - but signaturecapacity rises exponentially. Sizes for various XMSS tree derived public keys and signatures (based upon2011 description), where w = 16, m = 256, h is tree height and SHA-256 is chosen as the cryptographic hashalgorithm, are:

• h = 2, 22 signatures: public key 0.59kb, signature 2.12kb (0.4s)

• h = 5, 25 signatures: public key 0.78kb, signature 2.21kb (0.6s)

• h = 12, 212 signatures: public key 1.23kb, signature 2.43kb (32s)

• h = 20, 220 signatures: public key 1.7kb, signature 2.69kb (466s[3])

The trade-off for creating an XMSS hypertree (4 trees, j = 3, h = 5) with eventual signature capacity of 220

in less than 3s compared with 466s, for a signature of 8.84kb instead of 2.69kb may be acceptable.

7.3.2 Asymmetry

Creating an asymmetrical tree allows early signatures to take place with with a single XMSS tree construc-tion, which is extended as required for later signatures at a cost to overall signature capacity. The rationaleis that this is likely to be of no consequence for a blockchain ledger application and the wallet can give a useran option of signature capacity versus signature/key sizes. A maximum tree depth of j = 2 should sufficefor all circumstances.

10

Figure 8: Asymmetrical hypertree

7.4 QRL hypertree specification

The following default parameters are to be adopted for a standard hypertree construction:

• j = 0 (j ∈ {0 ≤ x ≤ 2}), h = 12 (h ∈ {1 ≤ x ≤ 14}), upper bound of signatures possible: 236,minimum signature size: 2.21kb, maximum signature size: 7.65kb.

i.e. A single XMSS tree, h = 12 with 4096 signatures available, which may be extended with further treesof up to h = 14 as required. For most users additional trees are unlikely to be required at all.

7.4.1 Example QRL signature

Assuming the most complicated hypertree construction where j = 2 and h = 14, a signature for transactionmessage, m, where n is the OTS keypair position for each XMSS tree, would require:

• Signature tree, j = 2: OTS signature of m, n, merkle authentication proof, merkle root of signaturetree

• Certification tree, j = 1: OTS signature of merkle root from signature tree (j = 2), n, merkle authen-tication proof, merkle root

• Original XMSS tree, j = 0: OTS signature of merkle root (j = 1), n, merkle authentication proof,merkle root

Verification involves generating the OTS public key from m and the signature, then confirming the suppliedmerkle authentication proof generates the signature tree merkle root. This becomes the message for the nextOTS signature and from this the next OTS public key is generated, the supplied merkle authentication proofused to recreate the certification tree merkle root, which becomes the message for the next certification treeOTS signature, and so on. A signature is only valid if the merkle root of the highest tree, the original XMSStree, (j = 0) is correctly generated.

Notice the OTS public keys are not required for verification of the XMSS tree signature. In fact the merkleroot for each tree can also be deduced and therefore omitted with hypertree signature verification if thesending ledger address is known (as this is a computed derivative of the merkle root for the highest XMSScertification tree (j = 0) within the QRL signature - see Accounts later).

As the signature scheme is stateful the wallet implementation must retain and update n for each XMSStree generated in the hypertree for a given address.

11

7.5 PRF

PRF from seed. HMAC DRBG.

7.6 Deterministic wallet

Using a single SEED it is possible to generate a very large XMSS tree which should suffice for most usersfor a prolonged period. A secure source of entropy is used to generate this SEED which is passed througha secure PRF function to generate a set of pseudorandom keys which generate the tree. One drawback ofusing the same XMSS tree is that the user is confined to a single address (although public key exposure isnot a concern with a MSS).A bitcoin or ethereum address is derived from the associated public key and as such a single private or publickey may only create a single address. However, an XMSS address is derived from the public key, PK, whichcontains the merkle root and public SEED. If the SEED remains constant but the number of OTS keypairsto compute the tree varies then the merkle root will change for each variation. Thus for every single additionor subtraction of a single OTS keypair the derived address will change.This feature may be used by wallet/node software to generate numerous variations of the XMSS tree (extend-ing/contracting it as required using the same initial SEED) allowing as many unique addresses as required tobe generated. To record this information in a safe, stateful and compact manner is computationally trivial.

8 Cryptocurrency design parameters

The remainder of the white paper will set out the proposed design parameters for the QRL ledger. The focusof the ledger is to be a public blockchain which is highly secure against classical and quantum computingattack vectors. This is a first draft and thus every aspect is subject to potential change.

8.1 Fees

The larger transaction sizes compared with other ledgers necessitates a transaction fee must be paid witheach transaction. The author is of the opinion that artificial fee markets (see bitcoin) are unnecessary andrun counter to the ideal of an open public blockchain ledger. Each transaction if it pays a minimum feeshould be as valid as any other. The minimum fee miners are willing to accept should float and be set bythe market. i.e. nodes/miners competitively set the lower bound of fees between themselves. An absoluteminimum value will be enforced at protocol level. Thus, miners will order transactions from the mempoolfor inclusion in a block at their discretion.

8.2 Blocks

8.2.1 Block-times

Bitcoin has a time between blocks of roughly 10 minutes, but with natural variance this can on occasionlead to fairly long periods before the next block is mined. Newer ledger designs such as ethereum haveimproved upon this and benefit from a much shorter block-times (15 seconds) without the loss of security orminer centralisation from high rates of orphan/stale blocks. Ethereum uses a modified version of the GreedyHeaviest Observed Subtree protocol which allows stale/orphan blocks to be included in the blockchain andrewarded[13, 5].

The QRL plans to safely use a block-time of 60 seconds.

8.2.2 Block-rewards

Each new block created will include a first ’coinbase’ transaction containing a mining address into which areward equal to the sum of the coinbase reward and the combined sum of transaction fees within the block.The block-reward is re-calculated by the mining node every block and follows the coin emission schedule.

12

8.2.3 Blocksize

To avoid controversy an out-of-the-box adaptive solution modelled upon the Bitpay proposal to increase theblocksize based upon a multiple, x, of the median size, y of the last z blocks would be employed[12]. Theuse of the median prevents gaming by miners to include either empty or overstuffed blocks to alter the meanblocksize. x and z would then be hard consensus rules for the network to obey.

Thus, a maximum blocksize, b could be simply calculated as:

b = xy

8.3 Currency unit and denominations

The QRL will use a monetary token, the quantum (plural quanta), as the base currency unit. Each quantumis divisible to a smallest element as follows:

• 1 : Quantum (plural: Quanta)

• 10−9 : Shor

Thus, each transaction involving a fraction of a quantum is actually a very large integer of Shor units.Transaction fees are paid and calculated in Shor units.

8.4 Accounts

A QRL address is designed to be extensible and supports a wide range of formats.The first three bytes of any address (descriptor) encode information to describe the hash function, signaturescheme, address format, and additional parameters.A typical account address is represented as follows:

Q01070050d31c7f123995f097bc98209e9231d663dc26e06085df55dc2f6afe3c2cd62e8271a6bd

8.4.1 Structure

QRL Addresses are structured in the following way:

Name Bytes Count Description

DESC 0 .. 2 3 Address DescriptorDATA 3 .. N ?? N will depend on the address format

At the moment, only one address format is supported: sha256 2XWhen using sha256 2X, a QRL address is composed of 39 bytes. This is the internal format used by anyAPI or module in the project. For representational purposes (i.e. user interface, debugging, logs), it ispossible that the address is represented as a hexstring prefixed with Q (79 hexadecimal characters). This isappropriate for user related purposes but will be rejected by the API.

Name Bits Count Description

DESC 0 .. 2 3 Hash FunctionHASH 3 .. 35 32 SHA2 256(DESC+PK)VERH 36 .. 40 4 SHA2 256(DESC+HASH) (only last 4 bytes)

In pythonic pseudocode this is represented as follows:

Q+DESC[: 3] +HASH[: 32] + V ERH[: 4]

13

8.4.2 Descriptor

Name Bits Count Description

HF 0 .. 3 4 Hash FunctionSIG 4 .. 7 4 Signature SchemeP1 8 .. 11 4 Parameters 1 (ie. height, etc.)P2 12 .. 15 4 Address FormatP3 16 .. 23 8 Parameters 2

In the case of using XMSS, the parameters are used as follows:

Name Bits Count Description

HF 0 .. 3 4 SHA2-256, SHAKE128, SHAKE256SIG 4 .. 7 4 XMSSP1 8 .. 11 4 XMSS Height / 2AF / P2 12 .. 15 4 Address FormatP3 16 .. 23 8 Not used

SIG - Signature Type

Value Description

0 XMSS1 .. 15 Reserved - Future expansion

HF - Hash Function

Value Description

0 SHA2 2561 SHAKE 1282 SHAKE 2563 .. 15 Reserved - Future expansion

AF - Address Format

Value Description

0 SHA256 2X1 .. 15 Reserved - Future expansion

8.5 Coin issuance

8.5.1 Issuance

The QRL initial issuance will be the following:

• Initial supply: 52 · 106 quanta

• Allocated for foundation: 13 · 106 quanta

• Initial total supply: 65 · 106 quanta

• Eventual total supply: 105 · 106 (40 · 106 quanta distributed via exponential decay emission scheduleover approximately 200 years)

14

8.6 Coin emission schedule

A defining feature of bitcoin is the scarcity and fixed upper limit to issuance of the underlying monetarytoken. QRL will follow bitcoin in this regard with a fixed upper limit to the coin supply of 105 · 106 quanta.A smoothly exponential decay in the block-reward is favoured up to the hard ceiling of coin supply. Thiswill eliminate the volatility associated with the bitcoin ’halving’ phenomenon.

The total coin supply, x = 105 · 106, minus coins created at the genesis block, y, will exponentially reducefrom Z0 downwards forever. The decay curve assumes the distribution of rewards for approximately 200years (until 2218AD, 105189120 blocks generated at an approximate rate of 1 block every 60 seconds).

The remaining coin supply at block t, Zt, may be calculated with:

Zt = Z0e−λt

The coefficient, λ, is calculated from: λ = lnZ0

t . Where t, is the total number of blocks in the emissionschedule until the final quanta. The block reward, b is calculated for each block with:

b = Zt−1 − Zt

References

[1] http://oxt.me/charts.

[2] D. Bernstein. Sphincs: practical stateless hash-based signatures. 2015.

[3] J Buchmann. On the security of the winternitz one-time signature scheme.

[4] J. Buchmann. Xmss – a practical forward secure signature scheme based on minimal security assump-tions. 2011.

[5] V Buterin. Ethereum whitepaper. 2013.

[6] A. Hulsing. W-ots+ - shorter signatures for hash-based signature schemes. 2013.

[7] A. Hulsing. Xmss: Extended hash-based signatures. 2015.

[8] A Karina. An efficient software implementation of the hash-based signature scheme mss and its variants.2015.

[9] A. Lenstra. Selecting cryptographic key sizes. 2001.

[10] R. Merkle. A certified digital signature. CRYPTO, 435, 1989.

[11] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

[12] S Pair. A simple, adaptive blocksize limit. 2016.

[13] Yonatan Sompolinsky. Accelerating bitcoin’s transaction processing fast money grows on trees, notchains. 2014.

[14] A. Toshi. The birthday paradox. 2013.

15