Update:
I am pleased to report that XMSS is now successfully integrated into the test node. I have also created deterministic addresses within giant XMSS trees from a single recoverable hexSEED / 32 word mnemonic using a provably secure pseudo random number function (HMAC_DRBG).
The QRL test node currently supports 3 types of post-quantum transaction types: 1) Lamport-Diffie one time signatures below a many time merkle tree signature scheme (MSS), 2) Winternitz-OTS signatures with a many time MSS and now 3) XMSS - a recommended post-quantum signature scheme incorporating W-OTS+ and XMSS many time trees. I may remove the support for the first two and focus upon a single tx type with longer keys.
What is interesting is that the signatures with XMSS are roughly 12kb hexlified (~6kb binary). Internode compression of transmitted transactions and blocks may be something to look into as they are currently communicated as plaintext JSON. Creating an XMSS tree which can provide 4096 signatures/transactions safely generates a wallet file size of ~50mb! There are around 330,000 256 bit keys generated (bitmasks, secret/public key fragments etc) for just this single tree. I was perplexed by this as most people like quite a few addresses and this would generate absolutely huge wallet files. But I have discovered a neat way of generating hundreds of addresses within the XMSS tree by simply contracting the merkle tree and recalculating the root value+PK..and voila a new address. New addresses can be added with minimal additional calculation (just need to keep the tree differences) as they share bitmasks and OTS keys with the original.
Releases:
A collaborator has created a blockchain explorer for the QRL (testnet) and we will be making that public once it looks pretty enough
- probably later this week.
Whilst I work on the node he is now working on a client side JS web wallet similar to mymonero which will communicate with a custom node via an API. The general idea is that user supplies a seed word mnemonic and the JS wallet obtains state information from the node. Transactions can be created client side and sent fully formed+signed to the node. It is only as secure as the browser but should suffice for less technical users.
Todo:
There is still plenty of work to be done. The next stage is to declutter some of the code, tidy up the protocol, simplify and better partition the state code, finally sort the currency units and improve reliability of the node - in particular the chain following behaviour.
PoS:
Recently I have had some ideas about implementing a Proof of stake system. I like the idea of using proof of stake in the longer term. I will experiment with introducing a PoS system for the QRL which is very simple but secure. I have been writing my ideas for a protocol in a second whitepaper which I will release after some testing!
More updates as they come..Volunteers welcome as always.
Inca
I am pleased to report that XMSS is now successfully integrated into the test node. I have also created deterministic addresses within giant XMSS trees from a single recoverable hexSEED / 32 word mnemonic using a provably secure pseudo random number function (HMAC_DRBG).
The QRL test node currently supports 3 types of post-quantum transaction types: 1) Lamport-Diffie one time signatures below a many time merkle tree signature scheme (MSS), 2) Winternitz-OTS signatures with a many time MSS and now 3) XMSS - a recommended post-quantum signature scheme incorporating W-OTS+ and XMSS many time trees. I may remove the support for the first two and focus upon a single tx type with longer keys.
What is interesting is that the signatures with XMSS are roughly 12kb hexlified (~6kb binary). Internode compression of transmitted transactions and blocks may be something to look into as they are currently communicated as plaintext JSON. Creating an XMSS tree which can provide 4096 signatures/transactions safely generates a wallet file size of ~50mb! There are around 330,000 256 bit keys generated (bitmasks, secret/public key fragments etc) for just this single tree. I was perplexed by this as most people like quite a few addresses and this would generate absolutely huge wallet files. But I have discovered a neat way of generating hundreds of addresses within the XMSS tree by simply contracting the merkle tree and recalculating the root value+PK..and voila a new address. New addresses can be added with minimal additional calculation (just need to keep the tree differences) as they share bitmasks and OTS keys with the original.
Releases:
A collaborator has created a blockchain explorer for the QRL (testnet) and we will be making that public once it looks pretty enough
- probably later this week. Whilst I work on the node he is now working on a client side JS web wallet similar to mymonero which will communicate with a custom node via an API. The general idea is that user supplies a seed word mnemonic and the JS wallet obtains state information from the node. Transactions can be created client side and sent fully formed+signed to the node. It is only as secure as the browser but should suffice for less technical users.
Todo:
There is still plenty of work to be done. The next stage is to declutter some of the code, tidy up the protocol, simplify and better partition the state code, finally sort the currency units and improve reliability of the node - in particular the chain following behaviour.
PoS:
Recently I have had some ideas about implementing a Proof of stake system. I like the idea of using proof of stake in the longer term. I will experiment with introducing a PoS system for the QRL which is very simple but secure. I have been writing my ideas for a protocol in a second whitepaper which I will release after some testing!
More updates as they come..Volunteers welcome as always.
Inca