Jokin

Im Idealfall steigst Du nur mit einem Teil Deines Spielgeldes ein - den Rest behältst Du an der Seitenlinie und schiebst ein bisschen nach wenn der Kurs fällt. Bei steigendem Kus nimmst Du ein bisschen wieder raus.

Lade sie bei github runter und speicher sie einfach lokal. Ich hab sie lokal gespeichert. Da das Berechnungsprinzip eines PrivateKeys sch nicht so schnell ändern wird braucht es da auch kein Update. Nie. (sag niemals "nie", aber sollte sich das wirklich ändern, dann hätten andere Leute in der Bitcoin-Welt noch größere Sorgen als ich) Der Electrum-Seed ist ein wenig spezieller, daher habe ich Electrum meinen selbst erzeugten BIP39-Seed gegeben. Ich halte es für äußerst unwahrscheinlich, dass in bereits 15 Jahren mein Seed nicht mehr mit der lokal gespeicherten HTML-Seite in PrivateKeys umwandelbar ist. Zudem halte ich es für meine Pflicht, dass ich mein Vermögen in regelmäßigen Abständen umschichte. Dieses Umschichten erfolgt im Falle einer Verlustrealisierung innerhalb der 12-Monatesfrist und im Falle einer Gewinnrealisierung außerhalb der 12-Monatsfrist. Und natürlich nicht der komplette Bestand, sondern immer nur ein Teil des Bestandes. Da reicht es schon wenn man sein Vermögen auf 12 Töpfe aufteilt und monatlich aktiv wird. ... oder 4 Töpfe und quartalsweise. Oder was auch immer. Daher hat der Seed den Charme, dass man mit einem Seed gleich mal unendlich viele PrivateKeys verbuddeln kann und innerhalb dieser Wallet frei agieren kann.

Ich warte nur auf diejenigen, die im Nachhinein den Absturz vorhersahen oder den Bounce oder die SPS-Formation reinmalen ...

Lustiger Plan - kommt aus dem positiven Unendlichen und geht ins negative Unendliche. Ihr Bildermaler seid die Geilsten hier

Hmm, dann müsste ich die Platzierungen wieder in der Datenbank ablegen und das macht's recht kompliziert. Kleinere Coins dürften an sich nicht in die TOP20 geraten - und wenn, dann kommen die nicht innerhalb einer Stunde mehrere Plätze rauf und wieder runter. Und wenn das auch der Fall ist, dann würde ein Kauf eh nicht so schnell passieren, da der 24h-low-Wert so niedrig ist, dass die BUY-Order entsprechend weit weg ist. Weiterhin ist meine Hoffnung, dass der Coin bei Eintritt in die TOP-20 gekauft wird und beim Wandern nach oben nich sofort wieder verkauft wird sondern sich eine Art "Trailing" ergibt. Derzeit sehe ich das bei BNB - den bekomme ich in einem Bot gerade nicht nachgekauft, weil der Kurs so abnormal nach oben rennt. Im anderen Bot hingegen wird der nun stückweise verkauft - was ja im Sinne der Strategie ist. (die Bots müssten sich die eher untereinander zuschieben ... )

Exakt. Dann wird jemand feststellen (z.B. die Steuerfahndung), dass die Anschaffung bereits länger als ein Jahr zurück liegt und nicht steuerrelevant ist. Eigentlich nix anderes als wenn Du privat einen Oldtimer verkaufst und mehr Geld bekommst als Du bezahlt hast. Den gibt auch niemand in der Steuererklärung an. Wo steht das? Ganz im Gegenteil - wenn man in seiner Einkommensteuererklärung alle Erträge ungeachtet der 12 Monate als Gewinn ausweist, dann übernimmt das FA einfach die Angaben ohne jeden Trade selber zu prüfen ob nun die 12 Monate dazwischen liegen. Da sollte man wirklich sehr stark aufpassen und nur das steuerpflichtige Einkommen angeben. Sollten Zweifel seitens des FA bestehen, wird nachgefragt oder der Steuerbescheid ausgestellt und die Sache im Anschluss an die Steuerfahndung übergeben. (ich hab oft genug und lang genug 2017 mit FA und Steuerfahndung telefoniert)

Kannste machen 🙂

Dann sichere Deine Wallet.dat einfach woanders und installiere bitcoin core neu. Generell solltest Du Deine PrivateKeys bereits separat gesichert haben falls Dir Deine wallet.dat mal verloren geht. Diese PrivateKeys kannst Du in anderen Wallets, z.B. Electrum importieren und damit Deine Coins transferieren.

Kannste in die Anlage SO eintragen. Sobald der Beamte sieht, dass die Anschaffung mehr als 12 Monate her ist, überspringt er den Teil. Kannste Dir also auch gleich schenken. Ja, für Zweifelsfälle. Aber hier ist es doch absolut eindeutig.

Dazu schaut man sich den Quellcode einfach mal an. Es gibt genügend Leute, die das bei oben genannten Seiten bereits mehrfach getan haben.

Mit folgendem Gedanken beschäftige ich mich derzeit: - über worldcoinindex stündlich die Rangfolge der TOP 30-Coins (nach Marketcap) ermitteln - Ausrechnen wieviel Coins ins Portfolio genommen werden können damit 2%-Kursveränderungen zum Einstellen von Order reichen. - Wenn es denn 20 Coins sein dürfen, dann die TOP-20 heranziehen (ansonsten entsprechend weniger oder mehr) - Dynamisch den TOP-20-Coins prozentuale Werte zuweisen von ca. 10% für #1-Coin bis runter auf ca. 1% für #20-Coin - Coins #21 bis #30 werden auf 0% gesetzt => Damit würde ich mir sparen in der Config für jeden Coin eine prozentuale Verteilung statisch festzulegen. => Damit würden im Marketcap steigende Coins im Portfolio hinzugekauft => Damit würden im Marketcap fallende Coins aus dem Portfolio nach und nach rausgeschmissen => Damit würden #21-#30-Coins durch die "0%"-Setzung lange genug vom Bot rausverkauft werden ohne dass durch das Rausfallen aus den TOP20 der Coin in Vergessenheit geraten würde. Das sollte natürlich konfigurierbar sein - entweder man definiert die Coins selber manuell was man wie halten möchte (gerade bei kleinen Budgets wichtig) oder über ein config-Parameter holt sich der Bot die Rangfolge der Coins und balanciert dementsprechend das Portfolio aus. Was habe ich übersehen? Erzeuge ich dadurch zusätzliche Risiken? ... wobei das sicher zu etwas Unübersichtlichkeit führt. Auch muss natürlich geschaut werden, dass diese Coins auf der Exchange auch gegen die gegebene Währung handelbar sind. Hmm, Ideen das zu vereinfachen damit es leichter nachvollziehbar ist?

Hmm, also meines Wissens nach ist es bei Binance egal ob der Bot die Order erstellt oder man das manuell macht - die Höhe der Gebühren ist dieselbe. https://www.binance.com/en/fee/schedule => Wichtig ist, dass Du von vorn herein ein paar BNB im Account hast, denn dadurch reduzierst Du Deine Gebührenzahlungen um 25% => weitere Gebührenreduzierungen gelten für Highvolume-Trader. Mit meinem 0,55-ETH-Account bin ich gerade bei 0,18% des Tradevolumen, was ich für geringere Fees bräuchte. Ich denke, ab ca. 30 ETH dürfte sich das Tradingvolumen soweit erhöhen, dass es sich lohnt mehr als 50 BNB im Account zu halten und so günstigere Maker-Gebühren zu erhalten. (über kurz oder lang will ich das auch erreichen, aber dazu muss ich erstmal die prozentuale Verteilung der Coins dynamisch vom Rang abhängig machen - dazu später mal mehr ...) Da der Bot von sich aus den BUY-Kurs auf die Hälfte zwischen aktuellem und dem 24h-Low zu setzen, hab ich den einfach laufen lassen und gedacht "der macht dat schon". Momentan sehe ich sehr schön, wie IOTA und XLM massiv im Wert fallen, was sich nun auf den Gesamtportfoliowert recht mies auswirkt.

Ja, das ist korrekt. Der HODLer kann sinkenden Kursen leider nur zuschauen und nach 12 Monaten bleibt er auf dem Verlust sitzen ohne dass er steuerliche Gewinne gegenrechnen kann. Der TRADer kann ebenso mit Verlust dastehen, jedoch im günstigen Fall mit mehr ETH als der HODLer und dessen Verluste kann er gegen andere Gewinne verrechnen. ... im ungünstigen Fall hat er durch das Traden seinen Coinbestand reduziert und steht ärmer als der HODLer da, kann seine Verluste aber steuerlich geltend machen. Im Gewinnfall steht der HODLer erstmal besser da, denn seine Gewinne sind nach 12 Monaten steuerfrei. Der TRADer hingegen muss umso mehr Coins erwirtschaften um seiner Einkommensteuerpflicht nachzukommen. Schafft der Trader dies und kann die zusätzlichen Freecoins für das Generieren weiterer Gewinne bis zum Steuerbescheid nutzen, dann hat er die Nase nachhaltig vorn. Leider wird das recht schnell beliebig kompliziert und es lässt sich nicht genau ermitteln was das Beste ist ohne mit Sicherheit in die Zukunft zu schauen.

Können Ihr Euch bitte draußen vor der Tür kloppen und wenn Ihr fertig seid, kommt wieder rein und diskutiert wieder sachlich mit, ja? Danke.

Ok, inhaltlich ist die Prognose eingetreten. Zeitlich jedoch hab ich mich voll verhauen, denn heute früh bereits war es soweit. Erst ADA gekauft und 2 Stunden später hat der Bot dann BNB verkauft. NEO fällt derzeit wieder und das brachte den Bot ... .... um 12 Uhr auf die Idee NEO zu kaufen -> BUY-Order angelegt ... .... um 13 Uhr bemerkte der Bot, dass er zu viele NEO hatte, die BUY-Order war noch nicht erfüllt, also löschte er sie weg. .... um 14 Uhr passte ihm das Gleichgewicht wunderbar und er tat nix. Derzeit sind keine Order in diesem Bot offen. Falls NEO noch weiter fällt, wird NEO dann doch mal nachgekauft. Die rote Linie ist weiterhin leicht ansteigend und das bleibt hoffentlich so ...

Der Abschnitt 6.5 enthält einen Fehler, dort ermitteln wir die Reihenfolge in der die Coins später abgearbeitet werden - der Coin mit der größten Abweichung soll zuerst bearbeitet werden. Die Ermittlung ist schlichtweg falsch. Jedoch ist die Auswirkung auf die Strategie nicht schlimm - ob nun der eine Coin zuerst oder der andere zuerst bearbeitet wird, ist nicht wirklich kriegsentscheidend. Dennoch vorab hier die Korrektur des Abschnitts 6.5: // Abschnitt index.php 6.5: // Nun müssen wir mal ermitteln wie weit weg das IST vom Ziel ist, dazu bilden wir einfach einen Faktor aus SOLL (target_percentage) und IST (current_percentage) // Mit "deviation_percentage" führen wir einen Wert ein, der besagt: // >1 -> Ich habe zu viel davon, das muss weniger werden! ... also SELL-Order erstellen oder BUY-Order löschen // <1 -> Ich habe zu wenig davon, das muss mehr werden! ... also BUY-Order erstellen oder SELL-Order löschen // bei der Basiswährung machen wir das auch $__balanceBot_basecurrency['deviation_percentage'] = $__balanceBot_basecurrency['current_percentage'] / $__balanceBot_basecurrency['target_percentage']; // und für jeden Coin ... foreach ($__balanceBot_coins as $key => $array_coin){ $__balanceBot_coins[$key]['deviation_percentage'] = $__balanceBot_coins[$key]['current_percentage'] / $__balanceBot_coins[$key]['target_percentage']; // Hier bauen wir uns das Hilfsarray indem alle Coins absteigend nach ihrer Soll/Ist-Abweichung drin stehen werden. // Update 25.01.2019: "Korrektur Sortierung der Coins zum Abarbeiten": $array_coins_sorted_by_deviation[$key] = abs($__balanceBot_basecurrency['deviation_percentage'] - $__balanceBot_coins[$key]['deviation_percentage']); } // nun sortieren wir das Hilfsarray auch so, dass es brauchbar ist um den am heftigsten abweichenden Coin zuerst abzuarbeiten. arsort($array_coins_sorted_by_deviation); // siehe php manual "krsort()" .. behält den key assoziativer Arrays bei und sortiert absteigend. // echo "<pre> Und das ist die Sortierung der Coins: <br>"; // print_r($array_coins_sorted_by_deviation); // echo "</pre>";

AHAAA !!! // Abschnitt index.php 12.2.1.2.: [...] // die Menge ergibt sich aus dem Gesamt-Portfoliowert und dem trading_factor $amount = round(($sum_coin_value + $__balanceBot_basecurrency['virtual_balance']) * $__trading_factor/100 / $price,$__balanceBot_coins[$key]['minQtyPrecision']); // sollte meine Wunsch-Amount mehr sein als ich verfügbare Coins habe ... // ich aber immernoch mehr freie Coins als die Minimalmenge habe, dann verkaufe ich einfach mal alles $amount = min($amount, $__balanceBot_coins[$key]['free']); // Der Minimum-Betrag darf natürlich nicht unterschritten werden // das "+ $__balanceBot_coins[$key]['minQty']" ist dazu da um Abrundungen zu vermeiden $min_amount = round($__balanceBot_coins[$key]['minNotional'] / $price, $__balanceBot_coins[$key]['minQtyPrecision']) + $__balanceBot_coins[$key]['minQty']; if ($amount < $min_amount) $amount = $min_amount; [...] // Abschnitt index.php 12.2.2.2.: [...] // die Menge ergibt sich aus dem Gesamt-Portfoliowert und dem trading_factor $amount = round(($sum_coin_value + $__balanceBot_basecurrency['virtual_balance']) * $__trading_factor/100 / $price,$__balanceBot_coins[$key]['minQtyPrecision']); // sollte meine Wunsch-Amount mehr sein als ich verfügbare Basiswährung habe ... // ich aber immernoch mehr freie Coins als die Minimalmenge habe, dann verkaufe ich einfach mal alles $amount = min($amount, $__balanceBot_basecurrency['free']); // Der Minimum-Betrag darf natürlich nicht unterschritten werden // das "+ $__balanceBot_coins[$key]['minQty']" ist dazu da um Abrundungen zu vermeiden $min_amount = round($__balanceBot_coins[$key]['minNotional'] / $price, $__balanceBot_coins[$key]['minQtyPrecision']) + $__balanceBot_coins[$key]['minQty']; if ($amount < $min_amount) $amount = $min_amount; ... an diesen Stellen müsste das dann jeweils rein (einmal auf Coins bezogen und einmal auf die base-Currency). 1. Also erstmal Wunschmenge ermitteln. 2. danach die echten restlichen verfügbaren verkaufen falls Wunschmenge zu gering 3. und danach wieder auf Minimal-Menge erhöhen falls die mögliche Menge zu wenig ist. Dieser Fall tritt eigentlich nur auf, wenn man nicht gerade mit 0,1% des Portfoliowertes die Order erstellt sondern größere Werte wählt, also gern mal 5% oder 10%. In diesem Fall wird dann so viel wie möglich in die Order gepackt und notfalls alles versucht zu verkaufen. Dadurch verliert aber der BalanceBot ein bisschen seinen Sinn und Zweck, denn wenn ich dem BalanceBot vorgebe, er soll 20% BNB im Portfolio halten, dann sollte er nicht unbedingt versuchen sämtliche BNB zu verkaufen. Im nächsten Intervall stellt er fest "oh, hab keine BNB, also mal fix welche kaufen". Und danach hat er wieder zu viele BNB und versucht alle zu verkaufen - das würde zu einem schwingenden System führen. Das Ausbalancieren erfolgt möglich in kleinen Schritten. Will man es perfekt machen, dann kann man sich ja noch ausrechnen wie groß der Schritt sein muss um die Balance zu erreichen. Allerdings hängt die Balance ja auch davon ab ob die Order erfüllt wird und von den Order der anderen Coins - da sollte man sich nicht die Handlungsfähigkeit nehmen. Zudem ist das Ausbalancieren ein iterativer Prozess, der Zeit benötigt und mit dem man sich langsam an die Balance herantastet - wohl wissend und hoffend, dass steigende und fallende Kurse die Balance eh wieder "stören". (nach nun dreimal rein und wieder raus, werde ich diese Zeile drin lassen jedoch auskommentiert ...)

Das Problem ist nicht neu. Wieviel schweizer Nummernkonten gibt es wo die Besitzer schon längst verstorben sind und kein Erbe weiß von den Konten? Sorry, aber entweder man will sich von Banken kontrollieren lassen und bekommt den Luxus, dass sie das Vermögen an die Erben übertragen oder man ist eben seine eigene Bank, dann muss man sich eben auch selber drum kümmern, dass seine Coins an die Nachfahren gelangen. Ein versiegelter Umschlag beim Notar für Erbsachen reicht doch schon aus.

Lightning hat damit nix zu tun. An sich ist es egal wie alt eine Wallet-Software ist, die Privatekeys sollte sie exportieren können - da hat sich nix dran geändert.

Da hast Du natürlich recht - im Atomkraftwerk reichen 80% Genauigkeit nicht. Ich arbeite ohnehin viel mit Schätzungen und Annäherungen (Budgetplanung), da ändert sich im Planungsverlauf so viel, dass es sich nicht lohnt zu viel Genauigkeit reinzustecken 🙂 Dabei kann es passieren, dass nicht genug Coins frei sind um das Mindest-Volumen für eine Order zusammen zu bekommen. Daher muss ich zwei Schritte machen: 1. Ermittle das gewünschte Ordervolumen, die ich gern in die Order stecken will (ich hatte 0,1% des Gesamt-Portfoliowertes genommen) 2. Falls das gewünschte Ordervolumen unterhalb des Mindestvolumens liegt, dann nimm das Mindestvolumen. ... das ist leider der Pferdefuß im USDT-Markt, denn dort geht unter 10 USDT nix während im ETH-Markt mit mindestens 0,01 ETH was zu machen ist, was derzeit ca. 1 USD sind. (oder ich hab Dich falsch verstanden ...)

Probiere es einfach mal aus - steck das Ding an einen anderen PC und versuch mal darauf zuzugreifen ohne irgendwelche bekannten Passwörter oder eben den Seed zu benutzen. ... wenn Du den nach 3 Versuchen resettest ... egal, hast ja die Recovery Phrase und kannst das Ding wieder herstellen.

Wallet schließen und einfach in Electrum öffnen wird kaum klappen. Du musst erstmal die PrivateKeys bei Multibit exportieren (siehe https://multibit.org/help/v0.5/help_exportingPrivateKeys.html) und dann bei Electum importieren. Vorab solltest Du Deine Bitcoin-Adressen kennen auf denen Du noch Guthaben hast damit Du Dir nicht zu viel Arbeit mit leeren Adressen machst.

Ja, das ist richtig. Ebenfalls eine kleine Nachlässigkeit meinerseits. Ich verfolge meist das 80/20-Pareto-Prinzip, mache nix wirklich perfekt - ich habe den Anspruch an mich recht schnell anständige Ergebnisse vorzuweisen, die in aller Regel verbesserungswürdig sind. An der Stelle wird es nur durch einen enormen Zufall mal so sein, dass exakt dieselbe Menge gerade so eben frei ist wie auch gebraucht wird, daher eigentlich "wurscht" 🙂

So, nun hab ich auch die Diagramme dazu erzeugt. Zuerst mein Bot, der mit nur 0.55 ETH läuft, also weniger als 100 USD im Portfolio verwaltet: Zu sehen gibt es dort wie der Bot um den 22.01. herum BNB verkaufte, da BNB im Kurs stieg. Durch diesen Verkauf hatte er zu viele ETH und wollte NEO kaufen - das führte zum Schwingen, Order angelegt und direkt wieder gelöscht. Ca. am 23.01. fiel der BNB-Kurs soass der Bot dann anstatt Neo doch lieber BNB kaufte. Am 24.01. hat er nach gestiegenem BNB-Kurs BNB wieder verkauft und wollte doch wieder NEO kaufen. Im weiteren Verlauf stieg der NEO-Kurs und der Bot hat keinen Sinn mehr darin gesehen NEO zu kaufen. Seit dem 25.01. steigt BNB schon wieder. Es dauert aber noch recht lange bis ein Verkauf vorgenommen wird, da prozentual eh schon zu viel ETH da sind. Vermutlich wird erst ADA gekauft bevor BNB verkauft wird. Wie im vorherigen Beitrag geschrieben: Die rote Linie zeigt den Wert des Gesamt-Portfolios und der ist stetig steigend, was jedoch im Wesentlichen dem BNB-Kurs geschuldet ist. Und nun zu meinem öffentlichen Portfolio: Hier ist erstmal im Groben zu sehen, wie die 10 ETH stetig abnehmend auf die anderen Coins umverteilt werden. Im Kleineren Maßstab sieht das dann so aus: Auch hier von oben kommend der abnehmende ETH-Bestand und von unten kommend die Coin-Bestände. Da für alle Coins immer fleißig BUY-Order eingestellt wurden, diese aber nicht immer erfüllt wurden, haben sich die Bestände unterschiedlich entwickelt. Auch hier dem stetig steigenden BNB-Kurs zu verdanken, dass weit weniger BNB gekauft worden sind als andere Coins. Im oberen Bild habe ich die prozentuale Ziel-Verteilung eingezeichnet, dort soll sich das Portfolio am Ende sammeln. Da durch die 10 ETH das Portfolio groß genug ist um auch 1%-Kursunterschiede aktiv auszugleichen, erwarte ich, dass ab Anfang Februar alle Kurse in den Zielbereichen liegen werden und dort recht gut gehalten werden. Gleichzeitig erwarte ich, dass der BalanceBot permanent irgendwelche Order im Orderbuch offen haben wird, die auch immer mal wieder erfüllt werden und sich über die Differenz von niedrigem Kaufpreis und hohem Verkaufspreis "zwangsläufig" ein stetig steigender Gesamt-Portfoliowert ergeben wird. Dass derzeit der Gesamtportfoliowert steigt ist nicht der Verdienst des Balancebots sondern dem steigenden Kurswert von BNB geschuldet - gerade in der Anfangsphase des Ausbalancierens ist es wahrscheinlicher, dass erstmal der Gesamt-Portfoliowert sinkt als dass er steigt. Die Erwartungen sollten dementsprechend bei "ca. 0%" liegen und da tendenziell eher im "ca. -0%"-Bereich 😉 Sobald das Ganze einmal ausbalanciert ist, sollte sich mit jedem Trade ein positives Ergebnis einstellen ... außer bei extremen Kursveränderungen.

Oh, da ist mir echt noch was durchgerutscht ... 😞 Mach "$symbol" draus, wie im Abschnitt darüber: // Abschnitt index.php 12.2.1.2.: [... ] $message = " ... Erstelle Order: $side ".number_format($amount, $__balanceBot_coins[$key]['minQtyPrecision'], '.', '')." @ $price $symbol (aktueller Kurs: ".$__balanceBot_coins[$key]['price'].") "; update_messages($message); // Message in DB schreiben und ausgeben. Sorry, diese Nachlässigkeit geht auf meine Kappe - Auswirkungen auf den Programmcode hat das nicht, dadurch fehlt lediglich ein Teil in der Ausgabe. (Grund für den Fehler: Das ist Copy-Paste aus anderem Programmcode von meinem ersten Balance-Bot) Danke für den Hinweis, das ist auch noch in meinem aktuellen Code enthalten Nein, denn in der php.conf haben wir "NOTICE"-Fehler unterdrückt - ohne diese Unterdrückung würde es tatsächlich eine Notice-Meldung dazu geben. Das ist korrekt - es ist nicht "selbstlos", sondern eine Win-Win-Situation bei der beide Seiten gewinnen können. Zugleich versuche ich die Risiken für beide Seiten möglichst gering zu halten. Ich setze diesen Bot exakt mit demselben Code selber produktiv ein. Die Anpassungen daran werde ich von Zeit zu Zeit in einem Release veröffentlichen - da gehört auch der obige Bugfix mit rein.