Es gibt ein Video über steuerliche Fallstricke beim Umgang mit Kryptowährungen auf der vergangenen FrOSCon. Den Vortrag hielt der Steuerrechtsexperte Axel Hellinger.

Sehr erhellend fand ich den Zusammenhang, dass bereits der Einsatz eines Tradingbots zu einer Neubewertung gegenüber dem Finanzamtder BaFin führen kann (14. bis 15. Minute). Das Video kann hier als Stream angesehen oder einfach heruntergeladen werden.


Gruss
Bill

Edit: Falsche Begriffe und Zusammenhänge korrigiert.

Hallo Freyr,


Nach langem hin- und herüberlegen komme ich immernoch nicht drauf, was du damit ausdrücken möchtest.

Angenommen hier gäbe es keinerlei Experten. Dann könntest du dir eine solche Aussage nicht erlauben, weil du in dem Fall auch kein Experte sein könntest.

Allerdings schreibst du eine solche Aussage, weshalb du ein Experte zu sein scheinst. Falls das stimmen sollte, wäre mindestens eine Person hier zugegen, welche sehr wohl kompetenten Rat geben könnte.

Also macht deine obige Aussage in keinem der betrachteten Fälle Sinn, dass solche Themen ausschließlich woanders (wo auch immer das deiner Meinung nach sein sollte) besprochen werden sollten.

Oder was meinst du, wo die heutigen Experten alle herkommen? Die haben allesamt mal unwissend angefangen.

Falls du gemeint haben solltest: "Hey, holt euch Security-Experten für den Aufbau!", dann sei mal kurz angemerkt, dass diese in der Regel enorm viel Geld kosten und dennoch für einen Außenstehenden die konkrete Kompetenz nicht nachprüfbar ist. Also kann man den Exchange auch gleich geschlossen halten und sich für das Geld ein schönes Häuschen in die Pampa stellen.

Zu deiner möglichen Kernaussage bezüglich des vorher Informierens. Wenn ich mir die Ruinen von MtGox so ansehe und dann mal kurz anschaue, was die Ursache für den Bitstamp-Hack gewesen zu sein scheint: Da kommen mir ernsthafte Zweifel, ob sich überhaupt jemand vorher bzgl. Sicherheit informiert zu haben scheint. Besonders bei Stamp habe ich den Eindruck gewonnen, dass da ein Webdesigner mit der gesamten Programmierung beauftragt wurde. Dabei sollte ich vielleicht mal erwähnen, dass Webdesigner in der Branche im Allgemeinen einen sehr schlechten Ruf bzgl. Programmierung mit Sicherheitsanforderungen haben. Das liegt auch daran, weil jeder Mausschubser mit ein bisschen Editorkenntnissen sich in der Regel auch Webdesigner schimpfen darf. Da wird keinerlei tiefergehendes Verständnis der zugrundeliegenden Technologien vorausgesetzt. Mir sind in der Vergangenheit schon einige Exemplare dieser Spezies über den Weg gelaufen, welche schon mit Fragen über die RFCs 768, 791 und 793 hoffnungslos überfordert waren.

Weiterhin schrieb ich oben ausdrücklich:

Weshalb du dich da zu der Aussage:

aufgerufen fühlst, kann ich nicht nachvollziehen. Aus meiner Sicht hatte ich bereits deutlich gemacht, dass das alleine nicht ausreichend ist, um sowas vernünftig aufzuziehen. Aber es sind Tipps, die sich als Best-Practices in meinem Umfeld herauskristallisierten und dementsprechend wertvoll sein können.

Falls du ein Experte sein solltest, dann bringe bitte deine konkrete Kritik im Rahmen der von mir geschilderten Punkte ein. Damit können wir hier durch die Diskussion vielleicht eine Art Katalog zusammenstellen, von dem alle Seiten profitieren würden.

Andernfalls sehe ich auch an diesem Punkt keinerlei Mehrwert für irgendwen.

Gruss,
Bill

Mache ich vielleicht zum Wochenende hin. Momentan habe ich auch hier schon eine Menge zu tun, da passt mir das Übersetzen eigentlich nicht so ganz in den Kram.

Es handelt sich hierbei um die Forführung der Beiträge aus diesem Thread.


Falls jemand vorhaben sollte, einen Exchange aufzumachen, möchte ich ein paar kleine Tipps loswerden (nicht vollständig):
1. Überlegt euch vor der Implementation, welche Sachen unbedingt in den Exchange verbaut werden müssen. Je weniger verbaut wird, desto kleiner ist die Angriffsfläche. Je kleiner die Angriffsfläche, desto weniger Informationsgewinn für einen Angreifer.
2. Sucht euch Leute, die schonmal sicherheitskritische Systeme implementierten. Solltet ihr diese nicht finden können, dann achtet darauf, dass ihr möglichst wenige aber dafür für eure Anforderungen am besten geeignete Bibliotheken einbaut. Im Zweifelsfall entscheidet euch für die Bibliothek, welche den größeren Anteil aktiver Entwickler, Tester und dokumentierte Testfälle hat.
3. Wenn ihr Bibliotheken verbaut, so vergesst bitte SaaS (Software as a Service). Ihr baut ein sicherheitskritisches System und eben keine Werbeplattform für externe Dienstleister. Der zusätzliche Code darf aber wegen der besseren Isolier- und Modularisierbarkeit durchaus von einem anderen Server kommen. Dieser sollte aber exakt in derselben Domäne stehen, wie die aufgerufene Seite.
Sinn dahinter: Ein Angreifer erhält so gut wie keine Informationen frei Haus geliefert. Das erschwert die Planung eines Angriffs und erhöht den Aufwand.
4. Misstraut grundsätzlich allen Komponenten, die Teil eures Designs sind. Und jetzt betrachtet euer Vorhaben erneut! Wie schottet ihr die Komponenten gegeneinander ab? In welche Richtung fließen die Daten? In welcher Richtung werden die Steuerungsbefehle gelenkt? Wie sollte es möglichst nicht aussehen, wenn jemand euer Netzwerk übernommen hat? Was würde einem Angreifer so richtig die Suppe versalzen, wenn dieser euer Netzwerk übernommen haben sollte?
5. Investiert mehr als die Hälfte aller eurer Mittel (sowohl Zeit als auch Geld und jegliche andere Ressourcen) in Fehler! D.h. geht davon aus, dass mehrere Tage lang alles schief gehen würde, was nur irgendwie schief gehen kann. Wie sollte das System in der Situation reagieren? Wie schlimm wirken sich Userfehler aus? Was kann durch fehlerhafte Bedienung schief gehen?
Kommt es z.B. durch Bedienfehler zum Datenverlust oder Rechenfehlern, dann wisst ihr bereits ganz genau, dass ihr auf dem Holzweg seid. Testet das System. Rollt nur getestete Komponenten aus und seid euch nicht zu fein dafür, sowohl Unittests als auch Integrationtests einzufordern. Sollte strikt das MVC-Prinzip beibehalten worden sein, dann könnt ihr die kritischen Komponenten fast immer vollautomatisiert testen. Für Integrationstests im Modell eignen sich z.B. expect (Tcl) und pexpect (Python). Greift im Testbetrieb euer eigenes System an! Sabotiert es! Trachtet danach, es zu zerstören! Nutzt Fuzzing (d.h. schmeißt Zufallswerte in die Eingabemasken!). Wenn euer System das alles verdaut, dann kann es in den Produktionsbetrieb gehen und wird ausschließlich netzwerkbasierte DoS-Attacken zu fürchten haben.

Wenn ihr das alles zusammennehmt, kommt ihr zu der goldenen Regel: Designt euer System grundsätzlich als Default-Deny und macht es dennoch fehlertolerant! D.h. das System sollte keinem Client trauen. Ganz besonders dann nicht, falls ein Aufruf nicht ganz sauber sein sollte. Der Server darf möglichst keine Informationen über den internen Aufbau herausgeben. Besonders auf Fehlerfälle darf dieser nach außen nur mit Schweigen und "Business as usual" reagieren.

Verschlüsselung erwähnte ich bisher nicht, weil ich diese als Standard voraussetze. Es versteht sich von selbst, dass diese nur in begründeten Einzelfällen selbst implementiert werden sollte. Das Risiko, Timings nicht richtig gegeneinander abzuwägen oder Speicherbereiche nicht sauber zurückzusetzen ist meistens größer, als die zusätzliche Angriffsfläche durch eine bekannte Bibliothek.

Das war nicht die Intention für meinen ursprünglichen Einwand auf asors Beitrag. Ich hätte genausogut einen anderen Exchange herausgreifen und mal darauf hinweisen können. Cryptsy wurde eben nur gerade als vertrauenswürdiger Exchange gehandelt und das war aus meiner Sicht nicht rational begründbar. Im Einzelnen kann auch Cryptsy sich eine ganze Menge dabei gedacht haben. Es kann intern auch über Filterkaskaden und Intrusion Detection Systeme die eingebundenen Dienste so einschränken, dass diese im Ernstfall eben kein Komplettversagen verursachen würden. Aber sowas ist leider dermaßen selten und anspruchsvoll in der Umsetzung, dass ich eher vom ursprünglich geschilderten Gegenteil ausgehen würde. Dementsprechend kam ich für mich zu der Feststellung, dass ich einem solchen Aufbau eben nicht vertraue.

Als ein komplett anderes Beispiel erlebte ich vor Jahren auch schon einen Exchange, welcher auf beliebiges Querverlinken mit allen möglichen Dienstleistern verzichtete und bei mir eigentlich hoch im Kurs stand. Der Exchange war nahezu spartanisch eingerichtet: der Apache lief im Production-Mode, das Javascript kam ausschließlich aus der aufgerufenen Domäne und auch sonst machte das Ganze einen durchdachten und gewissenhaften Eindruck. Bis ich dann mitbekam, dass die Tradinglogik vollständig mit Floating-Point umgesetzt wurde. Dass das nur die Spitze des Eisbergs war, zeigte sich bei einem später stattfindenden Diebstahl der Exchange-Wallet. Dort war der Fehler das krasse Gegenteil: Der oder die Programmierer haben sich lieber an der erneuten Raderfindung versucht, anstatt auf getesteten Bibliotheken aufzusetzen.

Hierbei versuche ich also Anzeichen zu vermitteln, woran durchdachte Exchanges von Hinterhofklitschen meistens (also nicht immer) unterscheidbar sind.



Um diese Diskussion vielleicht noch ein bisschen vertiefen zu können, habe ich mal einen neuen Thread gestartet.

Zunächst einmal war AWS nur exemplarisch gewählt, weil das vorher angesprochen wurde. Vielmehr reicht aber in der Regel ein Fehler in irgeneiner verwendeten Komponente, um das darauf basierende System (in diesem Fall den Exchange) zu gefährden. D.h. wenn vier Dienste verlinkt werden, hat ein Angreifer in der Regel die Auswahl aus vier Diensten. Dieser braucht nur eine Lücke finden, die zu dem gewünschten Angriffszenario passt. Der Exchangebetreiber muss hingegen dafür Sorge tragen, dass gar keine sicherheitskritische Lücke besteht. Wie soll das gehen, wenn ein großer Teil eher auf Vertrauen statt auf Nachprüfbarkeit basiert? Konsistenzen im Code lassen sich in der Regel nicht vollständig beweisen, weshalb auch niemand jemals vollständige Fehlerfreiheit garantieren kann. Das ist einer der Gründe, warum Versicherungen in dem Bereich nur schwer zu finden sind.

Weiterhin ist anzumerken, dass bis auf ganz seltene Ausnahmen (z.B. das Computerspiel Banished) Programmierung ein Mannschaftssport ist und das ganze immernoch von Personen betrieben wird, die auch mal unkonzentriert sein können. Das ist menschlich und gehört einfach zum Business. Besonders im Unternehmensumfeld werdet ihr da nicht ein System finden, dass komplett alleine von einer Person geschrieben wurde. Diese müsste nämlich das Betriebssystem, die Serverkomponente, den darauf aufbauenden Dienst und sämtliche Verbindungen (z.B. Switche, Firmware im Backend) selbst programmieren und warten. Zeigt mir mal bitte irgendjemanden, der innerhalb weniger Jahre mehrere Milliarden Zeilen Code fehlerfrei in C/C++ zusammenschreibt.

Wo wir gerade dabei sind. Ihr könnt euch ja mal den Spass machen und recherchieren, bei wievielen Bugs pro KLOC man derzeit von hoher bzw. guter Softwarequalität im PHP-, Perl- und C/C++-Umfeld spricht. Dazu empfehle ich was Hochprozentiges.

Dass mal jemand mit Kompetenz unter all den outgesourcten Indern, Chinesen und Taiwanesen dabei ist, verbessert die Lage nämlich nur punktuell aber nicht systemweit.

Weil das gestern zu kurz kam: Cloudflare und Co. gehören zu den wenigen Diensten, die Sinn machen. Für das Risiko, dass bei einem Rundumschlag gleich mehrere Exchanges versterben können, erhält jeder Exchange zunächst einmal eine deutliche Robustheit gegenüber allen netzwerkbasierten DoS-Varianten. DoS-Attacken sind wahrscheinlicher, als verfügbare Exploits in diesen Diensten. Deshalb macht das Sinn, sobald man sich a) nicht die Infrastruktur leisten kann oder b) nicht das nötige Know-How für Loadbalancing und ausgeklügeltes Netzwerkmanagement hat.

Dagegen ist auch nichts einzuwenden, sofern es sich um eine Unternehmenspräsenz handelt. Aber sobald es um sicherheitsrelevante Themen geht, reicht dieser Standard nicht mehr aus. Es hat schon seinen Grund, warum z.B. selbst die Sparkasse in ihrer Webpräsenz auf den Firlefanz verzichtet.

Es ist schon richtig, dass man besser auf Bibliotheken zurückgreifen sollte, bevor man programmiertechnisch Neuland betritt und als Unternehmslogik verbaut. Aber für Exchanges ist genau diese Sichtweise ein riesiges Problem. Sobald nämlich eine Lücke in der Amazon-Schnittstelle verkauft werden sollte, ist ein Hack auf den damit verbundenen Exchanges gratis mit drin. Das ist systemisches Versagen erster Güte und damit ein Paradies für jeden Möchtegern-Ganoven. Dann ist es eben kein Wunder, dass in einer Reihe vier oder fünf Exchanges platzen.


Warum? Weil Mathematik, Statistik und Risiko-Chancen-Abwägung überall funktionieren nur eben nicht bei Amazon? Was macht deren Service garantierbar fehlerfrei? Gelten die Theoreme von Turing und Gödel für die gesamte Computerwelt, nur nicht für Amazon?
Die Argumentation "das-haben-wir-schon-immer-so-gemacht" ist gerade hier deplatziert. Sie entbehrt jeglicher rationaler Grundlage. Es sind doch eure Coins, also warum lasst ihr sowas zu und nehmt jeden Exchange der nicht bei drei auf den Bäumen ist? Ist euch der Bitcoin so wenig wert?


Ein simples Rechenbeispiel. Angenommen pro KLOC (d.h. tausend Zeilen Code) gäbe es genau einen real existieren Bug (d.h. 1 BpKLOC). Nur jeder zehnte dieser Bugs sei sicherheitsrelevant (d.h. 0,1 BpKLOC sei der sicherheitskritische Anteil). Dann heißt das im Klartext, dass in diesem idealisierten Beispiel pro zehntausend Zeilen Code eine Zeitbombe schlummert. Weiterhin angenommen sei, es würden immerhin 40% aller Bugs gefunden. Dann heißt das im Klartext, dass ab einer Komplexität von achtzigtausend 25000 Zeilen Code mindestens ein sicherheitskritischer Fehler realistisch vermutet werden kann, der früher oder später auftreten muss, aber bisher noch nicht gefunden wurde.

Nun stecken aber mehrere hunderttausend Zeilen Code jedoch nicht nur in den AWS alleine, sondern zusätzlich noch in jeder Backendlogik, die eingebunden wird und im Webservice selbst. Jeder dieser Faktoren hat ein Backend, ein System (z.B. Betriebssystem, Hypervisor oder ähnliches) und Switche mit Firmware. Betriebssysteme haben übrigens unlängst die Milliarden-Marke bei der Zählung der Sourcecode-Zeilen überschritten.

Ist euch klar, dass damit riesige Probleme vor sich hin schlummern, die umso mehr wachsen je mehr von dem Schwachsinn ohne Not als Features eingebaut werden?

Das Problem oben habe ich schon bewußt klein und damit schöngerechnet, weil z.B. Oracle, Adobe und noch ein paar andere bekannte Marken in der Branche vermutlich in zehn bis hundert BpKLOC angenommen werden können. Da dürfte das Ergebnis also deutlich vernichtender ausfallen.

Oh und Oracle werkelt bei der einen oder anderen Seite im Backend. Soviel sei euch schonmal versichert. Was erwartet ihr denn auch anderes? Da setzen sich irgendwelche Webdesigner und Programmierer in dem Glauben hin, dass das schon nicht allzu kritisch sein wird. Und ihr bezahlt die Exchanges auch noch dafür, dass sie euch im Zweifel eine Sicherheitsillusion andrehen ohne euch darüber im Klaren zu sein, dass auch dort nur mit Wasser gekocht werden kann.

Das meinte ich in einem früher Beitrag mit meinem Hinweis, dass ich kein Spielgeld mehr für solche Experimente übrig habe.

Tante Edith so zu mir: Du hör mal, nimm mal bitte einen Taschenrechner für die untere Schranke.

Habe ich gemacht und oben korrigiert.

Nur mal oberflächlich überflogen braucht die Seite zusätzlich zum Javascript-Gedöns von cryptsy selbst:
http://pusher.com  (Echtzeitbibliotheken)
http://debitway.ca  (alternative Bezahldienste)
https://s3.amazonaws.com  (externer, verteilter Speicherplatz)
http://google-analytics.com  (Klickstatistiken)

Während pusher und debitway gerade noch so als Lib-Quellen für besondere Features herleitbar sind (Pusher: Echtzeitunterstützung; Debitway: Alternative Zahlungsmöglichkeiten), frage ich mich ernsthaft, warum eine Börse dicken Speicherplatz in den Amazon-Cluster externalisiert und zudem noch die Seitenzugriffe per Google mitloggen will.

Neben der zusätzlichen Programmierkomplexität und dem damit verbundenen Risiko von zusätzlichen Bugs in der Webseite wird damit noch stolz das Problem reingeholt, dass ein Fehler bei Amazon, Pusher, Debitways oder Google auch zu einem Sicherheitsproblem für Cryptsy werden kann.

Für mich eher ein Hinweis darauf, dass dieser Exchange mein Vertrauen gerade nicht verdient.

Das ist ja auch nicht das Problem. Sondern die Probleme sind:
1. Wie wird sichergestellt, dass auch ein Exchange zurückbuchen kann, wenn er 1) nur mit kompromittierten Knoten verbunden ist und 2) auf einem kompromittierten Netzwerk aufbaut?
2. Wie kann Missbrauch verhindert werden? Nämlich z.B.: 1. Schritt: Bitcoins auf Exchange; 2. Schritt: Bitcoins in Altcoins tauschen; 3. Schritt: Altcoins abziehen und im selben Zug Bitcoins zurückbuchen.

Nochmal: Die Sicherheit der Exchanges sollte bei den Exchanges geschehen und nicht bei den Bitcoin-Implementationen. Alles andere mutiert auf lange Sicht zu einem unüberschaubaren Wust aus Sonderregelungen und Ausnahmebehandlungen, welcher dementsprechend fehlerträchtig wäre.

Sollte das Blacklisting für Bitcoins jemals implementiert, werde ich jedem Bekannten dringend von Bitcoins abraten. Dann ist jeder andere Crypto nämlich um Lichtjahre besser. So eine "Lösung" ist einfach aus den oben genannten Gründen heraus ein Schuss ins eigene Knie: Sie bringt Nachteile für keinen echten Vorteil.

Tante Edith: Hast Du jetzt verstanden, warum diese Antwort kam?

Ja! Jetzt habe ich auch kapiert, dass OhShei8e sich rein auf die technische Umsetzbarkeit bezogen hat. Sofern es nur irgendwie funktionieren soll, ist das wirklich einfach.

Aber eine manipulationssichere Variante ist schwierig zu implementieren (z.B.: Auf welchen Annahmen basieren die Entscheidungen für oder gegen ein Blacklisting? Wie sieht es mit modifizierten Knoten im Besitz des Angreifers aus? Ein einfacher Angriff wäre z.B. ein modifizierter Man-in-the-Middle: Der Angreifer sorgt dafür, dass sich das Opfer nur mit Knoten im Besitz des Angreifers verbindet.). Darüber hinaus hätte ein solches Feature die von mir genannten Nebenwirkungen (Komplexität des Codes, Unattraktivität für den Handel, Missbrauchspotenzial und Sinnlosigkeit des Blacklistings, sofern dieses nur für eine bestimmte Zeit gelten soll). Diese meinte ich mit "dass auch das Blacklisting nicht klappt".

Sobald du dir mal Gedanken drüber machen solltest, wird dir wahrscheinlich auffallen, dass auch das Blacklisting nicht klappt.
Was bedeutet Blacklisting? Genau: Die Coins werden dem Kreislauf entzogen. Wie lange soll das sein? Angenommen, die Coins würden auf ewig geblacklistet. In dem Fall würde sich irgendjemand finden, der dann anfängt die Coins von legitimen Exchanges zu blacklisten. Was kann damit gewonnen werden? Die Verknappung führt langfristig zu einer Verteuerung der übriggebliebenen Coins. Die betroffenen Exchanges jedoch sind faktisch zahlungsunfähig, obwohl sie die Coins eigentlich haben. Damit kann die Konkurrenz ausgedünnt werden oder der Handel komplett zum Erliegen gebracht werden.

Sollte das Blacklisting nur vorübergehend sein, so hätte es keinen Sinn. Warum das so ist, wird dir sicher klar werden, sobald du da verschiedene ähnliche Geschäftsmodelle wie die Mixer beobachtest. Von der technischen Seite her ist es überdies schwierig, so etwas sauber und unumgehbar zu bauen.

Das Problem beim Blacklisting ist einfach, dass auch das ein gewisses Missbrauchspotenzial in sich birgt.

Noch einmal: Das Problem bei den Hacks ist nicht der Bitcoin, sondern die unerfahrenen Programmierer mit naiver Herangehensweise beim Aufbau von Exchanges.

Deshalb sollte das Problem auch genau bei den Exchanges in Angriff genommen werden und nicht durch Hinzufügen von Features im Bitcoin selbst. Damit ist nämlich zwangsläufig das Hinzufügen von Abstraktionsschichten verbunden, die einerseits mit Kompatibilitätsproblemen und andererseits mit zusätzlichen Bugs erkauft werden. Aus meiner Sicht bietet das aber keinerlei Vorteile.

Bitcoin sollte genau zwei Dinge machen: 1) Werte Clienten in einem Netzwerk manipulationssicher einzelnen Wallets zuordnen und den 2) Austausch der Werte ermöglichen. Alle weitere Komplexität sollte modular drumherum und eben nicht im Bitcoin selbst implementiert werden. Alles andere ist technisch gesehen totaler Murks und lädt verschiedene Interessengruppen nur dazu ein, früher oder später den Bitcoin beerdigen zu wollen.

Durch diese "wir-wollen-eine-eierlegende-Wollmichsau-Mentalität" haben doch erst die Sicherheitsprobleme an den Börsen geschaffen. Statt daraus zu lernen, forderst du aber eine Expansion dieses Wahnsinns in die Basis: nämlich in die Clients und damit in das Netzwerk.

Was passiert dann? In dem Fall haben wir dann wirklich irgendwann einen Rohrbruch im Bitcoin selbst. Das ist übrigens das einzige Szenario, in dem der Bitcoin tot ist. Das Problem wäre nämlich in keinster Weise auffangbar und hätte für alle Beteiligten Folgen.

Tante Edith mal wieder: Du solltest lesbarer schreiben! Ja, das habe ich jetzt behoben.

Dann lasse mich mal ganz naiv fragen: Was würden wir eigentlich mit einem Bitcoin machen, bei dem die Überweisungen rückbuchbar wären? Angenommen, der Walletinhaber hat einen Revocation-Key, dann kann ein Betrüger doch eine Überweisung tätigen und dann seinen Key nutzen, um sich zu bereichern. Also zuerst Geld auf einen Exchange, dann Altcoin kaufen, Altcoin abziehen und Überweisung rückbuchen. Das geht innerhalb weniger Sekunden, wenn man es richtig anstellt.
Was wäre damit gewonnen? Ein gepwntes System kann den Revocation-Key sicher nicht nutzen, weil dafür müsste der Exchange erstmal im Besitz eines nichtkompromittierten Systems im Netzwerk sein. Andernfalls kann jegliches "Senden des Revocation-Keys" von den Angreifern unterbunden werden.

Angenommen, das Netzwerk entscheidet über die Rückbuchung. Dann muss der Betrüger nur dafür sorgen, dass die Latenzzeiten zu seinen Knoten vom Opfer aus möglichst gering sind. Dadurch verbindet sich das Opfer mit den vom Angreifer kontrollierten Knoten. Also ist auch eine solche Maßnahme relativ leicht auszuhebeln.

Anderenfalls würde kein vernünftiger Händler mehr Bitcoins annehmen, weil diese ja im wesentlichen zurückgeholt werden können.

Ein solches Feature macht schon beim oberflächlichen Betrachten mehr Probleme, als damit gelöst werden würden.

Hier sind die Exchanges in der Pflicht. Wenn nur Programmierdeppen nach dem "schnell-und-billig"-Prinzip eingestellt werden, braucht sich keiner zu wundern, dass das in die Hose geht. Da wird eine Komplexität in die sicherheitskritische Infrastruktur geladen, die nicht mehr auditierbar ist. An der Stelle mal den klassischen Bad-Smell genannt: Wenn mehr als zwei Sites verlinkt werden und dann noch jede Menge Java-, Javascript- und noch besser Flash- oder Silverlight-Müll nachgezogen wird, dann ist die Exchange das Vertrauen einfach nicht wert.

Sicherheit kann grundsätzlich nur durch einen Verzicht auf Komplexität gewonnen werden. Ansonsten arbeitet beweisbar die Statistik dank der damit verbundenen Bugs gegen die Sicherheit und für sämtliche Scriptkiddies.

Wer sowas also programmiert, sollte möglichst wenig Bibliotheken nutzen, möglichst wenige Dienste zusammen an einem isolierten Ort laufen haben, diese isolierten Orte gegeneinander Abschotten und zusätzlich extensiv den Code testen. Danach sollte der Code mehrere Security-Audits durchlaufen. Die Hardware sollte stark heterogen gewählt werden, damit Firmware-Bugs isolierbar bleiben und zu keinem Systemversagen führen.


Das ist genau der Punkt. Je mehr Features in Bitcoin selbst verbaut werden, desto wahrscheinlicher sind Bugs, die ein systematisches Versagen des zugrundeliegenden Clients verursachen können.

TL; DR: Es handelt sich dabei um den Versuch der Rekonstruktion des Vorhersagemodells von 1910 bis 1920. Es ist hochkomplex, wodurch jegliche andere mir bekannte Technik ein deutlich besseres Aufwand-Gewinn-Verhältnis aufweist (allen voran Tradingbots). Selbst Karten legen ist da überschaubarer (und bei kurzen Trends vielleicht sogar besser geeignet).


Nein. Seit etwa Februar 2013 versuche ich eine Rekonstruktion der Vorhersagemodelle von 1910 bis 1920. Das ist ein hochkomplexes System, welches benutzerunfreundlich ist. Dank sehr dünner Quellenlage bin ich auch auf viel Improvisation angewiesen, welche bisher sogar bei klaren Trends deutlich schlechtere Ergebnisse liefert, als für das Original nachweislich belegt ist.

Es versagt komplett bei kurzen Rallys. Z.B. die Rally vom 08. bis 10.04.2013 konnte das System nicht vorhersagen. Also alle Kursschwankungen, die innerhalb von zwei Wochen stattfinden, werden im Modell nicht abgebildet (Trefferquote: 5%! Selbst Würfeln hat eine bessere Chance!). Praktisch bedeutet das, dass das System umso blinder ist, je kurzfristiger der Trend passiert. Oder anders ausgedrückt: Jeder noch so schlechte Tradingbot bringt bessere finanzielle Resultate, als das Vorhersagemodell. Darüber hinaus ist ein Tradingbot auch leichter zu programmieren und einfacher in der Bedienung.

Warum ich es noch nicht beerdigte, ist ein Ergebnis des Modells vom Mai 2013: ATH am 08.08.2013 mit starken und dauerhaften Kursrutschen ab 09.08.2013. Die Vergangenheit zeigt, dass die Daten nicht zutreffend sind. Jedoch ist es genau genug, um mich zu faszinieren.
Eine andere Erkenntnis aus dem Modell ist nämlich, dass der Downtrend bis Februar 2015 (genauer: Bottom am 07.02.2015) anhalten und sich durch einen stabilen Uptrend ablösen würde. Nun sind die Tendenzen im Modell (ausgedrückt als modell-interne Preise) im Vergleich zur Realität sehr unterschiedlich. Das bedeutet, dass wir auch beim modell-internen 07.02.2015 mit einer klaren zeitlichen Verschiebung gegenüber der Realität zu rechnen haben. Weil aber die Trendstärke ab 12./13.02. im Modell jegliche Abwärtstendenz nulliert, gehe ich davon aus, dass um den 10. bis 13.02. herum jegliche Abwärtstrends ausgeglichen werden. Oder anders ausgedrückt: Keine Abwärtstrends nach dem 19.02.2015 ist aus der Sicht des Vorhersagemodells eine sichere Vorhersage, keine Abwärtstrends nach dem 13.02.2015 ist eine wahrscheinliche Vorhersage und Bodenbildung zwischen dem 04.02. bis 10.02.2015 ist durchaus möglich. Was davon wirklich geschieht, werden wir erst sehen können, wenn es tatsächlich passiert ist.

Alles in allem ist jede andere mir bekannte Technik erfolgreicher, als das Trading nach dem Vorhersagemodell.
Warum ich trotzdem noch von Zeit zu Zeit am Modell weiterarbeitete, war die Hoffnung auf ein tieferes Verständnis von Bitcoin und Märkten im allgemeinen. Momentan lese ich nur Ergebnisse ab, weil auch kleine Erweiterungsschritte im Modell enorm viel Zeit kosten und dann aufgrund begrenzter Hardwareressourcen auch weit hinter den Erwartungen zurückbleiben. Die Hardwareressourcen werden auch in den nächsten Jahrzehnten den Flaschenhals des Modells und damit die Achillesferse jeglicher daraus entstehender Vorhersage bilden.
Nebenbei habe ich auch noch ein Leben, weshalb das Projekt momentan stagniert und ich nur Tendenzen abfrage, diese in Preisen innerhalb des System zu quantifizieren und letztendlich in Relation zur Realität zu setzen versuche. Alles sehr ungenau. Sollte der Downtrend tatsächlich mit dem Februar 2015 enden, finde ich vielleicht auch wieder genügend Kraft, das Modell zu hinterfragen und zu verbessern. Aber momentan möchte ich lieber meine Lebenszeit dafür nutzen, die ersten Sonnenstrahlen des Jahres zu genießen und meiner richtigen Arbeit nachzugehen.


Aufgrund der enormen Komplexität ist Voodoo, Kaffeesatz lesen oder Karten legen vermutlich überschaubarer.

Wie oben bereits erwähnt, ist die Motivation für mich eine andere. Würde es mir nämlich um Geld gehen, hätte ich das Projekt unlängst eingestampft und mir einen Tradingbot programmiert.

Tante Edith fragte: Wie nennst du das Vorhersagemodell? WGM-R oder WDGM-R: William (Delbert) Gann Model Reconstruction.

Es ist ja kein Befehl, sondern nur meine Sichtweise. Diese teile ich in der Hoffnung mit anderen, dass vielleicht ein paar Schicksale gemindert werden. In zwei Wochen werden wir sehen, ob ich damit richtig gelegen habe. Die Kursentwicklung in meinem Modell ist momentan tiefer, als der reale Kurs (im Modell sind wir jetzt bei 120 USD, nachdem wir bei 106 USD waren). Deshalb ist es durchaus möglich, dass das Modell zu pessimistische Ergebnisse liefert. Allerdings sind Teile des aktuellen Trends unvorhergesehene Wechsel und plötzliche Kurseinbrüche: Der Markt ist noch immer zu nervös, als dass man damit irgendwas langfristiges anstellen könnte. Das wird sich aber spätestens zum Ende diesen Monats komplett legen, weil auch unter schlechtesten Voraussetzungen die Bodenbildung nicht nach dem 19.02.2015 liegen kann. Mit der Bodenbildung wird die Nervosität zurückgehen, weil viele sich dann mit den realen Geschehnissen abfinden und (vorerst?) ganz aussteigen.

Aber ich will mir das nicht antun. Da ist viel zu viel Leid und Sorge um die private Altersvorsorge bzw. zerbrochene Hoffnungen auf ein besseres Leben dabei. Wir hier in den westlichen Regionen können uns nicht ausmalen, was der eventuelle Kursrutsch unter 150 USD für viele (besonders ärmere) Familien bedeuten würde.

Sind denn Werte nicht immer nur Schätzungen? Egal, ob es sich dabei um ein Haus, ein Auto, ein Gemälde, einen Teppich oder besondere Überraschungseier handelt: Es sind nur durch individuelle Sichtweisen getragene Bewertungen. Erst durch die unterschiedlichen Ergebnisse (bzw. Kauf- und Verkaufspreise) der Handelsteilnehmer gibt es eine Grundlage für Handel. Wieviele Basare und Flohmärkte gäbe es, wenn alles einen festen (bzw. festgelegten) Preis hätte? Genau keinen einzigen. Wo wäre der Anreiz für Händler im Allgemeinen, wenn sie etwas für 5 EUR ankaufen und für nicht mehr als 5 EUR verkaufen würden?

Erst durch die individuellen Unterschiedlichkeiten, durch die Schätzungsfehler und dergleichen gibt es die Ungleichgewichte, deren Resultat der Handel ist. Das ist die Lektion des Bitcoin, welche kein Novum darstellt. Zumindest Nietzsches Zarathustra verkündete diese bittere und zugleich stabile Wahrheit aller Epochen der bisherigen Menschheitsgeschichte. Jedoch können wir das am Bitcoin in der Praxis studieren.


Nächste Station ist mit hoher Wahrscheinlichkeit der Boden. Natürlich fallen meine Schätzungen nicht aus dem luftleeren Raum. Dennoch sind sie zu ungenau, um da irgendwas zu garantieren. Das hat was damit zu tun, dass die grundlegenden Modelle meiner Bewertungen unter bestimmten Umständen gar nicht und unter anderen Umständen sehr gut funktionieren. Das ist jedoch eine längere Geschichte und hat was mit der enormen Komplexität zu tun. Das ist der Preis für nichtlineare Abschätzungen auf schwankenden Datenbasen. Wer sich also darauf verlassen und alles auf eine Karte setzen sollte, tut das auf komplett eigenes Risiko, ohne dass ich dafür die Verantwortung in irgendeiner Form übernehme.

Diese Tatsache im Hinterkopf behalten sei hiermit erwähnt, dass ich die reale Bodenbildung irgendwo um den 04.02. bis 10.02.2015 erwarte. Zwischenzeitlich hoffte ich zwar darauf, dass wir das irgendwie aussitzen könnten. Aber jetzt wo die 220 USD gefallen sind, kann ich mit meinen Beiträgen auch nichts mehr verderben. Es wird wahrscheinlich tiefer gehen, als 159 USD. Die Chancen stehen gut, dass wir sogar 135 USD unterschreiten und damit kurzfristig sehr tief fallen werden. D.h. um die 135 USD herum liegt wegen Fibonacci der vermutete Notausstiegspunkt vieler internationaler Teilnehmer. Wahrscheinlich geht es dann in den zweistelligen Bereich. Unwahrscheinlich (jedoch nicht unmöglich) sind Preise unterhalb von 10 USD. Allerdings endet der Spuk spätestens um den 16. bis 19.02.2015 herum. Die stabileren Tendenzen sind nämlich bereits jetzt zu erkennen. Jedoch sind diese noch zu schwach, um den eigentlichen Kursrutsch aufhalten zu können. Je näher wir aber dem Boden kommen, desto fester werden die Widerstände und stärker die Buywalls. Je mehr Zeit vergeht, desto mehr Spekulanten, Neueinsteiger und "Visionäre der dritten Generation" springen (wieder) auf und wollen an dem niedrigen Einstiegspunkt mitverdienen. Die Nachrichtenlage wird besser werden und dementsprechend wird der Bitcoin sein Vertrauen zurückerhalten.
Korrigieren muss ich mich in punkto "schnelle Kurskorrektur": Die Bodenbildung wird dem Bitcoin sein Fundament zurückgeben und wahrscheinlich einen gemächlicheren Anstieg zeigen, als es sich einige Spekulanten erhoffen. Es werden allerdings vorerst zuviele mit einer blutigen Nase zurückbleiben, als dass der Kaufdruck jetzt wieder in Regionen um die 1000 USD reichen würde.

Deshalb rate ich hiermit allen mit schwachen Nerven: Entweder steigt innerhalb der nächsten 48 Stunden aus oder fahrt zwei Wochen in Urlaub ohne Internetanbindung und Bitcoin-News (oder bleibt zumindest dem Geschehen komplett fern).

Edith sagt: Warst zu langsam mit Deiner Antwort. Andere waren schneller und haben vor dir gepostet.

Versuchs mal mit MediathekView. Damit kann man es bequem auf Platte spiegeln. Allerdings ist das in Java geschrieben. Wer also Sicherheit möchte, muss es auf einem separaten System starten.

Das ist so nicht ganz richtig: Ich bin komplett aus Bitcoin raus. Für Experimente habe ich nicht mehr die Mittel. Umso entspannter ist es natürlich, das ganze vom Beckenrand aus zu beobachten. Es gibt einem einen viel freieren Blick auf das gesamte Geschehen. Wenn ich das nur früher gemacht hätte, dann ...

Ach, was solls? Hauptsache ich habe noch ein bisschen Spass dabei!

Wie bereits erwähnt: Der Kurs verhält sich gerade nicht logisch oder linear. So herum wird dann auch ein Schuh draus.

Meine "Vorhersagen" sind auch eher Spass am mitfiebern und weniger ernst gemeint (siehe auch meine Signatur). Wer darauf setzt, macht es in dem Wissen, dass auch ich statistisch gesehen nur in der Hälfte aller Fälle richtig liegen kann. Wer also meinen Worten glauben schenkt, macht das auf eigenes Risiko und ohne jegliche Garantien, dass das gutgehen wird.

Hast du in den letzten Wochen irgendwann erlebt, dass der Kurs nach irgendeiner Logik agieren würde?

Nichtsdestotrotz geht es jetzt erstmal aufwärts. Meiner Meinung nach solltet ihr euch aber nicht zusehr daran gewöhnen: In etwa zwei Tagen ist diese Zusatzvorstellung vorbei und der Bär erobert das Steuerrad zurück. Dann sehen wir eine Woche bis zehn Tage lang nur Drops, um dann in einer kurzen Wende stabile Aufwärtstendenzen zu haben.

Also Kotztüten bereit halten und Anschnallen: Das wird ungemütlich.



Jetzt bereue ich es, dass ich nicht mehr dabei bin.