Seed investment strategy, POS algorithm updates

Genesis pre-sale

Our official pre-sale date for May 24th has been kindly listed on various sites and has resulted in significantly increased traffic to and a marked rise in people joining our investor list. Likewise the number of people entering our development slack has skyrocketed in the last week or so.

We actually have our first investor onboard (welcome and thank-you for being 1st! If just 29 more people invest the same amount we reach our first development target!) and amongst the team we have decided to open our pre-sale of the QRL genesis block to our investor list on an invitational basis at some point in the next 2–3 days by email. Our website will be updated with some more information about our team (including photos and profile information) around this time to help potential investors perform due diligence and put a public face on the project which until now has been running in stealth mode.

Development targets

We have set development targets with our upcoming raise. If we do not reach $500k equivalent in bitcoin and ether collectively then we will return funds and continue to launch the project privately — this does not seem likely at present given the hundreds of crypto-enthusiasts on our investor list!

Our development targets are $1M, $2M and we are setting a hard cap at $4M because the team feels strongly we are raising funds for development — we expect to be listed on an exchange once we are running mainnet and there is no practical reason why anything more than this will be needed to develop the project for the next 36 months. These targets have been chosen because we feel they are realistic for a project as innovative and unique as the QRL — but also because our roadmap has a lot of development milestones to hit for the project to reach full potential. I see too many ICO’s with flashy websites and no product raising >$10M and that is not what the QRL is about.

Funding sets a speculative value on the genesis block which serves a hugely important function in bootstrapping the mainnet launch by securing the QRL with our proof-of-stake algorithm i.e. it prevents us being attacked as we launch by a malicious entity by raising the cost of such a strategy.

Pre-sale parameters

After a lot of internal debate the final parameters for our pre-sale are the following:

— initial invitational offering to investors on our ‘interested list’ which will then only open to the public ICO if we fail to reach our cap. Should the cap be struck during this private phase every investor will be included proportionally and any excess returned.

— from May 24th the public ICO will proceed on a first come first serve basis.

— initial distribution will be 65 million coins (quanta).

— final distribution in 200 years will be 105 million coins (smoothed exponential decay curve to a hard cap).

— 20% of pre-sale (13 million quanta) will held by team of which 65% will be vested by the QRL foundation.

— 100% of the pre-sale funding will be held by the QRL foundation with a phased vesting programme tied to development milestones and research goals

— bitcoin and ethereum multi-signature addresses to be accepted for pre-sale funding deposits (2-of-3 m-of-n multisig with keys held separately by 3 different founding members of the QRL).

— proposed mainnet launch (hopefully with synchronous exchange listing) pencilled in for August 2017.

Any further questions please email directly or for realtime discussion request an invite to the development slack.

Thank you to everyone who has worked on the QRL thus far and to everyone who invests in the project during the pre-sale and helps us to build the world’s first post-quantum secure public blockchain ledger with unrivalled future private and secure data applications.

Proof-of-stake algorithm

Jomari Peterson asked me to write a brief overview of our POS algorithm so here goes..

Conventional blockchain ledgers are secured by proof-of-work where blocks (which contain transactions) are added to the previous chain of blocks by the node which ‘wins’ the hash-based lottery first. This is an absolutely incredible design and it is testament to the simplicity and genius of the bitcoin proof-of-work system that nearly 8 years later it is still going strong.

The problems with proof-of-work are that it: burns energy, leads to centralisation of mining, requires dedicated hardware, leads to constant sell pressure for the cryptocurrency (for miners to recoup costs) and doesn’t really work as originally designed.

In 2009 bitcoin miners were just users who ran the bitcoin node software on their laptops or home computers. Now all new coins in the bitcoin network are created (fairly) by a handful of nodes connected to huge mining farms and 99% of users who continue to run fully validating nodes bear the costs of running the actual network leading to friction between developers, users and miners.

An alternative strategy called proof-of-stake is to use a block selection algorithm which arrives at consensus of which address/node is to create the next block and this is usually weighted by security deposits within the addresses of the participating nodes — the so called stake validators. The benefit of this system is that, depending upon the block selection algorithm chosen, it has minimal energy and processing requirements and it rewards nodes in a probabilistically even fashion based upon their stake balances. Thus the nodes with greatest ledger balances (and the most to lose from loss of consensus) are tasked with growing the blockchain.

The QRL uses an adapted form of proof-of-stake which has to be very careful to remain post-quantum secure at each step. The general idea is that each node who wishes to participate as a staker in the next epoch lasting 10,000 blocks signs an XMSS transaction in the current epoch. This transaction contains a signed SHA-256 hash which is actually the final hash in a hash-chain containing 10,000 iterative hashes (XOR’d with a key). If you remember that cryptographic hash functions are one-way functions then you will see that this enables the node which holds the entire hash-chain to reveal the hash preceding the signed hash in the transaction, then the one before that, and keep revealing preceding hashes for each block in the epoch. A hash which is revealed can then be fed into the SHA-256 function and the signed hash re-produced based on the number of iterations required. The key point here is that only the node with the hash-chain is able to produce the reveal hash because only they know the entire construction. A reveal hash cryptographically links the identity of the reveal hash to the signed hash and therefore to the node which owns the XMSS address in the original transaction.

So each potential staker sends out a transaction containing the signed final hash in hash chain. On the last block of the current epoch blockchain data is sampled to generate entropy which is fed into a hash-based provably secure pseudo random number function (PRF) called HMAC_DRBG. This simply takes a seed (+entropy) and emits a sequence of pseudo random numbers (huge ones which are 32 bytes long — exactly the same length as the SHA-256 reveal hashes). If you analyse the output from the PRF blindly it would appear to be uniformly random. In our case the seed and entropy for the output is generated after the stake transactions are added to the blockchain so there is no way for the stakers to know the contents of the pseudorandom number sequence. Even if they could their respective hash chain is essentially a random number sequence anyway!

Block selection each round is determined by nodes in synchrony voting with their respective reveal hashes. The closest reveal hash to the PRF output for this block is deemed the winner. Since there are 2²⁵⁶ possibilities a collision is statistically highly improbable — you are as likely to guess a specific bitcoin address. Nodes in synchrony then collate their reveal hashes and vote for the winner, then they collate those winning votes and vote their own view of network consensus as they have received it. Next individual network consensus votes are collated to determine overall network consensus based upon voting numbers and staked-weighting by validator account balance. Block-reward is paid based upon validator account balance to the block creator.

Staking addresses are frozen from transferring funds for the entire epoch although soon we will enable the ability to unfreeze the address but then for the remainder of the epoch it returns to being a normal address and is removed from the list of stake validators.

Stake validators which fail to produce the block which network consensus deems should have been created are punished by loss of block reward and banned from staking for the next 100 blocks.

Our algorithm uses individual node rules based upon consecutive consensus proof-of-stake cycles for preventing a group of validators colluding to try and build a longer chain and fork the network.

An interesting problem which is unique to the QRL is that XMSS signatures are expensive and so we have chosen to instead associate XMSS addresses with hash-chain reveal hash identifiers each block round. This has the vulnerability of being susceptible to a man in the middle attack (MITM) where a node may sit between stake validator nodes and front run their messages and tamper with the contents. To obviate this our protocol sends a hash of each message prior to the actual message. Only messages that are received which hash to a cryptographic hash received in the past are accepted — thus we use time to prevent an attacker altering messages.

To prevent a malicious user creating many sybil XMSS stake validator addresses we limit valid stake validators to -2 standard deviations from the median account balance of all stake validators when this number exceeds 20. Block reward is also paid proportional to the ratio of stake validator balance : all stake validators balance to remove an incentive to create multiple stake addresses with scattered balances.

Our QRL testnet is active and being destructively tested by a wonderful group of alpha-testers. Feel free to get involved or investigate our project further at