The first planned QRL network hardfork will soon be announced after upcoming Ledger integration.
Future forks will follow an annual/biannual planned upgrade schedule based upon community consensus.
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.
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.
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
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.