PeWi

Sagen wir es so - wenn ich Musik höre (bzw gehört habe), dann als Hauptbeschäftigung. Musik als Berieselung/Hintergrund mag ich nicht - also diametral zu deiner Einstellung.

Denkfehler: Du kannst Gewinne ja nicht nur durch das Auszahlen in Fiat sichern, sondern auch durch Umtauschen und Parken in Stablecoins wie USDT, TUSD, PAX, ... Dadurch kannst du dir quasi beliebig viel Zeit für das Auszahlen nehmen.

Und ich höre nie Musik. (Obwohl ich klassische Musik mag und als Jungerwachsener vor 30 Jahren davon viel aus dem Radio aufgenommen und gehört hatte. Aber seit bestimmt 20 Jahren ...) Hat einer von euch auch mal Phasen, in denen ihn Musik nicht interessiert? Oder ist das für euch unvorstellbar ...?

Was ich noch nicht verstehe - warum sieht man auf der rechten Seite des Charts vier Verkäufe ohne entsprechende Käufe dazwischen? Sind die Sells dann nur Teilverkäufe gewesen?

Das kann IMHO nur mit Shorten funktionieren. Damit sind alle Ansätze (oder Bots) ohne raus.

War da nicht neulich was mit Coinomi? Sollte man vielleicht noch warten, bis Entwarnung gegeben wird?

Möchtest du dich heutzutage darauf verlassen, dass Altbestände auf immer und ewig verschont bleiben? Ich kann mir durchaus vorstellen, dass ein unendlicher Schutz für Altbestände irgendwann mal auf eine Übergangsfrist herunterkastriert wird. Und ob dann zu dieser Zeit die Kurse zum Realisieren der Steuerfreiheit passen? "Was man hat, das hat man."

DIese Argumentation verstehe ich nicht ganz. Wer Bitcoins nicht nur sammelt, sondern auch im Auge hat, "sie als Bitcoin zu verwenden", der muss ihnen doch eine wie auch immer geartete "Kaufkraft" oder "Tauschkraft" zumessen. Andernfalls "verwendet" man sie doch nicht, sondern schiebt sie bestenfalls von der einen Tasche in die andere?

Zum Hodln noch ein Gesichtspunkt: Ich neige Jokins Empfehlung zu, gelegentlich zu Hochs nach Ablauf der einjährigen Haltefrist seine Coins zu verkaufen, um die bis dahin entstandenen Gewinne "steuerfrei einzusacken". Wie man bei den Aktien gesehen hat, kann die Steuerfreiheit nach einem Jahr Haltefrist auch abgeschafft werden. Nicht, dass man als vieljähriger Hodler irgendwann bei einem späteren (Teil-) Verkauf doch Steuern zahlen muss. Lieber zwischendurch Kursgewinne steuerfrei sichern und dann - sollte es auch bei Kryptos zur Abschaffung kommen - nur noch auf die neuesten Kursgewinne Steuern zahlen müssen, aber alle alten steuerfrei behalten. (Und ggfs, wie Jokin vorgeschlagen hat, zusätzlich Steuerverluste erzeugen und geltend machen.)

Ist das nicht doppelt gemoppelt? Entweder die Hodler verkaufen steuerfrei im Dezember 2017 und sacken pro BTC steuerfreie Gewinne ein. (Die sie dann nicht für den sofortigen Rückkauf wieder ausgeben.) Oder sie kaufen im Dezember 2017 sofort wieder rück - die steuerfreien Gewinne sind damit wieder ausgegeben - und können im November 2018 durch Verkauf und Rückkauf je BTC 7000 EUR steuerwirksame Verluste ausweisen. Aber steuerfreie Gewinne von 10k einsacken UND steuerliche Verluste von 7k ausweisen - das funktioniert nicht. Oder habe ich einen Denkfehler?

Je benutzerfreundlicher, desto eingeschränkter die Möglichkeiten - wer nicht wie ein Lemming in den ausgetretenen Spuren von tausenden mitmarschieren will, der kommt mit diesen schönen Baukästen oder Frameworks nicht weit. Die Grundlagen erarbeitet man sich im Training und den Schliff im Wettkampf. Nach Kolibris Beschreibung sollte alles außer echtem Traden doch kostenlos sein?

Ich bin mir ziemlich sicher, dass teurere Quellen für historische Kurse auch Schnappschüsse der Orderbooks anbieten. Damit kannst du auch den Einfluss deiner Order auf den Preis simulieren. Ansonsten: Backtests sind wie Sparringspartner beim Training. Würdest du wirklich gegen den Endgegner ('Realität') antreten wollen, ohne deine Fähigkeiten zuvor an Sparringspartnern trainieren und verbessern zu können? Deine Argumentation läuft immer darauf hinaus: Wenn der Endgegner doch anders ist als das, was mir an Sparringspartnern zur Verfügung stehen würde, dann brauche ich doch überhaupt nicht trainieren?

Wenn das wirklich 500 Kryll pro Monat kostet, dann ist der Betrieb merklich teurer. Laut CMC ist ein Kryll derzeit $0.102108 USD wert.

Ist das nicht ein bisschen übertrieben? Wenn man von (s)einer Strategie überzeugt ist, heißt das doch erstmal, dass man sicher ist, dass sie auf Dauer merklich mehr Gewinne als Verluste macht? Und abhängig von den Charakteristika der Strategie kann man dann ggfs entscheiden, welchen Anteil seines Vermögens man drin stecken haben darf, damit einem zwischendurch so Verluste nicht das Genick brechen?

Eine andere Sichtweise auf Smart Money - Smart Money hätte deswegen recht, weil es aufgrund der Größe seiner Orders den Markt zwangsweise mitnehme: https://www.mr-market.de/warum-das-smart-money-mehr-gross-als-smart-ist/

Vernünftige Sprachen unterstützen das in ihrer Laufzeitumgebung, dann ist das ähnlich harmlos wie DB-Handling. Struktur braucht man überall, nicht nur bei den Daten, insofern ist das klar. Das kommt ganz auf das Problem und das Drumherum an. Wer sowieso dauernd mit DBs hantiert, wird DBs auch schon bei "kleinen" Problemen verwenden, und wer jahrzehntelange Übung hat, mit strukturierten Dateien zu hantieren, der benutzt u. U. auch bei "mittlerer" Problemgröße noch Dateien.

Wieso kommst du mit so 'nem abstrusen Vorschlag? Nur damit du "Abspeichern in Textdateien" als unsinnig abtun kannst? Etwas realistischer würde man das z.B. in einer CSV-Datei pro Coin speichern. Da passen dann jeweils ganz viele Kurse rein und brauchen vermutlich auch kaum mehr Platz als deine DB.

Prinzipiell ist das doch von der Sprache unabhängig? Wenn du Daten hast, die einen Botabsturz oder -neustart überstehen müssen, dann müssen sie auf Platte gespeichert werden. Ob als Textfile oder in einer Datenbank, hängt dann vom Umfang der Daten, was du mit ihnen machen willst und deinen Gepflogenheiten ab.

Aller drei Probleme bin ich mir bewusst. Dafür waren der C64, sein Basicinterpreter und das kommentierte Romlisting, in dem jeder einzelne Maschinenbefehl von Interpreter und C64-Betriebssystem kommentiert war, sehr lehrreich.

Treffend formuliert! Einen weiteren Punkt gegen Python habe ich oben noch vergessen: Sobald man Python nicht für sich auf seiner eigenen Hardware betreibt oder zentral als Webanwendung für Kunden, fallen einem die Deployment-Probleme von Python auf die Füsse. Python ist von Haus aus für die Verwendung als interpretierter Source gedacht. Will man den Quelltext nicht freigeben, weil es um eine kommerzielle Anwendung geht, die beim Kunden läuft, muss man das ganze irgendwie "richtig" kompilieren, damit man den Quelltext los wird. Exkurs: Das kompatibelste und stabilste scheint bisher Cython zu sein. Das hat aber auch seine Tücken, weil man für jede Version von Python und für jedes OS eine eigene Version kompilieren muss. Zusätzlich muss der Nutzer trotzdem Python und alle benötigten Module in der richtigen Version selber installieren, damit die Cython-Kompilate funktionieren. (Das fällt mir gerade bei Ubuntu 18.04 aufwärts und Python 3.6 bzw 3.7 auf die Füße ...) Fazit: Python hat durchaus seine Tücken und ist keineswegs für alle Anwendungsszenarien so problemlos, wie es in obigem Artikel erscheint.

Er hebt ja darauf ab, dass Entwicklungszeit das teuerste sei, und dass laut der zitierten Studie die Entwicklung mit Python nachweisbar schneller geht (nur noch von Perl übertroffen). Seine Grundthese, dass man Performance-Bottlenecks mit dickerer Hardware ausgleichen kann, stimmt sicherlich grundsätzlich. Trotzdem gehe ich mit dem Autor nur teilweise konform. Er denkt anscheinend hauptsächlich in normalen Anwendungen/Webanwendungen, in denen das wichtigste Geschwindigkeitskriterium die Reaktionszeit für den Benutzer ist, und bei denen man gut mittels Computerclustern parallelisieren kann (was DB und Weboberfläche betrifft). Und das gilt vor allem im professionellen Umfeld, in dem sowohl für die Entwicklungszeit als auch für Hardware direkte Kosten anfallen. Für "uns", soweit wir daheim in unserer Freizeit ebenfalls programmieren, gilt das aber nur eingeschränkt. Wenn ich weniger lange zum Entwickeln brauche, habe ich deswegen nicht mehr Geld für Hardware, weil ich meine freien Stunden nicht einfach monetarisieren kann. Zum anderen stoße ich bei meinem Bot durchaus an Geschwindigkeitsgrenzen aufgrund von Python, wenn viel zu verarbeiten oder zu berechnen ist. Python unterstützt Parallelisierung nicht soooo gut;normales Multithreading läuft "dank" GIL nur auf einem einzigen Kern (hilft also nichts für Berechnungen), und richtiges Multiprocessing hat natürlich getrennte Adressräume, was die gegenseitige Kommunikation aufwendiger macht und zusätzlich Zeit kostet, wenn man einiges an Datenmengen zwischen den Prozessen hin- und herschaufeln muss. Zusätzlich hat paralleles Arbeiten einiges an Haken und Ösen und ist schwieriger zu debuggen. Die Komplexität steigt merklich, wenn ich in meinem Programm die Parallelität selber programmieren und verwalten muss, und nicht einfach "gekapselt" nutzen kann, in dem ich z.B. eine DB-Abfrage einfach an einen Cluster statt einer einzelnen Datenbank senden kann. Fazit: Bei meinem eigenen Bot merke ich die Langsamkeit von Python schmerzlich, und ich kann sie nicht einfach durch dickere Hardware erschlagen.

Ein interessanter Artikel zu Python ... https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1

Nachtrag: In einem der früheren Beiträge hast du aufgelistet, dass zu den 100% Coins noch 25% ETH kommen. Damit ließ sich alles restliche berechnen. So komme ich auf einen Gewinn von 5,85%, wenn du deine Coins nach deiner angegebene Gewichtung gekauft und liegengelassen hättest. Mit dem Rebalancen durch den Bot kommst du auf 5,05% Gewinn (siehe Berechnung oben), also weniger. Meine Tabelle ist leider kein Muster an Klarheit, ich hoffe, ihr kommt damit trotzdem klar - man kauft Coins nach der anfänglichen Gewichtung (alles mit 'anfangs'), bekommt damit eine Coinzahl ('gleichbleibend') und kann damit berechnen, was diese Coins beim Liegenlassen heute Mittag ('jetzt') wert gewesen wären.

Um deinen Wertzuwachs oder -verlust für den Fall zu berechnen, dass du anfangs einmalig deine Coins gemäß deiner Gewichtung gekauft und stehen gelassen hättest, fehlen mir noch Zahlen. (Bei nochmaligen Lesen ist mir aufgefallen, dass eigentlich das dein angestrebtes Ziel war ... ) Entweder wieviel Prozent ETH du noch zusätzlich zu deinen ca. 100% Coins hattest, oder wieviel deine Coins in absoluten Zahlen waren, damit ich darüber den ETH-Anteil am Gesamtportfolio ausrechnen kann.

Meine Rechnung ist viel simpler - ohne Garantie auf formelle Richtigkeit. Ohne Bot hättest du 9,59 ETH als ETH behalten, mit Bot hast du jetzt 10,38 ETH in Coins. Folglich ist dein Gewinn 10,38 ETH * 134,72 USD/ETH - 9,59 ETH * 138,81 USD/ETH = 67,21 USD (entspricht 5,05%). (ETH-Preise von coinmarketcap um 12h des jeweiligen Tages.)