[ANN] QRL - Announcing the Quantum Resistant Ledger

[inca]

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.

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

[1713562796]

1713562796

[1713562796]

1713562796

[1713562796]

1713562796

[1713562796]

1713562796

[1713562796]

1713562796

[2c0de]

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.

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

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.

[inca]

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.

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

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.

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?

[inca]

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.

 

[mtwelve]

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.

 

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

[inca]

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.

 

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

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

[inca]

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.

[inca]

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.


 

[inca]

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..

[inca]

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/<paste in here the txid>. (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/<paste here>. 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

[calkob]

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 ?

[inca]

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 ?

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!

[inca]

To the users who have expressed an interest in running a test node I will be in touch by PM in the next 24 hours with a slack invite for you. Thanks for the interest.

[inca]

A few major updates to the codebase this last couple of days. POS further implemented, recovery from hexseed and mnemonic words in the node client and an alpha block explorer:

http://crumble.org/~john/qrl/

(block navigation not yet active, nor seeing keys, sig and merkle tree in the txhashes.. but basic txsearch, address search functionality present..plus realtime update of network stats, stake validators latest blocks and transactions..)

Inching closer to a public testnet node release..

[inca]

Some further strides towards a public testnet release..

I have several volunteers and people who have expressed interest in joining the team. Anyone else who thinks they have anything to offer please PM me and I will invite you to the QRL slack. At some point in the next week or so I will release a short whitepaper detailing the current Proof-of-stake algorithm design for the QRL and of course all discourse, debate and opinion are welcome.

Inca

[inca]

We have a short blog post discussing blockchains and quantum computers.

https://medium.com/@surg0r/blockchain-is-here-to-stay-but-for-how-long-536336a02b03#.q6yc5coa6.

Inca

EDIT: we are looking for a logo artist, anyone interested please PM me. Thanks.

[inca]

UPDATE:

Three iterations of POS later and testnet is back up for testing. The current algo uses a pseudorandom number function (HMAC_DRBG) and the closest hash of stake validator reveal hashes within signed hash chains is used as a block selector mechanism. It cannot be easily gamed because signed hash chains are written to the chain in advance of the PRF seed being generated. As each hash chain reveal hash is unknown until block voting and funds are locked for the epoch (10000 blocks) the capacity to gain block reward by moving funds and colluding is neutered. Sybil attack with lots of stake validators is countered by weighting block reward by address balance. Additionally, a flexible rule to limit block selection to the top x stake validators each round is designed to prevent a block witholding or transaction witholding attack from low value Sybil stake addresses.

The team has grown with the addition of three more Devs and a project manager.

As always, enquiries welcome as the project gathers pace @ http://theqrl.org. You can also register your interest for a future launch there.

[inca]

UPDATE:

We continue to tweak our POS protocol and i think are in to the fine tuning stage. Once our stability issues are sorted we will try to massively expand the number of nodes on the network to see if it holds up.

Our little project has started to leak out into the crypto media sphere!

A first news article about us:

https://www.cryptocoinsnews.com/quantum-resistant-ledger-readies-battle-quantum-computing-hires-testers-seeks-feedback/
https://hacked.com

As always anyone interested in further details: http://theqrl.org

Inca

[inca]

UPDATE:

I am very pleased to announce that finally the test node is running with a prototype final draft design of the POS protocol and after a wobbly start is chugging along nicely with multiple stake validator nodes! Numerous bug fixes, stability fixes and features to be added still. But we are approaching a MVP / public testnet now and the end is in sight. Prediction is difficult but I would expect another couple of weeks of coding until we are stable for public testing.

TEAM:

We have added a marketeer to the team and a slew of alpha testers in preparation for pushing our POS protocol to the limit with higher node counts.

Once again thanks for the interest, particularly those who have emailed directly. Anyone with an interest in the project, either development, testing or simply to discuss the signatures or POS design feel free to PM me for an invite to our slack (or leave your details on http://theqrl.org).

Inca.

[inca]

Update:

Alpha testnet successfully running with 12 nodes earlier. POS protocol running smoothly. Test transactions sent from UK, US, New Zealand, Japan and the Netherlands.

So far up to block 2987 with a 40s block-time. The real test is when all nodes are able to stake the next epoch at block 10000 and whether there is a smooth transition.

Not a bad start to the QRL network testing phase. Next we increase the number of nodes and start capacity testing with transaction spamming scripts, and then the fun bit, try to attack it.

Inca