Hot Coins

[ImI]

...meines Wissens ist Boris nicht mehr zu 100% an Bord.

Woher beziehst Du denn dein Wissen?

Es wäre sicher für alle User interessant, wenn solche Behauptungen auch belegt würden.

Meine Quellen für Lisk sind hauptsächlich der offizielle Thread hier auf BTT und die Berichte vom Altcoinspekulant, also nix exklusives, sondern leicht selbst zu finden.

[1714168871]

1714168871

[1714168871]

1714168871

[1714168871]

1714168871

[thandie]

...meines Wissens ist Boris nicht mehr zu 100% an Bord.

Woher beziehst Du denn dein Wissen?

Es wäre sicher für alle User interessant, wenn solche Behauptungen auch belegt würden.

Meine Quellen für Lisk sind hauptsächlich der offizielle Thread hier auf BTT und die Berichte vom Altcoinspekulant, also nix exklusives, sondern leicht selbst zu finden.

Und wo steht auf Altcoinspekulant und BTT geschrieben, daß Boris nicht mehr zu 100% hinter dem Projekt steht?

[schnötzel]

The ELC giveaway ends when Bitcoin block 425920 has passed

Hui, das dauert aber noch eine Weile 

Mit "Giveaway" meinst du IPO, oder? Auf der Website steht zwar  "giving away ", kann aber von einem "Giveaway" im herkömmlichen Sinne nichts entdecken.

[ImI]

...meines Wissens ist Boris nicht mehr zu 100% an Bord.

Woher beziehst Du denn dein Wissen?

Es wäre sicher für alle User interessant, wenn solche Behauptungen auch belegt würden.

Meine Quellen für Lisk sind hauptsächlich der offizielle Thread hier auf BTT und die Berichte vom Altcoinspekulant, also nix exklusives, sondern leicht selbst zu finden.

Und wo steht auf Altcoinspekulant und BTT geschrieben, daß Boris nicht mehr zu 100% hinter dem Projekt steht?

Sorry, aber ich such doch jetzt nicht selbst wieder alles durch, ich hab ja ausdrücklich geschrieben "meines Wissens".

Falls du etwas gegenteiliges erfährst nur zu, Lisk könnte dringend ein gutes Dutzend Developer gebrauchen bei dem durchaus ambitionierten Projekt.

[allyouracid]

Ist jemand bei VOXELS (https://bitcointalk.org/index.php?topic=1235683.240) oder Elastic Project (https://bitcointalk.org/index.php?topic=1396233.0) dabei?

Ich bin bei Elastic dabei. Wobei das ein hohes Risiko ist m.E.

Chance/Risiko-Verhältnis bei einer max Marketcap von 250.000$ jedoch extrem gut. Kein Vergleich mit aufgeblähten Projekten wie Lisk welche nun mit einer Marketcap von 6 Mio$ starten.

dieses verteilte rechnen kann doch gridcoin schon lange... was hindert Gridcoin den ihre rechenpower neben der verwendung für wissenschaftliche projekte auch zu verkaufen  .... genau das was elastic machen will. nur die haben schon Jahre Vorsprung.... oder verstehe ich da was falsch?

Also Gridcoin ist etwas völlig anderes, wenn man es technisch betrachtet.

Ich bin mal so frei und zitiere deren Webseite:

Gridcoin was the first block chain protocol that delivered a working algorithm that equally rewards and cryptographically proves solving BOINC (Berkely Open Infrastructure for Network Computing) hosted work, which can be virtually any kind of distributed computing process (ASIC/GPU/CPU/Sensor/Etc).

Quelle: http://www.gridcoin.us, Zugriff am 8. April 2016 um 22:19

Bei Gridcoin geht es darum, dass ihr Arbeit in ein auf BOINC gehortetes project investiert. Basierend darauf gibt euch regelmäßig jemand einen gewissen Anteil GridCoins. Nicht nur ist die Verteilung der Gridcoins abhängig von einer zentralen Entität, sondern die "Work Packages" an sich sind zentral gehostet.

Das kann man so machen, und es lässt sich sehr leicht verifizieren dass die Leute, welche bei BOINC contrbuted haben, auch sinnvolle Arbeit geleistet haben. Bei Elastic wird es um einiges komplexer: Wir wollen keine zentrale Autorität, keine zentral gehosteten Aufgaben und niemanden der bevollmächtigt ist irgendwelche Coins zu verteilen.

Die Vision ist alles dezentral und algorithmisch zu lösen. Es ist nicht trivial und alles andere als schnell implementiert. Ein großes Problem ist in der Tat die Verifikation, dass die Teilnehmer sinnvolle Arbeit geleistet haben, und zwar so dass nicht alle Teilnehmer des Netzwerks die selbe Berechnung zur Verifikation durchführen müssen. Eine Verifikation muss immer schneller als der Task an sich sein. Homomorphe Verschlüsselung und Verifiable Computation seien jetzt mal zwei Stichworte.
Zugegeben, ein starker BOINC Server kann solche Verifikationen sicherlich problemlos durchführen, aber das soll nicht der Sinn der Sache sein.

Ein weiterer Punkt ist die "Faster Algorithm Attack" bei dem jemand eine Aufgabe ins Netzwerk postet für die er aber einen äquivalenten, schnelleren Algorithmus kennt. Aus diesem Grund ist Elastic auch ein Hybride aus POS (zur Sicherung der Blockchain) und POW (zur Erledigung der Arbeit). Andernfalls würde die Faster Algorithm Attacke eine sehr einfache 51% Attacke ermöglichen, da ein böswilliger Angreifer mit einfachsten Bordmitteln die Mehrheit der Blocks (durch Lösen seiner eigenen Aufgabe) finden könnte.

Es ist schwierig in der kurzen Zeit jetzt all zu tief in die Details zu gehen, aber Elastic (bzw. das Konzept dahinter) hat es so noch nicht gegeben. Klar, es ist riskant da einige Fragen noch offen sind, aber aus wissenschaftlicher Perspektive ist es eine bisher nie dagewesene Innovation.  

Holy…

…das, was Du da gerade geschrieben hast, hat mich aus den Socken gehauen. DAS hört sich mal richtig interessant an. Vor allem die fett markierten Teile.
Gibt es schon ein Whitepaper o.Ä.? Würde mich da nur all zu gerne näher reinlesen, und eine Idee bekommen, wie die Verifizierung gelöst wird.

[thandie]

Sorry, aber ich such doch jetzt nicht selbst wieder alles durch, ich hab ja ausdrücklich geschrieben "meines Wissens".

Falls du etwas gegenteiliges erfährst nur zu, Lisk könnte dringend ein gutes Dutzend Developer gebrauchen bei dem durchaus ambitionierten Projekt.

Ist doch albern. Entweder weiß man davon oder nicht.

Und ich bin überzeugt: wenn Lisk Devs benötigt, werden sie die auch bekommen. Aber könnte dringend benötigen finde ich vollkommen übertrieben, nach der kurzen Zeit.

Wir sprechen/schreiben uns in sechs Monaten wieder...

[ImI]

Ist doch albern. Entweder weiß man davon oder nicht.

Nochmals, ich such doch nicht alle Threads bei Reddit und BTT durch um dir einen Beleg zu präsentieren für etwas was ich sowieso schon weiß.

Devs werden dringend benötigt, bei dem ganzen Hype sollte man auch liefern, zumindest Stückweise, ansonsten fällt das schnell in sich zusammen. Geld müsste jetzt ja genug vorhanden sein.

[thandie]

Ist doch albern. Entweder weiß man davon oder nicht.

Nochmals, ich such doch nicht alle Threads bei Reddit und BTT durch um dir einen Beleg zu präsentieren für etwas was ich sowieso schon weiß.

Nochmal: Wenn ich hier schreiben würde, daß Buterin Ethereum verlässt, wüden auch alle User nach einer entsprechenden Informationsquelle fragen, wenn ich der einzigste User mit diesem vermeintlichen Wissen wäre.

Ich frage mal bei bei Max und Oliver nach.

[Evil-Knievel]

…das, was Du da gerade geschrieben hast, hat mich aus den Socken gehauen. DAS hört sich mal richtig interessant an. Vor allem die fett markierten Teile.
Gibt es schon ein Whitepaper o.Ä.? Würde mich da nur all zu gerne näher reinlesen, und eine Idee bekommen, wie die Verifizierung gelöst wird.

Es gibt eine Vage idee und ein Whitepaper was unsere erste Idee in ihren Grundzügen beschreibt.
Natürlich muss das Whitepaper viel detaillierter werden und den Ansatz ausführlich Evaluieren, aber zunächst gilt herauszufinden ob der Ansatz überhaupt etwas taugt.

https://github.com/elastic-project/whitepaper/raw/master/whitepaper.pdf

Die Idee ist quasi einen "State-Buffer" mitzuführen, welcher "während der Ausführung eines Programms" mit einer konstanten Rate gefüllt wird. Da SHA256 selber einen Stream aufnehmen kann, kann dieser Buffer quasi direkt in die SHA256 gepipt werden. Ist der Buffer "voll" so wird der resultierende Hash mit einem Targetwert verglichen: erfüllt er gewisse Kriterien z.B. eine gewisse Difficulty so gilt der "Beweis" als akzeptiert.
Das korrekte füllen des Buffers entspricht quasi dem korrekten Ausführen des Programms. Nachdem der Buffer voll ist und die Checks abgeschlossen sind, fängt alles wieder von vorne an; natürlich während das Programm weiter läuft. (ich glaube diese Programmabschlitte zwischen zwei Buffe-Full Events werden im Paper als 10ms Blocks bezeichnet, weil im Raum stand dass die Zeit zwischen zwei vollen Buffern eben 10ms betragen sollte).

Die Verifikation läuft analog dazu: Da der Buffer deterministisch gefüllt wird kann man genau sagen an welcher Stelle des Programms ein Buffer voll geworden ist, geleert wurde und mit der Füllung neu begonnen wurde. Alles was man zur Verifikation braucht ist die Grenze (z.B. als Index des x-ten Buffervorgangs) und den resultierenden Hashwert. So kann man nur durch das Ausführen isolierter kleiner "Teilbereiche" des Programms "stochastisch einigermaßen zuverlässige Verifikationen" erreichen.

Das was jetzt mal ganz vereinfacht erklärt; es gibt noch einige andere fancy countermeasures gegen einige triviale Angriffe ... im Paper steht es detaillierter.
Ich glaube es gibt noch einige Probleme: Was wenn jemand einen Teil des Programms identifiziert, für den er den Buffer schneller "vorhersagen" kann als wenn er den Teil des Programms ausführen müsste (hier wieder die Klassische Faster Algorithm Attacke). Somit könnte er diese "Proofs" signifikant schneller generieren als andere Miner, welche den Programmteil wirklich aufrichtig rechnen.

Die Faster Algorithm Attack ist allgegenwärtig und raubt uns den letzten Nerv ;-)

Wir sind uns ins der Community noch nicht einig ob es nur eine Form von DOS (man kann nur seine eigenen Aufgaben lösen und so sein eigenes Geld von sich selbst verdienen) ist oder ob es wirklich problematisch sein könnte (wenn man von anderen Geld verdient ohne sinnvoll zu arbeiten).

Es ist wirklich sehr schwierig, aber aus der Sicht der Informatik höchst interessant. Schade nur, dass wirklich Interessante Projekte oft nur im Schatten der Ganz-und-Glamor Coins stehen, die das Rad zum x-ten Mal neuerfinden.

[ImI]

Ist doch albern. Entweder weiß man davon oder nicht.

Nochmals, ich such doch nicht alle Threads bei Reddit und BTT durch um dir einen Beleg zu präsentieren für etwas was ich sowieso schon weiß.

Nochmal: Wenn ich hier schreiben würde, daß Buterin Ethereum verlässt, wüden auch alle User nach einer entsprechenden Informationsquelle fragen, wenn ich der einzigste User mit diesem vermeintlichen Wissen wäre.

Ich frage mal bei bei Max und Oliver nach.

Gerade hierüber gestolpert:

https://blog.lisk.io/boris-povod-joins-lisk-as-our-first-adviser-8e2c3d54b03d#.jrtiaembe

Please note that as an adviser he won’t serve as a member of the Lisk core team, but rather as a consultant from time to time.

Adviser, kein Mitglied des Teams.

[Limx Dev]

…das, was Du da gerade geschrieben hast, hat mich aus den Socken gehauen. DAS hört sich mal richtig interessant an. Vor allem die fett markierten Teile.
Gibt es schon ein Whitepaper o.Ä.? Würde mich da nur all zu gerne näher reinlesen, und eine Idee bekommen, wie die Verifizierung gelöst wird.

Es gibt eine Vage idee und ein Whitepaper was unsere erste Idee in ihren Grundzügen beschreibt.
Natürlich muss das Whitepaper viel detaillierter werden und den Ansatz ausführlich Evaluieren, aber zunächst gilt herauszufinden ob der Ansatz überhaupt etwas taugt.

https://github.com/elastic-project/whitepaper/raw/master/whitepaper.pdf

Die Idee ist quasi einen "State-Buffer" mitzuführen, welcher "während der Ausführung eines Programms" mit einer konstanten Rate gefüllt wird. Da SHA256 selber einen Stream aufnehmen kann, kann dieser Buffer quasi direkt in die SHA256 gepipt werden. Ist der Buffer "voll" so wird der resultierende Hash mit einem Targetwert verglichen: erfüllt er gewisse Kriterien z.B. eine gewisse Difficulty so gilt der "Beweis" als akzeptiert.
Das korrekte füllen des Buffers entspricht quasi dem korrekten Ausführen des Programms. Nachdem der Buffer voll ist und die Checks abgeschlossen sind, fängt alles wieder von vorne an; natürlich während das Programm weiter läuft. (ich glaube diese Programmabschlitte zwischen zwei Buffe-Full Events werden im Paper als 10ms Blocks bezeichnet, weil im Raum stand dass die Zeit zwischen zwei vollen Buffern eben 10ms betragen sollte).

Die Verifikation läuft analog dazu: Da der Buffer deterministisch gefüllt wird kann man genau sagen an welcher Stelle des Programms ein Buffer voll geworden ist, geleert wurde und mit der Füllung neu begonnen wurde. Alles was man zur Verifikation braucht ist die Grenze (z.B. als Index des x-ten Buffervorgangs) und den resultierenden Hashwert. So kann man nur durch das Ausführen isolierter kleiner "Teilbereiche" des Programms "stochastisch einigermaßen zuverlässige Verifikationen" erreichen.

Das was jetzt mal ganz vereinfacht erklärt; es gibt noch einige andere fancy countermeasures gegen einige triviale Angriffe ... im Paper steht es detaillierter.
Ich glaube es gibt noch einige Probleme: Was wenn jemand einen Teil des Programms identifiziert, für den er den Buffer schneller "vorhersagen" kann als wenn er den Teil des Programms ausführen müsste (hier wieder die Klassische Faster Algorithm Attacke). Somit könnte er diese "Proofs" signifikant schneller generieren als andere Miner, welche den Programmteil wirklich aufrichtig rechnen.

Die Faster Algorithm Attack ist allgegenwärtig und raubt uns den letzten Nerv ;-)

Wir sind uns ins der Community noch nicht einig ob es nur eine Form von DOS (man kann nur seine eigenen Aufgaben lösen und so sein eigenes Geld von sich selbst verdienen) ist oder ob es wirklich problematisch sein könnte (wenn man von anderen Geld verdient ohne sinnvoll zu arbeiten).

Es ist wirklich sehr schwierig, aber aus der Sicht der Informatik höchst interessant. Schade nur, dass wirklich Interessante Projekte oft nur im Schatten der Ganz-und-Glamor Coins stehen, die das Rad zum x-ten Mal neuerfinden.

Das ist ein super Ansatz, und ich bin ehrlich "just for fun" habe in euch investiert. Weil das Potenzial bei Erfolg enorm wäre. Schade das euer Projekt im schlechten Licht steht grade bzgl. des Scam verwurfes...aber na ja. Ist eben sehr schwer ein gutes Projekt zu führen und zu vermitteln...eigene Erfahrung^^

[thandie]

Gerade hierüber gestolpert:

https://blog.lisk.io/boris-povod-joins-lisk-as-our-first-adviser-8e2c3d54b03d#.jrtiaembe

Please note that as an adviser he won’t serve as a member of the Lisk core team, but rather as a consultant from time to time.

Adviser, kein Mitglied des Teams.

Ich habe es mir schon fast gedacht, daß Du hier etwas durcheinander bringst.


Boris als Advisor - Das war von Anfang an so und wurde auch überall so veröffentlicht.

https://bitcointalk.org/index.php?topic=1348884.msg13828495#msg13828495

Also hat sich am Status von Boris in Beziehung zu Lisk nichts geändert.

[Macno]

Was haltet ihr von Synero AMP ist eich weit gedroppt inzwischen. Lohnt sich nachkaufen?

Ich halte sehr viel von Synereo, verfolge deren Aktivitäten seit über einem Jahr, war auch beim ICO dabei und bin weiterhin sehr optimistisch.
Demnächst kommt die nächste Finanzierungsrunde über Bnktothefuture und eine Beta-Version ihrer Software.
Das Dev Team ist aus meiner Sicht fachlich top, siehe zB
https://www.reddit.com/r/ethtrader/comments/49g792/synereoethereum_partnership_leads_to_big_fucking/

Zum Preis: wir sind jetzt fast wieder auf dem Niveau von vor dem Poloniex Launch (ok, nicht ganz, aber bei Bittrex waren wir in der Spitze auch bei 0.00012). Steht und fällt halt alles mit dem Social Network und dessen Nutzung. Wenn das wie gepant gelingt, ist AMP spottbillig.

[allyouracid]

…das, was Du da gerade geschrieben hast, hat mich aus den Socken gehauen. DAS hört sich mal richtig interessant an. Vor allem die fett markierten Teile.
Gibt es schon ein Whitepaper o.Ä.? Würde mich da nur all zu gerne näher reinlesen, und eine Idee bekommen, wie die Verifizierung gelöst wird.

Es gibt eine Vage idee und ein Whitepaper was unsere erste Idee in ihren Grundzügen beschreibt.
Natürlich muss das Whitepaper viel detaillierter werden und den Ansatz ausführlich Evaluieren, aber zunächst gilt herauszufinden ob der Ansatz überhaupt etwas taugt.

https://github.com/elastic-project/whitepaper/raw/master/whitepaper.pdf

Die Idee ist quasi einen "State-Buffer" mitzuführen, welcher "während der Ausführung eines Programms" mit einer konstanten Rate gefüllt wird. Da SHA256 selber einen Stream aufnehmen kann, kann dieser Buffer quasi direkt in die SHA256 gepipt werden. Ist der Buffer "voll" so wird der resultierende Hash mit einem Targetwert verglichen: erfüllt er gewisse Kriterien z.B. eine gewisse Difficulty so gilt der "Beweis" als akzeptiert.
Das korrekte füllen des Buffers entspricht quasi dem korrekten Ausführen des Programms. Nachdem der Buffer voll ist und die Checks abgeschlossen sind, fängt alles wieder von vorne an; natürlich während das Programm weiter läuft. (ich glaube diese Programmabschlitte zwischen zwei Buffe-Full Events werden im Paper als 10ms Blocks bezeichnet, weil im Raum stand dass die Zeit zwischen zwei vollen Buffern eben 10ms betragen sollte).

Die Verifikation läuft analog dazu: Da der Buffer deterministisch gefüllt wird kann man genau sagen an welcher Stelle des Programms ein Buffer voll geworden ist, geleert wurde und mit der Füllung neu begonnen wurde. Alles was man zur Verifikation braucht ist die Grenze (z.B. als Index des x-ten Buffervorgangs) und den resultierenden Hashwert. So kann man nur durch das Ausführen isolierter kleiner "Teilbereiche" des Programms "stochastisch einigermaßen zuverlässige Verifikationen" erreichen.

Das was jetzt mal ganz vereinfacht erklärt; es gibt noch einige andere fancy countermeasures gegen einige triviale Angriffe ... im Paper steht es detaillierter.
Ich glaube es gibt noch einige Probleme: Was wenn jemand einen Teil des Programms identifiziert, für den er den Buffer schneller "vorhersagen" kann als wenn er den Teil des Programms ausführen müsste (hier wieder die Klassische Faster Algorithm Attacke). Somit könnte er diese "Proofs" signifikant schneller generieren als andere Miner, welche den Programmteil wirklich aufrichtig rechnen.

Die Faster Algorithm Attack ist allgegenwärtig und raubt uns den letzten Nerv ;-)

Wir sind uns ins der Community noch nicht einig ob es nur eine Form von DOS (man kann nur seine eigenen Aufgaben lösen und so sein eigenes Geld von sich selbst verdienen) ist oder ob es wirklich problematisch sein könnte (wenn man von anderen Geld verdient ohne sinnvoll zu arbeiten).

Es ist wirklich sehr schwierig, aber aus der Sicht der Informatik höchst interessant. Schade nur, dass wirklich Interessante Projekte oft nur im Schatten der Ganz-und-Glamor Coins stehen, die das Rad zum x-ten Mal neuerfinden.

Danke für die Ausführungen - ich bin selbst zwar kein Informatiker ("nur" Webentwickler), finde es aber ebenfalls wahnsinnig interessant. Ich werde mich da mal genauer reinlesen (danke fürs Whitepaper) und das Ganze weiter verfolgen.

Dem letzten Satz stimme ich vollkommen zu. Innovation und Genialität ist halt leider nicht das, was die Märkte treibt, sondern Unvernunft und Gier. Das Lösen komplexer Probleme scheffelt dem gierigen Mob halt nicht schnell genug die Taschen voll; die sehen lieber, wie Bobo the Clown™ auf Twitter wütet und versenken ihre Kohle da.
Aber das ist imho auch nicht, was wichtig ist. Langfristig werden gute Ansätze erkannt, aufgegriffen und weitergetragen. Das, was also wirklich einen Unterschied macht, wird auch auf die eine oder andere Art einen Einfluss haben. Und zwar auf eine wesentlich bessere Weise als ein Pump, der zwei Wochen geht, wenigen Leuten die Taschen füllt und danach ein zerstörtes Projekt mit Null verbliebenem Vertrauen und einen großen Scherbenhaufen hinterlässt.

Ich glaube zwar nicht, dass ich erfolgreich sein werde, aber über die Faster Algorithm Attack werde ich mir mal Gedanken machen. Möglicherweise kommt mir ja eine Idee, die in was Brauchbares umgewandelt werden kann.

[ImI]

Gerade hierüber gestolpert:

https://blog.lisk.io/boris-povod-joins-lisk-as-our-first-adviser-8e2c3d54b03d#.jrtiaembe

Please note that as an adviser he won’t serve as a member of the Lisk core team, but rather as a consultant from time to time.

Adviser, kein Mitglied des Teams.

Ich habe es mir schon fast gedacht, daß Du hier etwas durcheinander bringst.


Boris als Advisor - Das war von Anfang an so und wurde auch überall so veröffentlicht.

https://bitcointalk.org/index.php?topic=1348884.msg13828495#msg13828495

Also hat sich am Status von Boris in Beziehung zu Lisk nichts geändert.

Hatte mich missverständlich ausgedrückt, mit "nicht mehr 100% dabei" meinte ich das er beim Wechsel von Crypti auf Lisk nicht voll mitgezogen ist. 100% wäre er ein Full-Time-Developer. Und somit stimmt eben der Satz, wir haben einen Max welcher kein Dev ist und einen Boris welcher (im Gegensatz zu Crypti) nicht mehr 100% dabei ist. Und dann bleibt ausser Olivier eben nicht viel. Und die Ziele benötigen ja eher ein gutes Dutzend Developer anstatt 1 1/2 wenn es hochkommt.

Aber sie haben ja jetzt genug Schotter also steht dem nix im Wege.

[thandie]

 

[e-coinomist]

Hatte mich missverständlich ausgedrückt, mit "nicht mehr 100% dabei" meinte ich das er beim Wechsel von Crypti auf Lisk nicht voll mitgezogen ist. 100% wäre er ein Full-Time-Developer. Und somit stimmt eben der Satz, wir haben einen Max welcher kein Dev ist und einen Boris welcher (im Gegensatz zu Crypti) nicht mehr 100% dabei ist. Und dann bleibt ausser Olivier eben nicht viel. Und die Ziele benötigen ja eher ein gutes Dutzend Developer anstatt 1 1/2 wenn es hochkommt.

Aber sie haben ja jetzt genug Schotter also steht dem nix im Wege.

Gibt es denn da eine Ausschreibung, Suche nach Devs (und wieviel die bieten) ?

[Poly#Crypto]

Gibt es denn da eine Ausschreibung, Suche nach Devs (und wieviel die bieten) ?

Momentan nicht.

Aber falls Du interessiert bist und das entsprechende Know-how mitbringst, melde dich doch einfach. Ich denke mal, an der finaziellen Frage sollte es nicht scheitern. 

[sofu]

Schade, die die einzige IPO, wo ich paar BTC reinwerfen wollte, wird so wohl nicht stattfinden.

http://www.smithandcrown.com/slock-it-dao-crowdsale-to-be-unofficial-delays-expected/

[WorldCoiner]

Die Strafe dafür, dass Sie mir kein Interview geben wollten^^
Nein, im Ernst, sehr schade auch für den Kryptostandort Deutschland. Wird auch andere geplante DOA Projekte beinträchtigen bzw. vom Börsengang in Deutschland abhalten.