[ANN][LSK] Lisk | Blockchain Application Platform for JavaScript Developers

[Poly#Crypto]

No, according to this I was right, all collected funds will be paid out once the lisk network has FORGED it's first block which requires Forging.

You are talking about community forging. There was no such requirement. Forging has been happening since the first block, every block.
But don't we have better things to do than argue about the whys and hows of lisk funds?

?  Don't know if I agree on that explanation or definition but yeah, I'm done here.

This thread is all yours poly crypto.

This is not my thread, it's the Lisk Thread.
And I haven't made the rules.


...
In terms of the ICO funds that means they have to flow directly into the company itself. I.e. we are not allowed to lay a finger on them for even one second. However, this is not a problem!
...


https://blog.lisk.io/lisk-community-meeting-summary-june-11th-50dcadd41fef#.lf413d603

[Vega]

Okay, one last post about this, as I don't really care, as the funds will remain in escrow until a legal solution is found no matter what.

This is not my thread, it's the Lisk Thread.
And I haven't made the rules.


...
In terms of the ICO funds that means they have to flow directly into the company itself. I.e. we are not allowed to lay a finger on them for even one second. However, this is not a problem!
...


https://blog.lisk.io/lisk-community-meeting-summary-june-11th-50dcadd41fef#.lf413d603

That statement you quoted is simply not correct. No matter what they say they can't overwrite the original terms. They can choose not to touch the funds as long as they want, but the original terms were clear.

I agree, that there is some ambiguity of wording, but not that much.

From part II of ICO terms:

The Lisk team won’t have access to any funds at all, until the Lisk mainnet is launched successfully.

https://blog.lisk.io/lisk-ico-terms-part-ii-3b50ab74c9b6

From part III of ICO terms:

All collected funds (BTC and XCR) will be paid out, once the Lisk network has forged its first blocks successfully. Both escrow partners have agreed to this condition.

https://blog.lisk.io/lisk-ico-terms-part-iii-604e55ad0102#.y0zu7djab

So the intent of escrow terms was clear.

There is also a fact that every time a genesis delegate signs a block it's log has a line like this:

Forged new block id: height: X round: X slot: X reward: 0

And that's pretty much counts as forging in my book.

[cannabanana]

Okay, one last post about this, as I don't really care, as the funds will remain in escrow until a legal solution is found no matter what.

This is not my thread, it's the Lisk Thread.
And I haven't made the rules.


...
In terms of the ICO funds that means they have to flow directly into the company itself. I.e. we are not allowed to lay a finger on them for even one second. However, this is not a problem!
...


https://blog.lisk.io/lisk-community-meeting-summary-june-11th-50dcadd41fef#.lf413d603

That statement you quoted is simply not correct. No matter what they say they can't overwrite the original terms. They can choose not to touch the funds as long as they want, but the original terms were clear.

I agree, that there is some ambiguity of wording, but not that much.

From part II of ICO terms:

The Lisk team won’t have access to any funds at all, until the Lisk mainnet is launched successfully.

https://blog.lisk.io/lisk-ico-terms-part-ii-3b50ab74c9b6

From part III of ICO terms:

All collected funds (BTC and XCR) will be paid out, once the Lisk network has forged its first blocks successfully. Both escrow partners have agreed to this condition.

https://blog.lisk.io/lisk-ico-terms-part-iii-604e55ad0102#.y0zu7djab

So the intent of escrow terms was clear.

There is also a fact that every time a genesis delegate signs a block it's log has a line like this:

Forged new block id: height: X round: X slot: X reward: 0

And that's pretty much counts as forging in my book.

yeah, you're right then.

[honolulumark]

torrent

What went wrong in the past months, cannabanana?

[bitseedmike]

Nothing to worry about

I see this project as a long term investment. The lower the price, the more I buy.. Especially if you see how ambitious Max is.  He is young, has the knowledge and the money. Maybe not very experienced yet. But with the right people around him, I know he will manage this together with Oliver.

Written very well.
Besides, currently so many users have a good chance to invest in Lisk at a fair price. And the risk for investors is relatively small.

Yes, my outlook as well. I don't see more than a 50% potential downside in the short term, and a longer term upside of 10X to 80X in the next few years. As I mentioned early on shortly after Lisk was announced, Max and Oliver have grit, and continue to show it, and this is what makes for hugely successful companies. From Peter Diamandis, about grit, http://peterdiamandis.tumblr.com/post/125682464568/grit-so-important

[bitman008]

the price has dropped only 1/3 of the high.

[malcovixeffect]

the price has dropped only 1/3 of the high.

Did your balls shrink from the incident?

Cos im buying

[vlom]

I read in Lisk chat that the team has not access to their funds? Is it correct?

At the moment they do not have access.

What needs to happen for them to receive their funds?

forging

This is not true.
You were here from the beginning and you know exactly, the condition for access to the ICO Fund was the establishment of the company. (former gGmbH) So far...

So write the truth please. If you have questions, join the Lisk Chat or ask Max directly.

dude, grab that stick that's shoved up your ass and pull it out.  I'm not trying to be an ass here, but you seem to have a problem with everyone.

And yes, I was here since the beginning before the ICO. The promise was NOT the formation of the organization structure but literally the escrow release was based on FORGING.

Somewhere between the First promise and now it has been changed.  

What? Lol  

crazy kids tonight

call me a liar one more time, I usually keep my mouth shut on Shit but if you want, I can release a torrent of stupid shit about LISK that has happened over the past 6 months in the background.

well. then do it. i want to read this behind the scene news. or are just talking again like a few month ago?

[lokojones]

If you bought in at ICO, you better take the remaining Profit and run!
You could get in later again... don´t think it will blow up suddenly.

I didnt sell on 50K why I would like to sell on 20K? mind blowing:)

If you believe in this project like me, relax... for at least 2years:) I dont care for the rest of the noobs and short time gain cowboys.

[bitbitch]

I read in Lisk chat that the team has not access to their funds? Is it correct?

At the moment they do not have access.

What needs to happen for them to receive their funds?

forging

This is not true.
You were here from the beginning and you know exactly, the condition for access to the ICO Funds was the establishment of the company. (former gGmbH) So far...

So write the truth please. If you have questions, join the Lisk Chat or ask Max directly.

true, but i think there was a not unfair assumption back then that before now Lisk would have incorporated and accessed the ICO funds, hired developers, and be well on the way to forging. None of this has happened. A CEO takes credit when things go well, and must take criticism when things go nowhere.

[bitbitch]

I read in Lisk chat that the team has not access to their funds? Is it correct?

At the moment they do not have access.

What needs to happen for them to receive their funds?

forging

This is not true.
You were here from the beginning and you know exactly, the condition for access to the ICO Fund was the establishment of the company. (former gGmbH) So far...

So write the truth please. If you have questions, join the Lisk Chat or ask Max directly.

dude, grab that stick that's shoved up your ass and pull it out.  I'm not trying to be an ass here, but you seem to have a problem with everyone.

And yes, I was here since the beginning before the ICO. The promise was NOT the formation of the organization structure but literally the escrow release was based on FORGING.

Somewhere between the First promise and now it has been changed.  

What? Lol  

crazy kids tonight

call me a liar one more time, I usually keep my mouth shut on Shit but if you want, I can release a torrent of stupid shit about LISK that has happened over the past 6 months in the background.

 
Not one more time. So far I've never spoken to you directly here in Lisk Thread because I've been ignoring you for a long time.
Is not personal against you, just against your comments.

But YES, tell us all about Lisk. It is a free world, free speech, what are you waiting for...? I am open to all opinions. The only key is: it should be the truth.

My suggestion:
You read again all the announcements and articles on the Lisk blog. Then you feel better I hope. No stress, no hate, no evil words  

The Lisk blog has a fair amount of what i would call 'window dressing' that obscures the true state of things in the back room that we are not being allowed to see. Max needs to be a little more transparent. He's not the CEO of a top secret military project. This is a peer to peer project, which to my mind is a shared experience. He could learn a lot and make faster progress my opening up to the community more rather than insisting that he knows best. He seems a bit inflexible in his thinking.

Incorporating unlocks the ICO funds. That's been the delay on this project ever since the end of the ICO.

[Poly#Crypto]

true, but i think there was a not unfair assumption back then that before now Lisk would have incorporated and accessed the ICO funds, hired developers, and be well on the way to forging. None of this has happened. A CEO takes credit when things go well, and must take criticism when things go nowhere.

Max needs to be a little more transparent. He's not the CEO of a top secret military project. This is a peer to peer project, which to my mind is a shared experience. He could learn a lot and make faster progress my opening up to the community more rather than insisting that he knows best. He seems a bit inflexible in his thinking.

I think Max is also open to constructive criticism.
In the past Lisk has held so many community meetings. And every user had the opportunity to ask questions or criticize the team for publicity... however. At the last meeting, there were only 7 previously collected questions. And the number of participants was not very large. I wonder if all you guys have so many questions, why you don't take a part in such meetings?

Max needs to be a little more transparent
What exactly do you mean? What points are non transparent? What information do you miss?

[bitbitch]

true, but i think there was a not unfair assumption back then that before now Lisk would have incorporated and accessed the ICO funds, hired developers, and be well on the way to forging. None of this has happened. A CEO takes credit when things go well, and must take criticism when things go nowhere.

Max needs to be a little more transparent. He's not the CEO of a top secret military project. This is a peer to peer project, which to my mind is a shared experience. He could learn a lot and make faster progress my opening up to the community more rather than insisting that he knows best. He seems a bit inflexible in his thinking.

I think Max is also open to constructive criticism.
In the past Lisk has held so many community meetings. And every user had the opportunity to ask questions or criticize the team for publicity... however. At the last meeting, there were only 7 previously collected questions. And the number of participants was not very large. I wonder if all you guys have so many questions, why you don't take a part in such meetings?

Max needs to be a little more transparent
What exactly do you mean? What points are non transparent? What information do you miss?

the meetings have thinned out because the community has seen a consistent pattern over several months, and has naturally and understandably become a little disillusioned with all things Lisk. the community put its faith in Max expecting the funds to be invested to grow the project.

transparency - why did he zero in on a ggmbh? as i understand it no blockchain project based in Deutschland has ever tried to go that way. the 'natural' way is the Swiss way. i don't see what the reasoning was for trying for a ggmbh over a Swiss foundation, and he hasn't come out and explained that. he's swerved around the subject.

[bitseedmike]

The gGmbh would have been a major win for crypto in general in the EU, and Max said earlier when I asked in a community meeting that the information on how to set them up would be open sourced. I agree that it should not have been allowed to impact development or schedule, but it was a goal worth pursuing in its own right.

[GinnaGinna]

Guys dont invest your precious Lisk in Ark.io ICO !

Smells like a huge scam to me.

[tomkat]

Dev Team - Go Forward Plan
As you all probably have assumed, we have encountered numerous issues with the delegate system, and the security of the rise-core code base. A couple of highlights:

• Slow system speed - 10> Transactions per second - Above this causes forks
• DDoS Vulnerabilities in multiple core system packages that require significant updates to resolve
• Spotty delegate communication
• High resource usage for nodes

The above issues are difficult to resolve in the current code base (As evidenced by the original developers lack of resolution up until this point).

In order to find a solution for this, we are going back to the drawing board, and designing an entirely new architecture for the system, not based on anything that is currently in existence. We will be writing a new codebase from scratch.

The Architecture process is going to take a bit of time, but we will make sure that we post regular updates to where we are at, and we will keep all of our architecture and configuration documentation in a github project tracker so you can all track our progress yourselves. The address is RiseVisionProject. You’ll start seeing significant updates to this project by the end of this week.

The objectives remain the same, building a stable, scalable cryptocurrency, with customizable side chains, Distributed applications, and Smart Contracts. We will still have a hosting platform that can be installed on any publicly accessible server, and we will still be maintaining API compatibility with the current SDKs.

Once the new code is complete, we will initiate a straight swap of coins from one chain to the other. The mechanism for this is not yet decided on, but we will attempt to make it as seamless as possible.

Thank you all for your continued support, we will keep you updated on progress on a regular basis, starting with a Whitepaper coming very soon…

The above was posted in RISE thread, but since they've been copying Lisk code, I guess the same issues are present in Lisk.
Now, are they crazy to create a new code from scratch, OR they're not skilled enough to make it work without Lisk team, OR Lisk code is indeed so bad ?

[Poly#Crypto]

The above was posted in RISE thread, but since they've been copying Lisk code, I guess the same issues are present in Lisk.
Now, are they crazy to create a new code from scratch, OR they're not skilled enough to make it work without Lisk team, OR Lisk code is indeed so bad ?

I know nothing about the Rise Code. But I can tell you the Lisk development since the beginning has made a great step.
And the first priority is stability and security.

All changes made to the Lisk core:

Build
- Fixed address in use errors on restart.
- PostgreSQL is now included with the “Binary” install, removing the need to install it separately. A simple bash lisk.sh coldstart will initialise the database on first start.
- Running lisk.sh as root is now prevented by default.
- Added lisk.sh reload command. @Isabello
- Fixed #6. lisk.sh restart now cycles both Node.js and Postgresql. @Isabello
- Fixed #10. lisk.sh start/stop/restart now work more reliably. @Isabello
- New simpler binary installation, thanks to liskInstall.sh. @Isabello
- Added tune.sh for optimizing the default postgresql.conf. @Isabello
- Preliminary support for checksummed archives. @Isabello
- Fixed #76. Updating node/lisk-node to 0.12.14.
- installLisk.sh - added mainnet vs testnet installation.
- installLisk.sh - laying framework for upgrade support.
- tune.sh - corrected bsd memory allocation.
- Updating node/lisk-node to 0.12.15.
- Closed #44. Added timestamp to postgresql logs.
- Added empty blockchain.db.gz to allow for starting the blockchain from 0.
- Updating node/lisk-node to 0.12.16.

lisk.sh
- Closed #31. Added -s flag to support new snapshot feature.
- Closed #31. Added -c flag to specify config.json at runtime.
- Closed #21. Adding prereq checks, correct md5 checks for bsd/darwin.
- Implemented standard location for PID and log
- Reducing ram usage on machines with less than 1024Mb
- Made further reliability improvements to process
- Fixing postgresql locale / character encoding issues.
- Adjusted log naming based on DB instance Lisk is using.
- Determining whether Lisk is running based on PID and config.json input.
- Implemented new cases for independent management of Nodejs and PostgreSQL.
- Implemented url flag for lisk.sh to allow remote snapshots to be used with rebuild.
- Updated rebuild logic to allow for local backups to be reused and to specify file name.
- Improved lisk startup to display current block height after start or status is issued.
- Implemented new logic for interactive snapshotting.
- Added progress bar when downloading snapshots.

installLisk.sh
- Added flag options for batch and silent install @34ro.
- Reducing ram usage on machines with less than 1024Mb RAM.
- Made further reliability improvements to process
- Fixing postgresql locale / character encoding issues.
- Removed duplicated block height check already present in lisk.sh.
- Changed coldstart to use empty blockchain.db.gz.

lisk_snapshot.sh
- Implemented lisk_snapshot.sh for automated database backups.
- Added snapshot.json for configuring lisk_snapshot.sh backups.

Front end
- Complete rebranding of the client UI.
- Complete clean-up of the old code base.
- Added translations for 14 languages (Chinese, Russian, German, Dutch, Greek, Spanish, French, Hungarian, Italian, Japanese, Norwegian, Portuguese, Romanian, Ukrainian).
- Enforced BIP39 passphrases.
- Enforced BIP39 second passphrases.
- Unified every modal.
- Improved Dapp registration and Multi-signature registration modals.
- Added fees overview to every modal.
- Added more descriptions to every modal.
- Removed usernames and contacts (to be later reimplemented as a separate Identity Dapp sidechain).
- Fixed several browser specific UI bugs and inconsistencies.
- Improved and unified the overall user interface.
- Fixed #30. Voting now possible after enabling 2nd passphrase @pilldriver.
- Fixed #29. Resetting application state between sessions @2mdoty.
- Fixed #13. Improved error handling when sending transactions @karek314.
- New and improved Russian translation @densmirnov.
- Refactored delegate username validations.
- Fixed non-functioning delegate registration. @2mdoty
- Fixed #34. Dapp registration when 2nd passphrase enabled.
- Fixed #43. Language switcher now works for all languages. @senikk
- Complete change of terminology from dapps to blockchain applications.
- Implemented feeService. Fetching transactions fees for each transaction type.
- Adding security warning before opening apps.
- Closed #9. Disabling buttons on first click. Adding success/error toasts.
- Closed #14. Explaining master passphrase.
- Closed #17. Fixing Safari font-weight / aliasing.
- Fixed #31. Updating bitcore-mnemonic @mrv777.
- Fixed #38. Including total count of delegates.
- Fixed Lisk address validations.
- Closed #47. Replacing zeroclipboard with clipboard.js.
- Closed #50. Fixed Invalid Lisk amount error when sending fractional amount.
- Closed #57. Updating bitcore-mnemonic to version 1.0.1.
- Closed #59. Checking for zero amount after building parts.
- Closed #67. Removing prefixes from orderBy parameters.
- Fixed broken sync status indicator.
- Updated translations.
- Added Polish language support.
- Fixating and updating dependency versions.
- Fixing calls to null u_multisignatures/multisignatures.
- Fixing call to undefined resp.data.account.

Back end
- Complete clean-up of the old code base.
- Implemented Forging Rewards with an offset (first week no rewards).
- Changed the transaction fee to a constant 0.1 LISK.
- Revised error and logs messages throughout all backend modules.
- Change of address format (addresses now end with an L).
- Allowing dapps installation from GitHub using https.
- Fixed #13. Checking for presence of recipientId @fix.
- SSL: Using the default cipher from recent nodejs version to protect against weak RC4 cipher @TheGoldenEye.
- Fixed unrecoverable fork when comparing delegate id to generator id.
- Fixed #45. Improved sync / block insertion rate.
- Fixed #3. Setting X-Frame-Options/CSP headers @fix.
- Improved logging of received unconfirmed transactions.
- Improved logging of blocks loading from peer.
- Imposing hard limit on number of transactions per block.
- Changed database engine from SQLite to [PostgreSQL](http://www.postgresql.org/). Providing faster query performance, better support for concurrency, and further options for scalability.
- Removed usernames and contacts from mainchain (to be later reimplemented as a separate Identity Dapp sidechain). Delegate usernames still remain.
- Added dapp zip link storage mechanism, replaces GitHub and Sia integration, with alternative decentralized solutions to be implemented in future releases.
- Implemented concatenated inserts/updates, dramatically reducing number of round trips between client and database: https://github.com/vitaly-t/pg-promise/ ... ance-Boost
- Implemented promise based database logic using: https://github.com/vitaly-t/pg-promise
- Added optional PostgreSQL event monitoring using: https://github.com/vitaly-t/pg-monitor (see: config.json:db.logEvents). This will be used for finding further efficiency improvements at the database level.
- Enabled gzip compression on all http requests using: https://github.com/expressjs/compression. Significantly reducing the size of payloads transmitted between peers on the network, and also for lisk-ui (Example: vendor_app.js : Without compression 5.4MB, With compression: 1.2MB).
- Improved syncing reliability and chain comparison efficiency between peers, through query and code refactoring of Blocks#getIdSequence and the /peer/blocks/common API endpoint.
- Accounts#getDelegate(s): Calculating approval rating from total supply rather than a static amount.
- Increased max transactions per block from 10 to 25 (subject to further change after more testing and efficiency improvements have been made).
- Changed peers communication format from CSV to JSON.
- Fixed DApps#getInstalledIds, filtering installed ids to only include numerically named folders.
- Fixed “Dapp not ready” messages when auto-launching dapps upon starting client.
- Closed #24. Changing ‘sync’ to ‘syncing’. @HeisenbergCoin
- Closed #33. Logging each client request. @slasheks
- Fixed #36. Adding username and publicKey properties. @fix
- Fixed #47. Changing timestamps to UTC. @TheGoldenEye
- Fixed #50. Indicating forged blocks more clearly. @punkrock
- Fixed #52. Removing virgin field from mem_accounts. @simonmorgenthaler
- Fixed #54. Restricting total number of votes to 101. @TheGoldenEye
- Fixed #55. Fixing circular reference.
- Updated all 3rd party node modules to latest compatible versions.
- Switched from zip to gzipped tar for release packaging.
- Generated new genesis block for use on open testnet.
- Closed #69. Loading schema using external SQL file @vitaly-t.
- Closed #84. Allowing the setup of logging path in config.json @TheGoldenEye.
- Fixed #77. Peers API endpoint now works when filtered by state @slasheks.
- Fixed all known casting issues caused by db migration.
- Fixed ‘Recipient not found’ error on virgin accounts.
- Improved error logging/comments on fork causes.
- Added proper delegate username validations.
- Fixed test coverage of delegates API.
- Nearly Completed work towards #82, fork cause 3: @karmacoma
— Heavy refactoring of Round#tick, Round#backwardTick.
— Memory table updates are now wrapped within db transactions.
— Added checks for missed/unapplied mem_rounds on startup.
— Dropping mem_rounds table on reload if not in a valid state.
— Skipping delegate slot when round is ticking.
— Don’t receive block when round is ticking.
- Completed work towards #82, fork cause 3: @karmacoma
— Removing use of setImmediate in round ticks.
— Scoping each invocation of RoundPromiser.
— Iterating over delegates asynchronously.
— Getting outsiders only at end of round.
— Fixing finishRound logic.
- Fixed pending transactions API endpoint. @fix
- Fixed #8. Delegate usernames must now be lowercase. @fix
- Fixed #40. API payloads are now limited to 2Mb per request. @fix
- Fixed ip address detection when using proxy. @Isabello
- Fixed #122. Corrected schema errors in dapp transfers. @TheGoldenEye
- Fixed #101, #107 productivity calculations. @mrv777
- Fixed #90. Translating ips from long. @cezarsn
- Fixed #131. Added nethash p2p verification. @fix
- Fixed #22. Cannot read property ‘senderPublicKey’ of undefined. @fix
- Fixed forced blocks verification on startup, i.e: config.json-loading-verifyOnLoading.
- Closed #126. Using recommended pg-promise approach. @vitaly-t
- Updated transaction fees. 25 LSK for Delegate and Dapp registrations.
- Change of blockchain application categories
- Moved large queries into postgresql views
- Extracted SQL logic into separate modules
- Closed #134 Adding GET /api/blocks/getFees endpoint.
- Closed #137 Adding GET /api/blocks/getNethash endpoint.
- Standardised and fixed up test-suite.
- Fixed Lisk address validations.
- Fixing /apt/blocks/get?id= endpoint.
- Improved peers connectivity / preventing network partitioning.
- Improved logging when rebuilding chain.
- Set default loadPerIteration to 1000.
- Temporary extension of reward offset.
- Reverted forging timeout feature which was causing network to pause.
- Closed #110. Fixed fatal error when tmp directory does not exist. @m-schmoock.
- Closed #119. Added snapshot functionality.
- Closed #140. Adjusting levels for various log messages @tharude.
- Closed #160. Preventing / gracefully handling 101 votes exceeded errors @karek314.
- Closed #161. Improving consistency of GET /api/delegates?orderBy= results @ByronP.
- Closed #166. Standardising GET /api/transactions?orderBy= field prefixing @ByronP.
- Closed #171. Snipping secrets from logs @cezarsn.
- Closed #191. Configuring CORS with pre-flight.
- Closed #192. Normalising address casing, upon setting and merging of accounts.
- Closed #198. Added GET /api/delegates/search endpoint.
- Closed #201. Improving/log order and format @m-schmoock.
- Closed #203. Allowing local forging via config switch @m-schmoock.
- Closed #208. Fixed fatal error when trying to install a broken dapp link @m-schmoock.
- Closed #233. Improving efficiency of GET /api/accounts/top endpoint.
- Closed #237. Fixed PUT /api/multisignatures endpoint, including test coverage @mongrim.
- Closed #238. Fixed transaction broadcast reliability. Added unconfirmed transaction expiry @Crypto2.
- Merge #187. Fixed SQL errors in DappsSql module @TheGoldenEye.
- Merge #189. Added whiteList / blackList extension allowing cidr subnets @TheGoldenEye.
- Merge #226. Using local mocha dependency for tests @mfressdorf.
- Merge #199. Do not leave loop early, if ip was not found yet @TheGoldenEye.
- Fixed DApp#getWithdrawalLastTransaction error.
- Fixed invalid results yielded by GET /api/delegates/count endpoint.
- Refactored orderBy parameter parsing for all endpoints.
- Improved efficiency. Performing upsert when merging accounts.
- Fixed intermittent unnecessary rebuild of memory tables.
- Fixed inconsistent multisignature maximum lifetime (72 hours).
- Implemented chronological database migration system.
- Backported inTransfer / outTransfer module fixes. Resolves critical issue when saving outTransfer (type 7) transactions, used to initiate LSK transfers between a sidechain and the mainchain. The supporting test-suite has been improved to ensure this basic functionality is maintained between releases.
- Backporting transaction signature malleability fix. Replacing ed25519 implementation with js-nacl version 1.2.1, a high level API to libsodium.
- Closed #197. Improving error messages when account does not have enough funds. Yielding sender address and account balance.
- Closed #266. Changed behavior of POST /api/accounts/open and POST /api/accounts/generatePublicKey. New accounts are no longer written to mem_accounts. Added one-time migration to delete dormant accounts which have never received or sent funds.
- Closed #266. Verifying public key type, length and format in Account.prototype.set and Account.prototype.merge.
- Closed #266. Added virgin column to mem_accounts. Indicating whether an unconfirmed transaction sent from an account has been applied.
- Closed #266. Added protect_mem_account database trigger. Making address, u_username, username, virgin, publicKey, and secondPublicKey columns immutable once written.
- Closed #266. Added senderPublicKey exceptions to Transaction.prototype.verify.
- Added missing address validation to GET /accounts?address=.
- Fixed error on GET /api/delegates?orderBy=unknown:asc.
- Fixed error on GET /api/delegates?limit=0.
- Closed #163. Adding default orderBy to /api/blocks (height:desc).
- Merged #210. Block processing rewrite @fix.
- Preventing data corruption of memory tables after reload or shutdown #213.
- Closed #222. Fixing block reward calculation within first few blocks after milestone.
- Closed #258. Detecting numericality of snapshot round. Allowing node app.js —snapshot=foobar to default to the highest round.
- Closed #260. Removing infinite recursion in Loader.prototype.getNetwork.
- Closed #276. Finishing snapshot within __private.applyBlock.
- Closed #289. Prevent sync slowdown after receiving unconfirmed transactions.
- Conditionally loading blocks from network; when there has been no block “receipts” over network transport, or when last receipt was over 120 seconds ago.
- Added GET /api/loader/status/ping endpoint @34ro.
- Added GET /api/blocks/getEpoch endpoint.
- Added nethash and epoch properties to GET /api/blocks/getStatus.
- Fixed orphan account check. Excluding mem_accounts with NULL blockId.
- Fixed invalid type comparison on unapplied rounds.
- Fixed reported block height when rebuilding blockchain.
- Improved error logging with JSON dump of affected block.
- Closed #265. Fixing “Account not found” error when sending transactions to virgin account using POST /api/transactions.
- Fixed #279. Removing erroneous unconfirmed transactions.
- Fixed #279. Removing redundant double spend collection.
- Fixed undefined is not a function error. After error thrown while verifying transaction bytes.
- Added verification of transaction assets for all transaction types.
- Improved error logging with JSON dump of affected transaction.
- Improved logging of apply / undo of transactions at debug level.
- Performing sender balance checks using bignum arithmetic.
- Closed #269. Fixed crash on 404 error for POST /api/dapps/install.
- Downgraded npm to latest LTS release 2.15.10.
- Improving peers db efficiency #104. Sequencing peers updates.
- Improving peers db efficiency #104. Replacing insert / update with single upsert.
- Improving peers db efficiency #104. Chaining database queries when adding dapp peer.
- Closed #147. Replacing request with popsicle. Fixing memory leak on large request bodies, e.g. loading blocks from peer.
- Merged #227. Improved peer discovery using histogram cut selection of “good” peers @fix.
- Closed #231. Implementing API rate limiter. Individually configurable for both /api and /peer. Disabled by default.
- Added EHEADERS, ERESPONSE, ENETHASH peer error codes, extending: https://github.com/blakeembrey/popsicle#error-handling.
- Fixed timers in Loader.prototype.onPeerReady.
- Only trigger nextLoadBlock if loaded and not already syncing.
- Fixed halt to nextLoadUnconfirmedTransactions recursion when syncing.
- Fixed halt to nextLoadSignatures recursion when syncing.
- Checking nethash for all transport /peer requests.
- Returning JSON response for POST /peer/blocks.
- Returning success or error for GET /api/peers/get.
- Added success property to GET /peer/transactions.
- Ignoring already processed or confirmed transactions for POST /peer/transactions.
- Added transactionId property to POST /peer/transactions.
- Added success property to GET /peer/height.
- Removing peers which return bad response code.
- Removing peers with invalid request headers.
- Removing peers with invalid nethash.
- Improved logging of peer changes at debug level.
- Increased default peer timeout to 5000 ms.
- Fixed unwanted rejection of seed peers due to lack of os, version metadata.
- Removed unnecessary peer loopback detection.
- Validating peer headers using zschema only.
- Closed #147. Dramatically improved CPU and memory efficiency.
- Moved schema validations into separate modules, to eliminate unnecessary continous object creation.
- Added unique ids to schema validations, to better utilize z-schema schema caching.
- Nullifying any large objects identified by memory profiling at the earliest opportunity.
- Decoupled transaction types from modules into separately addressed modules.
- Defining functions on constructor prototype where possible.
- Using async for control flow, to remove deep nesting of code.
- Fully linted code base using jshint to a strict standard.
- Created database indexes on memory tables.
- Complete rewrite and abstraction of API tests, for cleaner tests.
- Massively expanded API test coverage, resulting in many fixes.
- Added initial unit test coverage, e.g. for block rewards.
- Removed unimplemented serveHttpAPI/Wallet options from config.json.
- Added maxUpdatePeers option to config.json.
- Added trustProxy setting to config.json.
- Updated all dependencies to latest compatible versions.
- Replaced underscore, util-extend with lodash.

[karmacoma24]

Thanks Poly#Crypto for the extensive breakdown. Much appreciated.

In the end, this is all a question of who is willing to do the hard work needed to get a job done. I would say despite our imperfections, Lisk is, and will continue to be the leading light in this regard.

Since the beginning of this year, the code base has been constantly and iteratively improved, to the point where we are now approaching the required stability in order to enable community forging.

To give a brief overview:

The numerous modules and logic that form the Lisk core have been (or are being) gradually refactored, or rewritten.

The various fork causes 1, 2 and 3, which have been holding back community forging are very close to being largely mitigated.

The peer to peer transport layer has been drastically improved, and I would argue in the forthcoming 0.5.0/0.6.0 releases, vastly more efficient than before.

The newly implemented "broadhash" implementation should guarantee much better block and unconfirmed transaction propagation throughout the network.

The test suite which guarantees stability, and prevents regressions between releases has been rewritten and gradually expanded.

This is all part and parcel of software development. In the end, we end up with a more efficient and stable product.

Getting to this point has required a lot of hard work and perseverance.

This hard work is not for the weak of heart, or mind.

Thank you.

[norsklaks]

big pump due to ark ico?     Lisk deserves to be lower than ico, because it is too expensive. Ark saved you

[ApexEvo]

big pump due to ark ico?     Lisk deserves to be lower than ico, because it is too expensive. Ark saved you

you deserve to not own LISK and being complete loser sobbing on moral bottom that is FUDders cave.