Topic: [ANN] QRL - Announcing the Quantum Resistant Ledger - page 86. (Read 186383 times)

A couple of points - 1) this is in early development and not even reached public testnet phase - the amounts floating around the alpha-testnet are not representative of the final chain.. 2) since the white paper the block selection algorithm has changed from proof of work to proof-of-stake. I like the idea of bitcoin balance importation but may ditch it as it reveals the bitcoin public keys of those who do, something i'm obviously not in favour of.

The current plan is for an initial release of the coin supply to allow proof-of-stake to function correctly. Whilst I like the idea of a 21 million upper cap (after 200 years) the exact size is up for debate as is the initial release methodology. New coins generated through p-o-s block creation will tail down with an exponential decline to a hard ceiling - that i can say for sure.

Why do you say the supply seems massive? Ethereum released over 70 million coins, no?!? :-) A release of 2-5 million coins seems reasonable to me in comparison.

Peer review is an interesting and important point. The post-quantum hash-based signature scheme (xmss) has been peer reviewed in the literature. To my knowledge there are only two working implementations of the signature scheme in existence which are open source - mine in python (http://github.com/surg0r/lamport) and a C version by A Hulsing. The QRL is open source and accessible on github (http://github.com/surg0r/QRL with the sig scheme contained entirely in QRL/merkle.py). All peer review very welcome indeed!

This sounds like an interesting project but first a 1:1 balance importation seems very high and the supply seems massive    Has this Quantum resistant ledger been peer reviewed yet and if so by who ?

Update:
- i have exposed the API of one of the vps nodes for the curious to take a peek inside the network from the comfort of the browser. This API powers the upcoming block explorer and an extended version for the web wallet.

http://104.251.219.215:8080/api

Available options are: block_data, stats, txhash, address, last_tx, last_block, richlist, ping, stake_commits, stake_reveals, stakers, next_stakers

With all the updates this week the network and chain resets very regularly but to see an example transaction or five try: http://104.251.219.215:8080/api/last_tx or http://104.251.219.215:8080/api/last_tx/5 . To see the actual data in an XMSS transaction (very different to bitcoin) simply paste the txhash from the last_tx page into: http://104.251.219.215:8080/api/txhash/. (i.e. http://104.251.219.215:8080/api/txhash/04449974ac8f4325760ca4f9e14e5fa17218025acd5a1833289014a04b337d68 although if the network chain resets then it wont exist!) To query an address simply paste it in after api/address/. I.e. http://104.251.219.215:8080/api/address/Q60470c8d6f57968e604753065ff700b506776d97113b00a7afcc347aa11bdbed8471 .

The stats can be seen at http://104.251.219.215:8080/api/stats and the richlist at http://104.251.219.215:8080/api/richlist

Anyone interested in becoming an alpha node tester?

(The only requirement is that you are on linux or mac and are able to run the binary (or install python 2.7 and run the node script if on windows) and that you are willing to leave it running / restart it for each hard fork / reset.

PM me..

First live run on the private testnet with block selection via a Proof of stake mechanism went successfully tonight. Very exciting to see once the nodes got going smoothly. Three nodes scattered across the world with block-times (with ~1s variance) of around 23seconds.

A few changes need to be made to the main node to simplify the code slightly.  A major decision is how to deal with absent stakers from the stake list and whether to punish them and also how to restart the network when it breaks. I expect to make a number of major updates to this effect over the next week or so culminating in the public testnet + block explorer release on March the 4th.


 

To clarify construction of the first iteration of the QRL POS algorithm:

Before each stake cycle transactions with a POS flag containing a signed hash are collected to generate the staker list (or initially placed in genesis for first epoch). The hash is actually the last hash in a iterative hash chain of length 10,000 (the length of each stake cycle). Each block/stake cycle is signed by the staker with a reveal hash going backwards in their respective chain.

After the (block-time-x) seconds every full node sorts their transaction pools by timestamps then txhash and generates a list of merkle root hashes. All nodes should have almost identical pools but due to variance and network latency there may be minor disparities, hence usage of a list rather than a single hash. Stakers broadcast their merkle root hash lists and the POS selector publishes the block. The staker selected to construct the block is chosen via a PRF (HMAC_DRBG) from the stake list. The stake list is updated from new POS tx during the epoch and the next sequence of staker selection is taken from historic chain data.

To prevent a MITM spam attack a commit-reveal scheme is used for both stakers publishing merkle root hash lists of acceptable blocks and before the final signed block is published. i.e. in further detail

1. staker nodes publish a commit stake message which includes a stake address, merkle hash list of tx pool contents and a commit hash of the merkle hash list + previous hash in hash chain.
2. staker nodes collect stake data for a time period and then broadcast a reveal stake message. each node uses these to validate the previous messages. Since all nodes have this information (including the stake block selector) the merkle root tx pool hash which is most frequent is known by all nodes - thus the stakers actually choose the block - the selector merely selects and constructs it correctly.
3. the stake selector publishes a commit block creation message which includes the chosen merkle tx hash, their stake address and a commit hash (blockheader hash or merkle tx hash + prev hash in hash chain).
4. The selector then publishes the block which contains the blockheader and merkle tx hash contained in the commit stake layer message but also the reveal hash which is used to validate the block by the network.

The commit-reveal element could be removed if each stake message is simply signed by the stake address, but in a stateful sig scheme like XMSS this means a huge number of signatures which are expensive to compute, store and decrypt, especially with a short block time like 15-20 seconds, hence the hash chain scheme.

Hopefully 2-3 weeks to implement the first POS iteration in private testnet before I release the node. It is getting exciting! :-)

Do you have an ETA on when this phase will be complete? Interested in following development

Update: fairly big update to the node structure and validation related to POS taking place.
Github and here will be quiet until that phase is complete.
Once updated after some bug fixing the QRL should be ready finally for a public testnet release with binaries for linux/mac and windows.

 

I already use a derivative of merkle sig scheme with winternitz ots + called xmss. But this looks interesting. Sort of like a hardened winternitz signature. I'll look into it further at some point.

Do you mean 'only signed blocks are valid' in the sense that they must be signed from a POS staker address?

Yes. A super long hash tube with a private key on one end and a public key on the other end can be generated. Then you sign bits using successive tube levels.

Every client then knows that only signed blocks are valid. Quantum proof.

Full node cannot change history or create fake histories.

You mean this?: https://www.docdroid.net/mR3fUNS/paper.pdf.html

Try Nakamoto Hash Tube algorithm to sign blocks. If the full node signs two distinct blocks, the key strength collapses. This ensues that no fake histories are created.

Not exactly. We already know what is susceptible: RSA, ECDSA etc. We know that the digital signature scheme backing bitcoin and ethereum etc are vulnerable.

There are several classes of 'quantum safe' signatures of which hash based signatures used in the QRL are the most promising.

Based upon existing mathematics if a sufficiently powerful quantum computer were created by a government then bitcoin (and everything else) would insecure but the QRL would not. But you are right that it is of course theoretical resistance because no such computer exists publicly to attack either chain and test out the hypothesis!

The idea with the QRL is to get crypto ready for this computer advance so we are ahead of the curve. 

So to elaborate, there's no way to test the resistance against anything quantum computing capable, due to technology not being there yet? So as of right now, this quantum resistance is theoretical if I read that correctly?

Thanks. But we do know already that Shor's Algorithm had been used to factor small numbers with early quantum computer prototypes. It is true we may be some way off from such machines breaking ECDSA - but the honest answer is we cannot be sure!

Update: I have begun implementing POS on the test node.

First, congrats for your initiative and work on QRL.

But Quantum Resistant Ledger can not be tested without a Quantum attack, even if you apply theory and mathematics, we are still far from Quantum computing and have no insight about its capabilities.

Whilst the current design has a placeholder sha-256 pow function the testnet release will be proof of stake. With this in mind I will circulate a proportion of the starting ledger balance at genesis.

I'm not entirely knowledgeable with how you have achieved this, but will mining be any different then SHA-256 or Scrypt, X-11, etc.?

Hi guys.

Update:
- blockchain explorer API complete.
- units now accurate down to smallest denomination
- block reward implemented and accurate down to smallest denomination (tricky with python, floating point math inaccurate across OSes, had to use decimal.Decimal)
- started to implement some network latency measurements.
- begun packaging the node as separate binaries in preparation for a testnet release.

Upcoming:
- blockchain explorer to be made public shortly.
- Transition to alpha POS block selection algorithm over next month.

I will be looking for one or more early alpha testers of the test node in the next week or so. Anyone interested in being a Hal Finney please pm me (you will receive a % of the ICO as a reward).

Inca