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! :-)

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?

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

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. 

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.

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.

Whilst my original intention was simply to integrate post-quantum signatures into a blockchain (which I have done successfully) I did envision the QRL as carrying value. Information can have value of course, but for a blockchain to work the base tokens must be desirable IMO.

It goes without saying that no matter how cool this is - one should never put a private key into a browser.

Whilst your intentions are probably well meaning - please no one actually use this site unless you are able to personally verify the source code.

Inca

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

Yes I won't be developing anything more than the server side code for a webwallet - needs a JS developer although we could fairly easily code up a mymonero clone.

First priority is to complete the node.

The project is still seeking python developers who want to join up. Anyone interested in the benefits that go with joining a project this early PM me.

Happy new year and a profitable 2017 to you all.

Actually the ledger addresses are derived from a modified merkle tree signature scheme (XMSS) in a hypertree construction using hash-based one-time signatures to sign transactions.

But you are correct that at this time the project is to be similar to BTC, featuring a capped upper supply limit, with very limited scripting and an emphasis upon security over scalability (the signatures / transactions are necessarily much bigger than any other crypto ledger thus far).

We are at quite an early stage so some design parameters may change but i am keen to allow bitcoin users to directly import their balances into the chain for a time after the main net goes live.

Thanks for the interest.

Reserved.

I would like to announce that the Quantum Resistant Ledger (QRL) has launched!

The QRL is the first decentralized cryptocurrency which has implemented from the outset to be resistant to both classical and quantum computing attack.

It uses a different system of cryptography to Bitcoin (and all other altcoins) known as XMSS, which is a hash-based digital signature scheme, and provably quantum-resistant.  The ledger will be the first to use quantum-resistant signatures on a blockchain, which provides an ultra secure store of value in the event of a sudden advance in quantum computing (rendering bitcoin, ethereum etc vulnerable to attack). The initial aim of the project is to establish a functional and secure blockchain on which more technology can be built, such as the Ephemeral post-quantum secure data channels.

The project has grown significantly over the course of 2017 and 2018, led by myself, a core dev team, ancillary devs and a post-quantum cryptographer. We have added to that a marketing manager and small communications team.

Our current featureset:

1. Multi-platform qrlcore node release.
2. Multi-platform binary wallets (Mac, Windows, and Linux)
3.User friendly Webwallet (https://wallet.theqrl.org) and Explorer (https://explorer.theqrl.org)
4. 100% PQ-secure address space for the QRL (XMSS)
5. Cryptonight POW algorithm, 1 minute block-time interval, ability to mine in existing pools, using existing mining software.
6. Completely separated wallet and node functionality with all wallet-based requests passing through the node by our universal grpc api.
7. Use of slave XMSS tree signing capability to allow secure mining (and later, staking) keeping private keys offline.
8. PQ-token capability out of the box — creating tokens on the QRL chain is now functional.
9. PQ-secure data stamping functionality out of the box.
10. Two audits covering 100% of our codebase.
11. Full API (https://api.theqrl.org) and Documentation (https://docs.theqrl.org)
12. Offline-wallet-generator: (https://github.com/theQRL/offline-wallet-generator)
13. Hardware wallet support through Ledger Nano S/X

Upcoming hard fork featureset:

1. Multisig addresses
2. Deterministic address support
3. Extended message transaction functionality
4. Decentralised on-chain poll support
5. Backwards incompatible state upgrades and optimisations

Features anticipated for 2019/2020 hard forks include:

1. Smart Contracts (Project Silicon)
2. Ephemeral messaging
3. Consensus mechanism change (PoS, dPoS)

Anyone who wishes to get involved can join our Discord server below. The best way to find out QRL related news would be to keep an eye on Twitter, Reddit, Medium, and/or Discord.

The QRL is currently trading on Bittrex and related international sites.

Genesis Block = 65M coins.
Final distribution in 200 years is 105M (exponential decay in emission).
Blocktime will initially be 60s.

When PoS Comes:
No minimum staking limit. Secure offline staking via deferred stake signatures. .

Feel free to ask any questions.
Many thanks,
Inca

Whitepaper: https://github.com/theQRL/Whitepaper
We now have translations in Japanese, Russian, Chinese, German, French, Turkish, Spanish, & Vietnamese on our website

Website: http://theqrl.org
Discord: https://discord.gg/BheKAZb
GitHub: https://github.com/theQRL
Medium: https://medium.com/the-quantum-resistant-ledger
Twitter: https://twitter.com/qrledger
Subreddit: www.reddit.com/r/QRL /
Facebook: https://www.facebook.com/The-Quantum-Resistant-Ledger-492163101309701/
YouTube: https://www.youtube.com/channel/UCZl6N10P9LNpYkrMwWYtK1w

Email: info@theqrl.org
Support Email: support@theqrl.org

CMC: https://coinmarketcap.com/assets/quantum-resistant-ledger/

Bittrex: https://bittrex.com/Market/Index?MarketName=BTC-QRL
UpBit: https://upbit.com/exchange?code=CRIX.UPBIT.BTC-QRL

Ah it's theymos' alt cobra to the rescue. 

Given you have been censoring discussion on any alternative clients who knows what most active bitcoin users are aware of. It is just electronic cash to most people. Still you have singlehandedly contributed to the decline of market share bitcoin holds within the ecosystem. Oh and lost any vestiges of credibility you ever held in the cryptocurrency space :-)

Longs pretty high at 41M on finex. Shorts extremely high at 23k. Market floating for a giant move. Toss a coin. Hope you are all hedged appropriately after the recent huge gains.

I personally think we have a few months for the market to get acclimatised to this new price point before we charge much higher. But hey this is bitcoin so it could be ATH next week.

 

EDIT: it is worth pointing out that the trolls talking down bitcoin on here are themselves long otherwise they would have left long ago..

Yep expecting upwards volatility for a few weeks. Price could literally go anywhere.