casiopaya

Hallo, ich muss auch diesen alten Beitrag rauskramen, da ich nach den ersten Aktionen meines Tradingsbots doch überrascht war. Neben den 0.4% Kaufs- bzw Verkaufsgebühren, die automatisch vom Zahlbetrag oder von der BTC Menge abgezogen werden, gibt es ja doch noch eine weitere Gebühr, die über das Fidor-Konto eingezogen wird: Käufergebühr BTCA-*** bzw Verkäufergebühr BTCA-*** Diese scheinen genau 0.1% des Handelsbetrags zu sein. Ich habe lange bei bitcoin.de nach einer Erklärung gesucht, aber dann bei Fidor gefunden: https://www.fidor.de/documents/PLVZ_Fidor_Retail.pdf Siehe Seite 10, 7.Kryptowährungshandel [Bitcoin.de Expresshandel] D.h. also neben den 0.4% bitcoin.de Gebühren gibts noch 0.1% Fidor-Gebühren. Toll. War das immer schon so oder ist das neu? Ich habe eigentlich bitcoin.de gewählt, da ich eine 100%ig automatisierte Lösung benötige, wie ich einfach BTC kaufen und verkaufen kann (über den "Umweg" FIAT...). D.h.. nichts mit manuell überweisen, bestätigen oder sonst was... Das Konstrukt bitcoin.de / Fidor ist das einzige dieser Form, das ich überhaupt gefunden habe. Trotzdem frag ich mich so langsam ob das eine gute Wahl war da ich der Meinung bin, dass 1% Gebühr (ein Kaufen->Verkaufen Workflow) doch ziemlich viel sind. Wenn mein Bot einen Schnitt von 0.5% anstrebt muss der BTC Kurs dazu um 1,5% steigen (natürlich nicht ganz genau, schon klar...) Oder ist das bei anderen vergleichbaren Plattformen auch so? Gibt es eine derart 100% automatisierbare Lösung wie den Expresshandel bei Bitcoin.de überhaupt wo anders? Danke + Grüße Casiopaya

Jup, bekomme einen 500 zurück. Seit ca 14:55.

Hallo! leider nein Da es ohne end_datetime funktioniert, und das eindeutig der erste parameter ist ("e") kann ich beides ausschließen Irgendwie verstehe ich euch aber so, dass bei euch ein CREATEORDER mit end_datetime funktioniert? Das haut mich echt um 🙂 Das Problem bei Datumsangaben habe ich übrigens nur bei POST. GET (z.b. showMyTrades mit date_start) funktioniert auch bei mir.

Hallo Peter, leider funktioniert es auch mit Leerzeichen statt "T" nicht, selber Fehler. Grüße Casiopaya

Hallo, ich krame diesen alten Beitrag mal raus, da ich mit der aktuellste API version ebenfalls dieses Problem habe. CreateOrder funktioniert ohne end_datetime einwandfrei, mit end_datetime kommt Invalid Signature. So wie ich diesen Beitrag hier lese wurde dazu nie eine Lösung gefunden? Aus meiner Sicht ist das ein Bug, denn auch ich halte mich komplett an die Beschreibung der API Doku: 1. Ich baue den Parameterstring zusammen, die Werte werden dabei einzeln URL encoded, also z.b. end_datetime=2020-08-28T23%3a00%3a00%2b02%3a00&max_amount_currency_to_trade=0.00629844&min_amount_currency_to_trade=0.00629844&price=9526.17&type=buy 2. Ich sende alle post Parameter als x-www-form-urlencoded, das Bitcoin Api Log sagt: POST-Parameter: { "end_datetime":"2020-08-28T23:00:00+02:00", "max_amount_currency_to_trade":"0.00629844", "min_amount_currency_to_trade":"0.00629844", "price":"9526.17", "type":"buy" } Body: { "errors":[ { "message":"Invalid signature", "code":5 } ], "credits":14 } Da das ganze ohne end_datetime funktioniert, muss also hier der Fehler liegen. Lesen Leute von bitcoin.de dieses Forum, kann das wirklich sein, dass dieser bug seit > 2 Jahren vorhanden ist? Danke + Grüße Casiopaya

>> Hier ist zumindest der Fehler drin, dass du den MD5-Wert eines Leerstrings (d41d8cd98f00b204e9800998ecf8427e) nutzt, obwohl du den MD5 über deinen URL-Parameter "type=buy" (44af1bc3841a162a58d6618329ac6c01) hättest errechnen müssen. Die Doku sagt im Prinzip folgendes: Der MD5 Hash wird nur über die POST parameter gemacht. Im Falle von GET gibt es die nicht, TROTZDEM muss man dann den MD5 Hash "über die POST Parameter machen", was bedeutet, über den leeren String. Deshalb ist der hash die obere Konstante. Über die Sinnhaftigkeit darf da wie gesagt durchaus diskutiert werden. Ich kann mir nur vorstellen, dass bitcoin.de das aus PErformancegründen macht, sozusagen um keine Fälle unterscheiden zu müssen. >> Signaturen sind in der Regel nicht deterministisch, daher kann man sie nicht vergleichen. Mein Vorschlag klappt natürlich nur bei deterministischen Verfahren, aber sämtliche von bitcoin.de in diesem Prozess genutzen Hashverfahren sind dies. Ehrlich gesagt sind mir nichtdeterministische Signaturen neu, aber man lernt ja nie aus.

Der Punkt geht an dich 🙂 Ich entwickle gerne im Cleanroom, zumindest solche Dinge wie API Clients. Das zwingt einen, die API wirklich zu verstehen und kennenzulernen. Aber ja, jetzt wirds wohl Zeit mal den einen oder anderen Test zu fahren. Bei der Trade_Id bin ich wirklich gespannt. Alles in allem ist die Doku nicht schlecht, aber durchaus an vielen Stellen verbesserungsfähig.

Ok das ist interessant! In der Doku steht davon nichts. Nur new_order_id_for_remaining_amount, welches ja die ID einer neuen Order ist, sofern bei eine Restmenge automatisch eine neue Order angelegt wurde.

Eine Frage dazu habe ich doch noch. Wenn jemand meine Order traded, verschwindet die aus showMyOrders und wird in showMyTrades zurückgegeben. Aber es gilt ja nicht order_id == trade_id, sondern trade_id ist eine neue ID. Wie also kann ich einen Trade einer Order zuweisen? Alle meine Orders und Trades werden in eine DB repliziert, daher kommt die Frage. Danke

Einen anderen Anhaltspunkt gibt es erstmal nicht. Eventuell kannst du dir doch mal den Code von github runterladen, den ans Laufen bringen und dann vergleichen, was dein code und der github code an Signatur produziert. Leider hat bitcoin.de keine Beispiele gelistet anhand deren man die eigene Implementierung verifizieren könnte, das hätte ich anfangs auch gebraucht.

>> für meineOrderbookabfrage nicht auch einen Kauf einstellen kann Im Prinzip ist das der Grund ja. die Sigantur ist für jede Nachricht eine eigene. Du sendest <NACHRICHT><SIGNATUR>. Die Nachricht ist unverschlüsselt (mal von TLS bei Header+Body abgesehen...), die Signatur "verschlüsselt" deine Nachricht noch einmal mit dem PRIVATE key und macht einen kurzen Hash daraus. Der Gegenüber kann mit dem zugehörigen PUBLIC key anhand von <SIGNATUR> verifizieren, dass <NACHRICHT> korrekt und nicht abgeändert ist. Das ganze basiert darauf, dass nur du den PRIVATE key hast. Selbes Prinzip gibts bei Signierten Emails oder PDFs mit qualifizierten Signaturen.

Hallo >> warum ich die ganzen Infos zu dem Link mit in den hmac-code einfließen lasse Du signierst damit deinen Call. Damit kann die Gegenstelle verifizieren, dass der von dir kommt (bzw. von jemandem, der deinen PRIVATEKEY hat, was nur du sein solltest). >> hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ get_parameter_url_encoded_query_string Da fehlt doch im Falle von GET das "#d41d8cd98f00b204e9800998ecf8427e" als "md5 hash über die nicht vorhandenen POST parameter" (hier stellt sich tatsächlich die Frage nach der Sinnhaftigkeit...) >> was der Header bei dem API-Call ist Der HTTP Standard definiert das so. 1. Methode (GET, POST, PUT etc), 2. URL (die Zieladresse), 3. Header (Key-Value-Paare) und 4. Body (im Prinzip ein Bytearray, es gibt verschiedene Unterformate wie man einen Body mit welchem Inhalt verschicken kann.) >> Mit dem v4 stoße ich aber auf einen 400-Error Was kommt denn als Body zurück? Da ich nicht regelmäßig mit Python arbeite kann ich auf die schnelle nicht beurteilen, ob die h.* aufrufe korrekt sind. Grüße casiopaya

Vielen Dank!

Und was passiert, wenn die verbleibende Order ein geringeres Volumen als 60 Euro (BTC x Kurs) hätte? Der Kurs ist dann wirklich immer noch der selbe, also kann es über diesen Weg tatsächlich Order mit Volumen < 60€ geben?

Ich danke Dir für deine Antworten! Gibt es denn eine Maximalanzahl an Orders, die man gleichzeitig offen habe darf oder ist auch das unbegrenzt?