Whilst our current plan is to transition to an abstracted unified transaction format with the release of our ‘silicon’ smart contract platform (pencilled for release mid 2019), we have decided internally to integrate multisignature functionality into the QRL early in our upcoming hard fork.

As this brief blog will describe this adds some unique and powerful functionality to the chain and in doing so will be the first example in the world of post-quantum secure multisignature technology in the wild.

What actually is ‘multisig’?

multisig not multipass!

“Multisig” or multiple signature transactions require one or more different valid signatures to transfer funds from a special construct called a multisignature address to a destination address. The idea being that funds held in a multisignature address cannot be spent without the cryptographic agreement of a specified number of parties.

A multisig address can be setup with a certain number of addresses able to take part (n), of which a specified number (m) must provide valid signatures together for a multisig transaction to be valid and spendable. Thus, a multisig address may be said to require m of n signatures.

An example would be a multisig address which includes three signatory addresses but only requires two signatures for funds to move. This would be: m of n equals 2 of 3.

What all of this means in practice is that it allows custody and control of funds to be made much more transparently secure than current reliance upon access via a single private key or wallet. This is important for bigger clients who may wish to use a particular chain such as institutional investors, hedge funds, etc.

QRL multisig

So how will it work in the QRL? Is it different from other existing solutions? As usual we have to do things slightly differently because of our post-quantum signature scheme XMSS.

Briefly, we will introduce the new tx subtypes multisig_create and multisig_spend in the next hard fork, introducing hard-coded functionality which is immune to the multisig issues seen previously with ethereum.

Creating a new multisig address which can be seen on the explorer and receive funds like any other address is simple — just send a multisig_create transaction. This transaction incorporates a list of valid co-signers (addresses or public keys) and thus n, the weighting of each signatory, w, and the required number of signatories for a successful spend — the m.

example weighting of a multisignature address

What do you mean by ‘weighting’? In conventional multisig each signature counts as a single vote. So, to reach an m of three requires three signatures. Whilst this remains default behaviour in the QRL, our implementation allows a specific signatory address to carry more voting weight than another. We implement this simply by attaching an integer value to each party during multisig address formation.

An example of this would be a new multisig address created in which m of n is 4 of 7. Signatory address 1 has weighting 3, whilst all other signers have weighting 1. Thus, to move funds successfully from the multisig address if signatory address 1 and 2 both sign a valid transaction, then 4 of 7 is satisfied and the transaction will be valid. Similarly, if signatory address 2, 3, 4 and 5 sign a valid transaction then this too would be valid and allow the funds to be spent.

Alternatively, one could create a new multisig address where one address has functional spending control. One could have an m of four required signatures, with an n of four signatory addresses. If address 1 had a weighting of 3, and all the rest had a weighting of 1, then even if addresses 2, 3, and 4 all signed, they would not have the 4 of 4 required signatures to spend.