PeWi

Mir sind die Vorzüge von Go durchaus bewusst. Das hat jetzt nichts mit Go zu tun - ich hadere nur gerne mit der großzügigen Einbindung und Nutzung vieler Bibliotheken, weil ich das Programmieren vor 35 Jahren auf einem Commodore C64 mit sagenhaften 64 KByte gelernt habe. Da hat man trotz Assembler mit jeden Bit gegeizt - das prägt einfach ...

Nachtrag: Gruselig ist der Umfang, den man benötigt, um den Bot um die Charts aufzupeppen. Quasi mehr Aufwand für die Erweiterung als für den ganzen "eigentlichen Bot". Ich weiß schon, warum ich mich bisher immer von Frontends ferngehalten habe ...

Lustig ist auch, dass nur Cointracking genannt wird, ein Tool, das eigentlich zum Tracken dient und nur als zusätzliches Anhängsel einen notdürftigen Steuerreport mit vielen Fehlern enthält, nicht aber CryptoTax, das sich - zu einem ähnlichen Preis wie euer EBook - auf das Erstellen eines Crypto-Steuerreports spezialisiert hat, sich auf die Beachtung der vielen Spezialitäten des deutschen Steuerrechts konzentriert und einen sehr guten kostenlosen Support nahezu 24/7 bietet - das wäre euer Konkurrent, gegen den ihr antreten müsset.

Super gemacht! Danke für deine Mühe und deine ausführliche Darstellung! Ähnliche Probleme werde ich demnächst auch lösen müssen, da kann ich das gut gebrauchen. Bisher war ich reiner Backend-Programmierer und habe um CSS/JS/... und alles Frontend-Gedöns einen weiten Bogen gemacht.

Vermutlich garnicht? Es geht ja nicht ums Momentum, sondern um die sozusagen statische Frage "wie ist der Unterschied zwischen Ist und Soll". Und abhängig davon werden Orders erzeugt oder gelöscht.

Dein Link verweist auf deine lokale Adresse http://192.168.1.23:5000/sharing/b5VCe7SFw, das kann nicht gehen.

Auch, wenn es keine Hodler gäbe - die Marketcap würde trotzdem nur stimmen, wenn alle Coins zum aktuellen Preis bewegt worden wären.

Mir leuchtet die Theorie ein, mir leuchten deine Erklärungen ein; mein Problem ist nur weiterhin der Punkt, dass du zur Monetarisierung des ganzen im Durchschnitt einen Unterschied von mehr als zweimal der Tradegebühr brauchst. Und soviel oder mehr gibt es doch nur, wenn genügend Masse beteiligt ist?

Vielen Dank für den Link - sowas hat mich schon länger interessiert!

Nebenbei: Diese Formulierung ist mir in nahezu identischen Worten letztes Jahr in irgendeiner Telegram-Gruppe schon mal über den Weg gelaufen.

Dann mal Butter bei die Fische - um wieviel Prozent bewegen die Delta-Orders der paar Hansel, die Jokins Bot nachgebaut haben, den Kurs von ETH, ADA, IOTA, NEO und Konsorten deiner Überschlagsrechnung nach? Hint: Nur, wenn der Kursbewegung die 0.4% überschreitet, hätte Jokin eine Chance, nicht draufzuzahlen. Nachtrag: Ich habe es für NEO/ETH mal nachgerechnet, weil das von den genannten Coins auf dem von Jokin empfohlenen ETH-Markt gerade das geringste Volumen besitzt. Fazit: Man müsste ca. 980 NEO im Wert von $5882 kaufen, um den Kurs um 0.4% anzuheben. Selbst, wenn man Jokins Empfehlung von 0.1% nicht folgt, sondern gleich Orders über 1% setzen würde, entspräche das einem Kapital von einer halben Million Dollar nur in NEO, also von mehreren Millionen in den Accounts insgesamt, die von Klonen von Jokins Balancebot betreut werden müssten. Um soviel Herdenvieh zusammenzubringen - wieviel Werbung und Aufwand müsste man da treiben? Mit anderen Worten - wer nach deiner Vorstellung abschöpfen möchte, muss das ganze in sehr viel größerem Massstab aufziehen.

Es ist schön, wenn Leute mitdenken und auch nicht offensichtliche Sachen erkennen. Trotzdem sollte man auch seine eigenen Theorien kritisch betrachten und quantitativ abklopfen, um nicht als Verschwörungstheoretiker zu enden. Rechne dir doch einmal aus, wie groß die kumulativen Orders etwa sein werden und vergleiche sie mit dem Orderbook der großen Coins, die Jokin verwendet. Wieviel Bruchteile eines Promille werden die den Kurs bewegen?

Von der Theorie hast du grundsätzlich natürlich recht. In der Praxis - wenn 20 Leute mit durchschnittlich ein paar hundert Euro mitmachen sollten, dann ist das viel für so 'nen kleinen Thread im Coinforum. (Jokin, kannst du irgendwie abschätzen, wieviele Leute mitmachen?) Da beim Rebalancen nur Orders über das Delta zwischen Soll und Ist erstellt werden, kannst du abschätzen, wie groß die geballte Marktmacht dieser Botarmee ist. 😉 Und wieviel Jokin dann tatsächlich abschöpfen könnte, wenn er es denn ausnutzen wollte? Das dürfte deutlich unterhalb der Gebühren liegen, die Binance einkassiert ...

Das ist Kritik an der falschen Stelle, weil Jokin in seinem Bot ja volumenreiche Coins auf einer großen Exchange benutzt. (Und mit der geplanten Erweiterung des CMC-Ranking genauso.) Und zusätzlich nur kleine Orders setzt, weil er pro Schritt ja nur einen Teil des Ungleichgewichts ausbalanziert. Da ist der Unterschied zwischen dem theoretischen Preis und dem Ausführungspreis vernachlässigbar. Problematisch an dem Konzept des Rebalancings finde ich eher, dass man damit keinen Schutz gegen Bärenmärkte hat und nahezu genauso reinrasselt wie bei Buy-and-Hold.

Über die API bekommst Du das nicht. Es gibt Webarchive, die Snapshots der Seite enthalten, da kann man sich zumindest mit annähern. Aber der Aufwand dürfte den Nutzen bei weitem übersteigen. Unter https://coinmarketcap.com/de/historical/ kann man zumindest einmal pro Woche das Coinranking nachschauen. Wenn ich tatsächlich für jede freie Stunde entsprechende Projekte an Land ziehen könnte, dann hättest du vollkommen recht. Aber ich arbeite daran, dass es irgendwann mal so funktioniert.

Es würde mich schon reizen, für deinen Balancebot ein Backtest-Script zu schreiben und das dann hier zum Herumspielen zur Verfügung zu stellen. Leider fehlt mir im Moment die freie Zeit dazu. Zudem nimmt dein Balancebot ständig an Komplexität zu, es wird also immer aufwendiger, ihn zu simulieren. Sobald die Coinranking-Systematik auch noch drin ist, wird es kaum mehr möglich sein; zumindest ist mir nichts bekannt, dass man von Coinmarketcap das Coinranking für die Vergangenheit zumindest tagesgenau bekommen kann. (Falls doch, würde ich mich über Hinweise freuen.)

Oh, ein Kenner 😉 BUGMPTORY

Um Schwingungen zu vermeiden, könnte man ein bisschen Hysterese einbauen: Bei z.B. 20 Plätzen für Coins - Coin erst abverkaufen, wenn er die Top 30 verlässt. Ersetzen dann durch den besten, noch nicht verwendeten aus den Top 20. (Bei 20 Plätzen und einem Coin, der nach unten durchrutscht, muss ja mindestens einer der Top 20 noch nicht im Portfolio sein.) Ggfs Top 25 statt Top 30, wenn weniger Hysterese reicht. Müsste man ggfs ausprobieren. Erfahrungsgemäß schwingen kleinere Coins stärker als große - insofern verschenkt man vermutlich merklich Rendite, wenn man die Coins so stark unterschiedlich gewichtet. Statt der Staffelung 10:1 nur 5:1 oder gar nur 3:1?

Ich wäre schon damit zufrieden, wenn ich es ungenau ermitteln könnte.

Da dieser Bot nicht gegen einen Stablecoin tradet, sondern gegen ETH, das genauso rauf und runter geht, sollte die rote Linie weiterhin leicht ansteigend bleiben; es sein denn, einer deiner Coins NEO, ADA oder BNB fängt zu schwächeln an. Leider garantiert das Rebalancen keine absoluten Gewinne, aber immerhin relative, d.h. gegenüber Buy-and-Hold der gleichen Coins sollte man auf Dauer immer besser (und das mit wachsendem Tendenz) dastehen.

Aus https://www.php-einfach.de/php-tutorial/php-array/foreach-schleife/ Die foreach-Schleife funktioniert ebenfalls bei assoziativen Arrays. Dort können wir sogar zusätzlich angeben, dass wir den Schlüssel des assoziativen Arrays ebenfalls als Variable abspeichern möchten: <?php $mitarbeiter = array("Klaus" => "Müller", "Bob" => "Baumeister"); foreach($mitarbeiter AS $vorname => $nachname) { echo "$vorname $nachname <br>"; } ?> Statt foreach($array AS $value) können wir (müssen aber nicht) bei assoziativen Arrays die foreach-Schleife als foreach($array AS $key => $value) schreiben. In dem Fall wird der Schlüssel des assoziativem Arrays in der Variable $key und der zugewiesene Wert in der Variable $value im Schleifenrumpf hinterlegt. Im obigen Fall ist also in der Variable $vorname der entsprechende Vorname, und in der Variable $nachname der entsprechende Nachname hinterlegt.

Das stimmt natürlich. Das kommt bei mir auf die Situation an. Wenn das eine für den Programmfluss wichtige Verzweigung ist, dann auf jeden Fall ausführlich. Wenn es eine unbedeutende Verzweigung in einer sowieso schon längeren Funktion ist, dann nehme ich gerne die Kurzform, weil mir dann die Übersicht über das ganze wichtiger ist.

Eben im Go-Playground ausprobiert - man darf's wenigstens einzeilig schreiben: if test { a = 1 } else { a = 2 }

Mit anderen Worten: Es schaut dir nicht auf die Finger, du musst selber aufpassen.

Sei mir nicht böse, aber das ist keine gute Idee. Jedesmal, wenn der API-Client auf Github verändert wird - seien es Bugfixes, Erweiterungen oder EInpflegen von API-Änderungen bei Binance - musst du deine Änderungen per Hand wieder nachziehen oder auf die neue Version verzichten. Behalte alle Konvertierungen in deinem Source, damit du beim API-Client jederzeit problemlos Updates verwenden kannst. JSON ist absichtlich ein Austauschformat des kleinsten Nenners, weil es dann auf jedem System und mit jeder Sprache funktioniert - um den Preis einer gewissen Unbequemlichkeit.