The first planned QRL network hardfork will soon be announced.
Future forks will follow an annual/biannual planned upgrade schedule based upon community consensus.
To extend functionality of the QRL beyond the ledger an off-chain network messaging system known as ‘ephemeral’ is proposed. These lifespan-limited internode broadcast messages may be relayed and stored optionally by agreeable qrl-nodes.
A simple initial format with some DDOS protection is suggested, allowing custom implementations from users or applications wishing to interact with the QRL ledger/network.
A suggested message format is:
Ephemeral message | ID | PAYLOAD |TTL |BLOCKHASH | POW — | — | — | — | — | —
The ID field is a 64 byte identifier. It may be accessed as a complete ID field or two 32 byte separate identifiers (ID0 and ID1). The ID is intended to be a unique nonce.
The payload is the body of the message containing user data. The precise contents are left open but some example schemes will be suggested in a future QIP to enable powerful end-end encrypted data channels. Max field length = 8192 bytes.
TTL is a 32 bit network expiry timestamp following unix time specification. This ‘time to live’ value is a timestamp upon which the network renders the message invalid and proceeds with deletion. Whilst messages are relayed across the network by agreeable nodes they are only held transiently until they expire - hence ‘ephemeral’. Alternatively, this could be replaced with a blockheight?
The first 4 bytes of a recent QRL block-header hash must be supplied as a rough message timestamp. The chance of a random 4 byte guess being successful is
allowed_ephemeral_message_blockdepth/2^32. In combination with POW this prevents a determined attacker grinding out a huge number of messages over a long period of time which are then used to flood the network.
POW. Any broadcast protocol is susceptible to spam and each message passed through the network will require a variable amount of ‘work’ to be performed and verified via a supplied pow hash prepended by a byte pow algorithm identifier. This adds a small amount of computation time to confirm message validity. Furthermore, the amount of work required is linked to the TTL expiry timestamp - the longer the shelf-life of the message, the greater work must be expended to attain validity. The pow is performed on a cryptographic hash digest of the message
(SHA2_256(ID+PAYLOAD+TTL+BLOCKHASH)), with the resultant pow hash (and prepended byte) appended as the final field of the message.
Activating ephemeral messaging requires minor changes to the qrl-node python and go implementations to relay and prioritise additional traffic. It is anticipated the vast majority of traffic will occur using open source public off-chain centralised message repositories.
New qrl-node configuration parameters for:
Furthermore, to allow encrypted data channels via ephemeral messages across the network, lattice tx featuring embedded Dilithium and Kyber pk’s must be activated. This requires a hard fork upgrade to all network nodes. Specific end-end data channel cryptographic implementations will be discussed in future QIPs.
One of the biggest potential use cases of blockchains in the future is the tokenization of existing securities to be bought and sold by valid parties. Being the only existing blockchain that is quantum resistant from genesis and adding the functionality of smart contracts, QRL is in a unique spot to capitalize on this opportunity. The QRL team should evaluate whether the functionality of the smart contracts that are currently in progress can support the tokenization of securities on the QRL blockchain. If that is not the case, the team should consider adding additional functionality that allows for such tokenization.
The current usefulness of blockchain is highly debated, and there is much conversation about what “killer app” will eventually drive adoption. One current use of blockchain is speculation, and it is very attractive in this area due to the ability to buy fractions of a coin or token. In contrast, many traditional assets require the purchase of an integer number of the asset. For example, it is difficult to obtain a fraction of a stock or real estate property.
Traditional assets, including stocks, real estate, and derivatives, are estimated to be worth a combined amount of over one quadrillion dollars (source: https://money.visualcapitalist.com/worlds-money-markets-one-visualization-2017/). There is incentive to tokenize existing securites and offer new securities on the blockchain, including the “removal of middlemen… to lower fees, faster deal execution, free market exposure, larger potential investor base, automated service functions, and lack of financial institution manipulation” (source: https://medium.com/@apompliano/the-official-guide-to-tokenized-securities-44e8342bb24f). In addition, security tokenization would raise the credibility of blockchain in the eyes of many traditional investors, as there would be “real value” in the underlying assets.
As of now, QRL is the only existing blockchain that is quantum resistance from genesis and implementing smart-contract functionality. Such functionality is necessary for the tokenization of securities, as the buying and selling of securities is restricted by KYC/AML laws. Given QRL’s unmatched quantum resistance and future-oriented security, the QRL blockchain could be a very attractive platform for security tokenization.
The purpose of this QIP is to urge the QRL team to evaluate whether or not the in-progress smart-contract functionality can support the creation and exchange of security tokens. QRL smart contracts are limited in functionality compared to ETH (where security token standards are currently being created), so the author does not automatically assume that such functionality currently exists. If it does not, consideration should be given to add such functionality.
QRL already has the ability to create tokens, but to be compliant with regulations, it must be possible to restrict transactions of security tokens between wallets if the sending and receiving wallets do not meet certain criteria (example: https://thesecuritytokenstandard.org/); therefore, it would have to be possible to make these checks before a token transaction is admitted to the blockchain.
Several entities are working on platforms for tokenization of securities. Polymath, Harbor, Securrency, and tZero are prominent examples. It may be worth reaching out to them for evaluation and implementation.
Purpose of this QIP is to implement a dPoW mechanisme to strengthen QRL protection against attacks like 51%
Because security is the first concern of QRL project, we have to consider all solutions that can improve its security.
Thanks to hash power provider like NiceHash, we know that it is possible to perform a 51% attack against QRL blockchain for little amount of money.
A test done by a community member (curefrankosflue) demonstrates this figures : “20 MH/s @ 0.0090 BTC /(MH/s x day) means 0.0075 BTC/hour, which turns out the cost of a 5 hour attack at 20mhs to be at 0.0375 BTC or 150 $”
Some projects like Komodo solves this issues by using BTC blockchain to benefit from its hash power.
Also, some project like VeriBlock propose to better secure alternative crypto asset networks using Bitcoin blockchain (concept of proof-of-proof (PoP))
QRL should evaluate the level of protection afforded by lowering the reorg limit versus a DPOW solution that would be based on BTC hashpower.
Message transactions sent on the QRL blockchain network allow broadcast and decentralised storage of 80 bytes of data per transaction for purposes such as notarisation and data stamping. This minor QIP extends the message transaction format to include an optional payee/receipt address.
It would be useful to direct message transactions to a specific destination address rather than simply writing them into the chain in a broadcast manner.
Potential benefits include: 1) allowing message-based interaction between user and smart contract addresses 2) enabling user addresses to exchange message data directly between themselves
For example a smart contract may be scripted to perform certain actions based upon specific message transaction input from a given address. Or a smart contract address associated with a user address could alert a user address with a message transaction if certain thresholds are met (such as changes in balance) or to acknowledge receipt of a payment from a user address to a payee contract address.
Adding a destination address also allows future consensus voting within the QRL network to be refined. (i.e. voting for a specific QIP proposal, contentious network decision or election of addresses to positions of authority within smart contract constructions such as multisignature contract wallets).
Whilst a minor extension to the existing message transaction format this is not backwards compatible with existing versions of qrl-node and therefore requires a hard fork.
Purpose of this QIP is to initiate development of multi signature wallet support on QRL network, based on finalised specification.
Currently, QRL doesn’t have support to multi-signature wallet address. So to execute any transaction only a proof of signature is required either by the main address or the slave address. Thus the introduction of multi-signature wallet address will fill this gap and will allow multiple authorities to have a transaction from a single wallet once the consent has been established.
In order to create and spend from a multisig wallet new transaction types are required. multisig_create and multisig_spend are the two new transaction types which will be introducted to support multisig wallet.
multisig_create transaction type will be used to create a new multi sig wallet. It will have following input fields other than common transaction fields.
multisig_spend transaction type is to move funds from a multisig wallet to another address which could be a normal qrl address or another multisig address. It will have following input fields other than common transaction fields.
multisig_spend transaction will only be executed once minimum required threshold is met.
MultiSig addresses will be derived by following to maintain the standard QRL address format.
Prefix ‘Q’ + 3 bytes descriptor + hash of (descriptor + txn hash) + last 4 bytes of the hash of (descriptor + previous hash)
Descriptor Format (https://docs.theqrl.org/developers/address/)
|HF||0 .. 3||4||SHA2-256|
|SIG||4 .. 7||4||Signature Scheme|
|P1||8 .. 11||4||Height|
|P2||12 .. 15||4||Address Format|
|P3||16 .. 23||8||Not used|
So a multi sig address generated by multisig_create transaction having transaction hash 5a4c37ef7e5b7cc5a2a58ab730269ed8f4cbf08a005dc3508e31465535e1d6bb will be derived by following
Prefix = ‘Q’
Descriptor = 110000
SHA2_256(Descriptor+Txn hash) = 3674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7
SHA2_256(Descriptor+Prev Hash) = fe2088fb
MultiSig Address = Q1100003674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7fe2088fb
The introduction of multisig wallet on QRL Node will need a hard fork, as two new transaction will be introduced in it. Therefore, the changes will not be backward compatible.
Implementation of Multisig wallet is in progress.
Extended address functionality from master XMSS wallet
A suggested change to generate multiple deterministic addresses which may be signed using the XMSS tree associated with a user master address.
Currently QRL uses XMSS to sign transactions and create a single re-usable address for users. Prior to signing a transaction the XMSS tree must be generated with varying computational cost dependent upon the signature capability of the address. Further signature capability may be added by signing slave XMSS trees to extend this scheme infinitely.
However, it would be valuable for users to have access to more than one address from which to send or receive QRL, without the prospect of adding significant computation time and worsening the user experience by generating additional XMSS trees. Given QRL is a public blockchain, such a facility would improve privacy for those not wishing to unnecessarily reveal their primary address balance and transaction history to a payor. i.e. a payor may be given an address to send funds to other than the user master address. Additionally, the easy creation of deterministic addresses allows privacy extension through deliberate usage of one of more change addresses to obfuscate user holdings.
A 51 byte unique seed is used to generate a user wallet in the node or webwallet. The first three bytes are extended seed encoding with the following 48 bytes of random entropy providing the cryptographic seed used in PRF generation of the XMSS tree and subsequent master address.
In addition to the master XMSS tree, the 48 byte random seed may, in a cryptographically secure fashion, be used to generate a deterministic sequence of pseudorandom 32 byte values. This sequence can be trivially generated computationally yet retain the appearance of uniform random output when revealed to an external observer. Furthermore, the seed may not be determined using any or all of the PRF sequence values.
prf_output = SHAKE128(SHA_256(SHA_256(SHA_256(seed[:32] ^ SHA_256(seed[32:])))))
i.e. the first 32 bytes of the seed are xored with a hash of the last 16 bytes of the seed and the result is iteratively hashed three times then passed as input into SHAKE128, where output may be derived as a 256 bit pseudorandom deterministic number sequence.
Existing address format:
An existing standard address is created with the following format (pseudocode):
QRL_address = encoding_bytes + hash_function(xmss_pk)
encoding_bytes includes the required hash function, signature scheme, xmss tree height etc
xmss_pk = master_xmss_tree_merkle_root + xmss_public_seed
Suggested new extensible address creation:
Assuming a PRF sequence,
prf[n], an additional address may be simply created like:
extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n])
In this way, with each new value in the
prf sequence a resultant new address is created for use.
Additionally, a user field such as the hash of a pin or seed phrase may be added to generate a different series of addresses.
extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n] + hash_of_user_generated_data)
For ease the address
encoding_bytes must match the master address XMSS tree encoding to allow appropriate decoding during spend transaction processing.
QRL uses re-usable addresses. An example transaction may move part of the funds from address
b. After such a standard transfer transaction an outside observer can see precisely what funds remain in the user controlled master address
The addition of multiple deterministic addresses to a master address means that the following is now possible: all funds may move from
c and perhaps
d. The balance of
a is now zero, and an outside observer will not know that some funds were moved to address
b and that the user controlling
a actually controls the addresses
Whilst the effective final balances of the two users in the transfer transaction remain the same – to an outside observer the precise movements and control of funds are obfuscated.
Optional fields (
.extended_pk_address_user) to be concatenated and hashed with pk must be added into the transaction logic in the base
Transaction class. Minor state changes required to associate extended addresses with existing master address pk’s following a spend transaction (to preserve OTS safety).
Higher level changes required in terms of tracking, displaying balances and allowing spend functionality from within the webwallet. This latter point will require internal discussion.
The QRL network supports arbitrary messages up to 80 bytes in length to be stored on chain through the MessageTransaction transaction subtype.
There is the capability for second layer clients to read and interpret the data contained within these message transactions, and format interfaces accordingly. This can be seen with the currently implemented
Document Notarisation transaction type found on both the QRL Wallet and QRL Explorer applications, and further implemented in the explorer-helpers repository.
This QIP aims to create a new base layer for a standard message encoding format such that other usecases have a framework to build within - for example the coinvote proposal mentioned by @surg0r.
The following will describe the base requirements to indicate a message contains encoded data, and provide further context on earlier usage as has been implemented in the
Document Notarisation transaction type.
There are a total of 80 bytes available in a MessageTransaction transaction that are usable. For the purposes of describing the format in this document, we will represent all data as HEX strings. It is worth noting however that the data is later converted to binary bytes for storage by a QRL node.
To indicate a message is an encoded message, the first two bytes are reserved for the following HEX string:
The subsequent two bytes should indicate a unique encoded message transaction type. Each proposal to the community for a new encoded message type will be allocated a unique HEX string for these bytes for client implementations.
The remaining 76 bytes contain any data relevant to the encoded message, and should be proposed to the community through a QIP.
If this QIP is accepted, a record of accepted message transaction sub type and their respective QIP should be kept updated on docs.theqrl.org such that client implementations have the technical detail available to implement with ease. A Github repository will be setup on https://github.com/theQRL/standard-message-encoding to allow community pull requests into this standard encoding format.
The following describes the structure of the
Document Notarisation message transaction sub type for historical purposes. There are approximately 25 transactions from early stages of the network that utilise this format. It is optional to implement for display purposes.
First 2 bytes:
AFAF - Indicates encoded message.
Subsequent Half byte:
A - Indicates this is a document notarisation message transaction sub type.
Subsequent Half byte:
3 indicating which hash function has been used to notarise the document as per below:
1 - SHA1 (Now deprecated in user interfaces when notarising a document)
2 - SHA256
3 - MD5 (Now deprecated in user interfaces when notarising a document)
The remaining 77 bytes are reserved for both the hash of the document, and a variable amount of free form text depending which hash function was use. For each hash function above, the following describes the remaining 77 bytes utilisation.
1 - SHA1 - Subsequent 20 bytes store the SHA1 hash, with the remaining 57 bytes available for free form text.
2 - SHA256 - Subsequent 32 bytes store the SHA256 hash, with the remaining 45 bytes available for free form text.
3 - MD5 - Subsequent 16 bytes store the SHA1 hash, with the remaining 61 bytes available for free form text.
No immediate implementation work is required for this QIP as it simply states a standard for encoding messages using the QRL networks
MessageTransaction transaction type.
This QIP explores the feasibility of migrating to Cryptonote v8, and continuing to change the POW algorithm just like Monero.
ASIC resistance is the most obvious reason, so that GPU miners can participate, thus making mining truly decentralized, instead of the select few who can afford to buy and setup ASICs.
Currently, qryptonight implements Cryptonote v7 via hooking into a few important files in xmr-stak, and putting a SWIG wrapper around it.
Since xmr-stak 2.5.0 (931bd5fef17f908afc62836ae7b6ea087d1441ca, unify cpu cryptonight implementations), the internals have changed enough that qryptonight needs to be modified, and xmr-stak needs to be forked.
Once this is done, having qryptonight use Cryptonote v8 is as simple as changing this line:
Cryptonight_hash<1>::template hash<cryptonight_monero, false, false>(input.data(), input.size(), output.data(), &context);
Cryptonight_hash<1>::template hash<cryptonight_monero_v8, false, false>(input.data(), input.size(), output.data(), &context);
This breaks the following tests:
TestChainManagerReal.test_add_block TestChainManagerReal.test_multi_output_transaction_add_block TestChainManagerReal.test_simple_add_block TestBlockHeader.test_hash TestBlockHeader.test_hash_nonce TestQryptonight.test_hash TestQryptonight.test_hash2 TestQryptonight.test_hash3
From these tests it appears that the code does not depend too much on the POW algorithm, which is good news.
Both algorithms will need to be present in qryptonight, and qryptonight must be modified to accept an extra argument that specifies which hashing algorithm should be used.
The best place for the node to decide which hashing algorithm should be used is
The exact block height from which Cryptonote v8 should be used instead of v7 should be defined in
This work will have to be duplicated in go-qrl.
Should Monero’s future POW algorithms require a different amount of memory than Cryptonight v7/v8, further modifications need to be made to qryptonight and xmr-stak in