Topic: [ANN][LISK] Lisk | ICO | Dezentrale Anwendungen & Sidechain Plattform - page 65. (Read 113732 times)

Stimmt, das fällt einem kurz vor dem ursprünglich angekündigten Launch ein - Ende April/Anfang Mai.

Ach ja, war der eigentliche Grund nicht, dass alle Passwörter noch nicht validiert seien? Mit dieser Begründung wurde ja der Erste Launch ( 11. April ) verschoben.
Als ob alle ihre Passwörter bis zum 24.05. validieren werden...

Ohne steigenden BTC Kurs wäre mir der Starttermin von lisk schnuppe. von mir aus nächstes Jahr.

Ich persönlich finde es nicht so schlimm wenn sich der Launch um einen weiteren Monat verzögert. Was ich aber seltsam finde: Wieso engagiert man einen Communitymanager aber keine(n) zusätzlichen Coder? Hat das Geld dazu nicht gereicht? 

Viele Probleme sind bei Crypti einfach nicht aufgefallen, weil es viel weniger genutzt wurde. Schaut Dir mal die offenen Probleme auf github an:
https://github.com/LiskHQ/lisk/issues
Ganz fertig war Crypti wohl doch noch nicht.

Handelt es sich hierbei nicht um einen Crypti Klon? Inwiefern hätte es  technische Probleme geben können? Auf SQLite alleine kann man die Argumentation schlecht stützen meiner Meinung nach.

Handelt es sich hierbei nicht um einen Crypti Klon? Inwiefern hätte es  technische Probleme geben können? Auf SQLite alleine kann man die Argumentation schlecht stützen meiner Meinung nach.

Max und Oliver sind erfahrene Leute.

Soon after we announced the scheduled release date and pre-launch development plan, someone stress tested our network and it collapsed. A few hours later Oliver released a fix which sets the transaction maximum per block to 10. It fixed the stress test related problems and made the network stable again, however it became crystal clear that we need to optimise Lisk before launch. The code was not durable enough yet to withstand the enormous popularity of Lisk. Therefore, Oliver completely switched the Lisk blockchain database layer from SQLite to PostgreSQL. Additionally, he implemented many speed optimisations and restructured big parts of the block synchronisation code.

The results are fantastic; the client is much faster and more responsive. All concurrency problem we had, when many users were using the same node (e.g. login.lisk.io) are resolved. Additionally, the network backbone is far more robust and scalable. The update will be available next week in order to properly test it, a testnet reset is necessary.

Unfortunately, the database switch pushed us back for 9 days and further tests of the changes will require a total of one week. On GitHub we also received more issues in the past weeks which need to be fixed before launch.

Therefore, coming back to the release date. In order to have a successful launch Lisk needs to “simply work”. We decided for quite a generous release date. Which gives us more than enough time to properly test the new release, finish the pre-launch development plan, and work on the GitHub issues.

Habe ich was verpasst?
Quelle?

Sollte der Release nicht Ende des Monats sein?

Du sagst es. Den Wechsel von Lisk zu Waves können sie verhindern indem sie den Start auf Juni verschieben.

Was sie nicht verhindern können, ist die Panik vor dem kommenden Halving. Mindestens 75% aller lisk werden gnadenlos in BTC umgetauscht.

 Ich persönlich finde es schade, dass der Start, angesichts der Anspannung auf den Märkten, erneut verschoben wird. Unterstellen möchte ich ja nichts, aber so spät noch die DB ändern um den Start zu verschieben ?
Wenn BTC Ende Mai bei über 500$ ist, wird es massig Panic sells geben.

das was mein vorposter schrieb, ist nicht ernst gemeint. nicht das das jetzt jemand auf die goldwaage legt.

leider ist der knaller kein knaller, das datum wurde weit nach hinten verschoben, das sieht unschön aus. dann wird das kapital in IOTA fließen und in wave. daher wärs besser, gleich noch 2 wochen drauf zu packen und LISK anfang juni erst zu veröffentlichen (damit fällt schomal das risiko raus, das die leute schnell LISK abverkaufen und in wave ihr geld rein pumpen).