Common questions *and* answers to those questions prepared by our team.

Have more questions? See our Documentation or Contact Us

The Quantum Resistant Ledger (QRL) is a first of its kind, future-proof post quantum value store and decentralized communication layer which tackles the threat Quantum Computing will pose to cryptocurrencies.

This is backed by provably secure, peer-reviewed XMSS (instead of 256-bit ECDSA) with a proof-of-work(POW) algorithm, Cryptonight v7, which will later be hard forked to Proof of Stake.

Also included is:

- A web wallet to create tokens & send and receive Quanta.
- Desktop Apps (windows, mac, Linux)
- An explorer
- gRPC with protobuf for a powerful API

Soon to be included is:

Permanent Link- Initial Distribution: 52m
- Foundation: 13m
- Initial population: 65m
- Eventual Total Population: 105m
- Block time: 60 seconds
- Adjustments: Per block
- Emissions: 40m (following an exponential decay emission model over 200 years)

Yes.

We have evaluated current strategies publicly and have developed a multi-tiered approach to 51% attack resistance.

Permanent LinkWe have a number of guides related to testnet features, and you are always welcome to come check out our #testnet channel on our Discord or submit a bug report to our GitHub! Guide to get started with testnet: https://github.com/theQRL/QRL/#qrl-testnet-instructions-for-alpha-testers

- Web-wallet: https://wallet.theqrl.org
- QRL Explorer: http://explorer.theqrl.org/

NOTE: If one of the above links does not work it is because we have updated Testnet but not our FAQ page yet. The updated links and information will be present in #alpha-testers. Thank you for your patience.

Permanent LinkThere are many varying definitions of privacy. Some include obfuscated IP addresses (Tor protocol), others use a difficult-to-trace transaction setup and unclear balances (Monero) while still others use zero knowledge proofs (zcash, zclassic).

The method by which the QRL would implement privacy would be the Zk-Stark technique about Zk-Snarks that makes them quantum resistant (detailed by Vitalik and some very mathematical papers). This would make a private transaction have a size of roughly 400 to 500 kilobytes which is pretty unfeasible to include in a block (basic bitcoin transactions are under 300 bytes, our transactions are about 2.1 kilobytes) unless it is limited to one per block and an absolutely massive fee is attached (hundreds of dollars).

For this reason, in addition to legislation in the EU bringing anonymity into a legal gray area, it is unlikely that the team will pursue implementing it in the near future. We’d like to have a chain that can be utilized by businesses and governments without concern for whether or not doing so would even be legal.

If information science develops further that enables this to be accomplished more efficiently, it might be revisited.

The team desires to be as friendly as possible to independent forks of our chain as we believe they are an important and healthy part of the system we create. It is not unlikely that someone at some point might enable a fork to utilize this privacy technique, but again, it’s not something we are pursuing in the short term.

Permanent LinkSeveral important algorithms in public-key cryptography (such as ECDSA used in Bitcoin) base their security on the assumption that the discrete logarithm problem over carefully chosen groups has no efficient solution. It has however been shown that a quantum computer of sufficient power can use Shor’s algorithm to effectively compute a private key generated using ECDSA by ‘scanning’ all possible solutions to a given public key (address) in superposition simultaneously.

QRL implements one of a series of peer-reviewed post-quantum secure algorithms: XMSS (eXtended Merkle Signature Scheme) XMSS uses a OTS (One Time Signature Scheme) that can only sign one message with one key. OTS signature keys are generated as needed, making XMSS unforgeable under chosen message attacks.

Permanent LinkECDSA (Elliptic Curve Digital Signature Algorithm) is a digital signature algorithm standard that is using elliptic curve cryptography to generate and verify digital signatures. ECDSA is used in cryptocurrencies such as Bitcoin to secure financial transactions.

In order to generate a valid Bitcoin transaction the private key is needed to sign the transaction and generate the ECDSA digital signature. The corresponding public key is published after the transaction is generated, because it is needed to verify that the transaction was signed correctly using the private key.

The security of ECDSA relies on the assumption that it is hard to compute the private key when the public key is given.

The security of ECDSA is broken when the private key can be computed from the public key, because when the private key is known signatures can be forged and there would be no difference between an authentic signature and a forged signature.

This private key can be computed when the public key is given by solving the Elliptic Curve Discrete Logarithm Problem (ECDLP), which can be stated as follows:

Given the public key that is represented by point ‘Q’ on the elliptic curve and a standardized base point ‘P’ on the elliptic curve, find the private key that is represented by the integer ‘a’, such that Q=a*P

In which ‘*’ represents an elliptic curve point multiplication.

This Elliptic Curve Discrete Logarithm Problem (ECDLP) can be solved efficiently using Shor’s algorithm on a large quantum computer, which would then break the security of ECDSA.

Permanent LinkA change from ECDSA-based addresses to quantum-safe addresses would be no small fork, and would potentially require disabling active addresses for a period of time while a fork was implemented, regardless of the specific cryptocurrency. This could have significant deleterious effects on a cryptocurrency-powered blockchain network, and, as we have experienced in creating our own blockchain, could also require the changing of significant sections of the cryptocurrency’s code to accommodate the new security features, drawing into question the feasibility of implementation.

Additionally, one cannot always (or, one could argue, ever) predict when and where technological innovation will rapidly progress. This is especially true of emergent technology, and both blockchain and Quantum Computers would qualify as such. There is potential for an unforeseen/unpublicized advance in Quantum Computing leading to an attack on a cryptocurrency network, and the market-wide realization of the sudden vulnerability of cryptocurrencies that are based on ECDSA signature methods. This would likely cause a “run on the banks” scenario and crash the value of many-if-not-most cryptocurrencies that were secured by ECDSA.

Finally, even if the signature scheme of a particular blockchain platform can be updated to something with Post-Quantum security, there will never be a 100% adoption rate among the total set of wallets. There will always be old wallets which are no longer accessible (due to lost keys) and which cannot be updated, and going forward there will be an ever-larger set of non-technical users unable/unwilling to take necessary steps in a timely fashion should a sudden QC threat emerge. The coins in those old wallets could be vulnerable if the associated account ever broadcast a transaction, and an attacker with a sufficiently powerful quantum computer could accumulate a non-trivial percentage of a coin’s circulating supply and use it to manipulate the price of that cryptocurrency. It is not guaranteed that an attack of this sort would be immediately noticeable.

Permanent LinkQRL is using an digital signature algorithm called XMSS (eXtended Merkle Signature Scheme). XMSS is used to sign transaction messages in order generate valid transactions. XMSS uses a One Time Signature (OTS) scheme that can only sign one message with one key. If you use the same One Time Signature (OTS) key to sign two different messages, an attacker could generate a valid signature for a third message you had never signed before. This might allow an attacker to generate a valid transaction you had never approved. Which is why it is important to keep track of which OTS keys have been used already, so you can use a different OTS key for each message.

Permanent Link