Bitcoin Forum
August 19, 2017, 09:52:08 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
Author Topic: [ANN] QRL - Announcing the Quantum Resistant Ledger  (Read 91113 times)
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 17, 2017, 12:19:18 PM
 #21

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?

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. 
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503136328
Hero Member
*
Offline Offline

Posts: 1503136328

View Profile Personal Message (Offline)

Ignore
1503136328
Reply with quote  #2

1503136328
Report to moderator
1503136328
Hero Member
*
Offline Offline

Posts: 1503136328

View Profile Personal Message (Offline)

Ignore
1503136328
Reply with quote  #2

1503136328
Report to moderator
2c0de
Full Member
***
Offline Offline

Activity: 139


View Profile
February 17, 2017, 03:36:59 PM
 #22

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.

DHjxvnHB9RirtPbvkovSotn1fY2poNffoi
LWeT4wwDVdJ9x49UcXPyS6CznRpbQFM6nx
0x96273C2FD825f0A2745d917bbbfabD6032dC1aDD
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 17, 2017, 05:38:49 PM
 #23

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

2c0de
Full Member
***
Offline Offline

Activity: 139


View Profile
February 17, 2017, 06:02:03 PM
 #24

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.

DHjxvnHB9RirtPbvkovSotn1fY2poNffoi
LWeT4wwDVdJ9x49UcXPyS6CznRpbQFM6nx
0x96273C2FD825f0A2745d917bbbfabD6032dC1aDD
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 18, 2017, 07:59:05 AM
 #25

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 18, 2017, 12:01:26 PM
 #26

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.

 Cool
mtwelve
Legendary
*
Offline Offline

Activity: 980


Bitcoin Journalist PM for more info


View Profile WWW
February 19, 2017, 01:33:02 AM
 #27

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.

 Cool

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

inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 19, 2017, 02:28:01 AM
 #28

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.

 Cool

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

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

Activity: 1162


View Profile
February 19, 2017, 01:38:09 PM
 #29

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 26, 2017, 03:33:22 AM
 #30

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.


 Cool
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 26, 2017, 07:44:47 PM
 #31

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.. Grin
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
February 27, 2017, 07:48:06 PM
 #32

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
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 27, 2017, 08:30:46 PM
 #33

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

Activity: 1162


View Profile
February 27, 2017, 09:11:33 PM
 #34

This sounds like an interesting project but first a 1:1 balance importation seems very high and the supply seems massive  Undecided  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
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 02, 2017, 06:25:08 PM
 #35

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 04, 2017, 10:15:03 PM
 #36

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.. Grin
inca
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 06, 2017, 03:21:30 PM
 #37

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 10, 2017, 03:50:29 PM
 #38

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 20, 2017, 06:09:24 PM
 #39

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
March 21, 2017, 12:42:42 PM
 #40

Question for the lurkers:
We are toying with the idea of distributing a customised PI with our pre-sale planned launch (think aluminium case with logo engraved) to act as a plug and play hardware node which automatically stakes on the network. Early experience from two of our developers is that the test node runs well on a PI 2 and at this point we are tinkering with validation rules and node behaviour so it is unlikely to require more extravagant hardware going forward.

Is this something people find appealing? I personally think it sounds pretty cool :-) (examples of similar cases can be seen at: http://www.raspberry-pi-case.com)

Inca

http://theqrl.org
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!