"Pre-launch Development Plan
Security
To improve the overall security of accounts, we are implementing the BIP39 scheme for first and second passphrases, i.e. a string of 12 words. By additionally salting the second passphrase we are aiming to prevent rainbow table attacks. Additionally, users who are using multiple Lisk accounts with the same second passphrase will become more difficult to trace.
• Enforce mnemonic checksum (BIP39) on passphrases (1st & 2nd).
• Salting the second passphrase with the public key of the first passphrase.
• Fix recently discovered XSS attack vulnerabilities."
Dose this related to the upcoming Lisk clients only? or also to our validated ICO addresses??
I never had a second passphrase, just the 12 word key I generated during the ICO
The "12 word key" generated during the ICO
IS your first passphrase. The second passphrase is optional and can be configured later in the client against a small network fee. The words in the "12 word key" are called mnemonics. The checksum makes sure that the specific format (12 words) are used. The generated passphrases during the ICO already follow this principle, which is explained in the BIP39 (Bitcoin Improvement Proposal #39).
So you don't need to worry about anything. All is OK. If you ask yourself why we do this. I saw MANY passphrases cracked at Nxt, because people chose easily passphrases. The BIP39 passphrases are extremely secure and uncrackable in the next centuries.
Also shouldnt they have tested it before and then announce a date? I feel like this is going to be the most dissapointing ico of 2016.
We thought that the Crypti code base would be more robust. We already implemented a lot of improvements and Lisk is not just a Crypti fork anymore. It's a completely new "beast" now.
"As planned", "Delay", "promised release date",…
Am I the only one remembering that all given dates before were ESTIMATIONS? They never promised anything, up until now. May 24th is the FIRST release date that they are firm on.
Correct.
So let's skip the FUD and discuss some bottom-line facts.
What broke the Lisk 0.1.4 network was 600 transactions in a minute or 10 transactions per second (10 tps).
For years, Bitcoin has been limited to 7 tps until changes made to cope with its DDoS attack last year.
https://blog.blockcypher.com/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4#.mypx90hpi
http://fc16.ifca.ai/bitcoin/papers/BHMW16.pdf@liskhq : What tps figure is the new and improved Lisk 0.1.5 network designed to support? What tps figure has been demonstrated in testing?
A major change made by BTC has been modifications in their transaction queueing system that stores excessive incoming transactions for processing during later blocktimes. Basically they store on the machines of individual miners those transactions that cannot be processed immediately. The miners then resubmit those transactions for processing at a later time.
What is the buffer size in Lisk 0.1.5 among the 101 Active Delegates (both in bytes and in transactions) that stores "excessive" transactions for later processing during future blocktimes?
We successfully tested 3 full rounds with 50tx per block, i.e. 16200tx per hour. We are certain that later on there is
much more upside potential. We are just taking the more reliable/secure route right now and set the limit to 25tx per block. The new version will be 0.2.0 because it's quite a big update.
Regarding the "buffer size" which is called payload in Lisk, I'm not 100% certain. Better ask Oliver later on the Lisk Chat or forum. However, a regular transaction requires 117 bytes (without 2nd passphrase). The payload maximum size is currently 1MB. That means (1024*1024)/117=8962 tx. This can obviously be increased. As I said, better ask Oliver for this.
I just quote ETH tps to make a comparison:
How many TPS does Ethereum support
between 20 tps to 45 tps. possibly more.
With CASPER and future iterations what will the block times and tps be?
1-2 second block times and 115000 tps.
You know it's marketing. Same as BitShares 100000 tps and in the end they can handle 1000 tps. Our numbers look small in that regard right now, but (1) much volume will happen on our sidechains only and (2) we will gradually increase our supported tps.
