Jump to content

Empfohlene Beiträge

Am 15.2.2018 um 19:39 schrieb burschujez:

Auszahlungslimit erhöhen, spricht diesen an den stetig steigenden Bitcoin Kurs anpassen.

Hatte ich im Dezember 2017 hier schon mal angeregt (s.14 in diesem Thread), zu Zeiten der Rekordkurse.

keine Reaktion von bitcoin.de, damals.  Hätte wohl nicht alternativ die Umbenennung in "millibitcoin.de" vorschlagen sollen... 😉

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 2 Stunden schrieb wwurst:

Hatte ich im Dezember 2017 hier schon mal angeregt (s.14 in diesem Thread), zu Zeiten der Rekordkurse.

keine Reaktion von bitcoin.de, damals.  Hätte wohl nicht alternativ die Umbenennung in "millibitcoin.de" vorschlagen sollen... 😉

 

Die 150k pro Tag? Reicht mir erst Mal. Wir sprechen uns nächstes Jahr aber wieder, wenn McAfee am Kurs schraubt.. ;)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Wir hatten schonmal darüber gesprochen, dass die Reservierung von Bankguthaben und die prozentuale Verteilung extrem unflexibel ist. Derzeit sind folgende Szenarien nicht möglich:

  • Man reserviere 1000€ und lege 3 Kaufanfragen zu BTC, ETH und BCH an mit jeweils 1000€. Die erste durchgeführte Order wird den reservierten Betrag erhalten, alle anderen fallen danach auf Zahlung per Überweisung zurück.
  • Es soll immer das maximale Guthaben von Fidor als Reservierung vorliegen.

Nun kommt es aber zur nächsten Umständlichkeit, und hier würde ich mir wirklich Verbesserung wünschen, wenn man an dem Reservierungsmodell festhalten möchte:

  • Man reserviere 3000€, und verteile es mit 34% auf BTC, 33% auf ETH und 33% auf BCH. Man erstelle 3 Kaufanfragen für BTC, ETH und BCH mit jeweils 1000€. Geht man nun ins Wochenende und ETH kommt zum Zug, dann fallen direkt die anderen beiden Orders auf Banküberweisung zurück, weil 33% nicht mehr ausreichen. Das erwartete Vorgehen wäre aber vielmehr, wenn die 3000€ Reservierung angepackt werden und verkleinert werden, dann sollen die Anteile auch dynamisch angepasst werden, d.h. nach dem vollen Verkauf der 33% ETH sollen die Anteile auf 50% BTC und 50% BCH verteilt werden, so dass die bestehenden Kaufanfragen mit der übrigen Reservierung auch weiterhin funktionieren, ohne dass man sich erneut an die Verteilung der Prozente machen muss.

Ist man mit 3 Orders und der Reservierung nämlich im Wochenende, und würde ein Dropdown eine weitere Order triggern, dann würde diese auf die Überweisung warten und fehlschlagen, wenn man innerhalb eines Tages nicht reagieren kann.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Einfachere Lösung für all Eure Probleme:

Das System der Reservierung bleibt unangetastet.

Jedoch folgende Systematik umsetzen:

Wenn ein User Buy-Order in verschiedenen Orderbüchern als Expresskauf-Order stehen hat, dann bleiben diese dauerhaft als Expresskauf-Order stehen solange keine neue Reservierung vorgenommen wird.

Es bleibt also der Expresskauf-Status einer Order bestehen, wenn er einmal vergeben wurde.

Der Expresskauf-Status wird ausschließlich im Falle einer Aufhebung der Reservierung zurück gesetzt.

Neue Kauforder, die nicht mit dem reservierten Guthaben erstellt werden können, sind SEPA-Order, die alten Order bleiben Expresskauf-Order.

 

Auf diese Weise wird kein Käufer davon überrascht, dass er eine plötzliche Zahlungsaufforderung erhält während er am Wochenende in einem Funkloch Urlaub macht.

-> Die Kundenzufriedenheit erhöht sich und zeitgleich das Handelsvolumen und damit die Gebühreneinnahmen für bitcoin.de

@Christoph Bergmann ... vielleicht magst Du die Grundidee bei Euch im Team diskutieren? Technisch dürfte der Umsetzungsaufwand recht gering sein - einfach Flag belassen, wenn es einmal gesetzt wurde.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo, ich gebe es weiter.

Verstehe aber nicht, wie die Express-Order bestehen bleiben soll, wenn die Reservierung ausgelaufen ist. Das wäre dann ja ein totes Angebot im Orderbook ... ich fürchte, wir haben das am Anfang alles schon mal in alle Richtungen diskutiert, auch dieses Szenario.

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 10 Minuten schrieb Christoph Bergmann:

Hallo, ich gebe es weiter.

Verstehe aber nicht, wie die Express-Order bestehen bleiben soll, wenn die Reservierung ausgelaufen ist. Das wäre dann ja ein totes Angebot im Orderbook ... ich fürchte, wir haben das am Anfang alles schon mal in alle Richtungen diskutiert, auch dieses Szenario.

 

Die Reservierung ist nicht ausgelaufen, schau mal das Beispiel:

- 9.000 Euro werden reserviert
- Verteilung des Guthabens zu je 33% auf BTC, BCH und ETH
- Es werden 3 Kauf-Order angelegt jeweils 3.000 Euro BTC, BCH und ETH

Nun wird die Kauforder BTC bedient, das reservierte Guthaben beträgt nun noch 6.000 Euro

IST
- Die 6.000 Euro werden erneut im Split auf die drei Währungen aufgeteilt
- Nun stehen jeweils 2.000 Euro zur Verfügung
- Da die BCH und ETH-Order nicht mehr mit dem Guthaben bedienbar sind, werden sie zu SEPA-Order obwohl ausreichend Guthaben reserviert wurde

SOLL
- die bestehenden Expresskauf-Order zu je 3.000 Euro bleiben im BCH- und ETH-Orderbuch als Expressorder stehen weil das reservierte Guthaben immernoch ausreichend ist.

 

Ich würde es sogar als "Bugbehebung" bezeichnen, denn es kann ja nur ein Fehler in der Software sein, dass das Guthaben, welches für eine Expresskauf-Order ausreichend war auf einmal ohne weiteres Zutun des Users nicht mehr ausreicht.

Und zweifelsfrei reichen 6.000 Euro Reservierung zum Bedienen von zwei Expresskauf-Order zu je 3.000 Euro und es besteht kein Grund diese auf SEPA zurück fallen zu lassen.

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 26 Minuten schrieb Christoph Bergmann:

Hallo, ich gebe es weiter.

Verstehe aber nicht, wie die Express-Order bestehen bleiben soll, wenn die Reservierung ausgelaufen ist. Das wäre dann ja ein totes Angebot im Orderbook ... ich fürchte, wir haben das am Anfang alles schon mal in alle Richtungen diskutiert, auch dieses Szenario.

 

bitte genauer lesen und ja wir haben das Problem schonmal ausführlich diskutiert. Aber für dich nochmal kurze Zusammenfassung (eig genau das was mssm im zweiten Teil schreibt) deines Missverständisses:
1) 2000€ sind reserviert.
2) Man stellt eine 50:50 Verteilung auf BTC und ETH ein -> aktuell wären 1000€ für BTC und 1000€ für ETH möglich.
3) Man stellt eben solche Kauforders zu je 1000€ Wert ein, beide werden als Expressorder eingetragen.
4) Jemand nimmt eine der beiden Kauforders an, insg insg also nur noch 1000€ reserviert.
5) Da aber eine 50:50 Verteilung gewünscht wird, verteilt bitcoin.de das Guthaben jetzt neu und es sind nun 500€ für BTC und 500€ für ETH reserviert.
6) Daraus folgt die eine noch offene Order über 1000€ wird nun überraschend in eine SEPA Order umgewandelt.
Und genau das ist das Problem. Es hat nichts mit dem Auslaufen einer Reservierung zu tun, wie du schreibst.

Allerdings hat so eine prozentuale Verteilung auch diverse Vorteile, weshalb es auch nicht gut wäre sie ersatzlos durch was völlig anderes zu ersetzen. Ich hatte da mal die Idee gehabt, dass man alternativ zur prozentualsen Verteilung bei jeder Reservation absolute Beträge definiert, statt prozentual. Das muss dann halt jedesmal neu gemacht werden, ist aber für manuelle User sicher kein Problem. Für Bots ist die automatische prozentuale Verteilung oftmals besser (außer es gibt nen API Call um die absolute Verteilug zu setzen).

Jokins Vorschlag klingt allerdings auch sehr gut. Allerdings gäbe es hier noch folgende Wechselwirkung (vllt noch mehr die mir grad nicht einfallen):
Wenn ich nur 2000€ für BTC reserviert habe und nun 2 Orders a 1500€ in BTC (hier also nur eine Währung) erstelle, dann wird soweit ich weiß aktuell diejenige eine Expressorder, welche sich höher im Orderbuch befindet. Hier gibt es also einen weitren Mechanismus, welcher einmal gesetzte Expressorders in SEPA umwandelt zugunsten einer potentiell besseren Order.
Allerdings halte ich es auch für sinnvoller dieses ganze Management dem User zu überlassen und nichts ohne sein zutun einfach so zu ändern. Dh in diesem Wechselwirkungsfall sollte die zuerst platzierte Order einfach weiterhin eine Expressorder bleiben. Und wünscht man sich, dass die andere Order Express wird, muss die erste halt erst gecancelt werden. (oooder man fügt bei bitcoin.de hinzu, dass orders bearbeitet werden können, man also selbst den Express-status hinzufügen/wegnehmen kann).

Ich denke man sieht, dass vermutlich jede Lösung noch diverse Rattenschwänze hat. Ich denke aber dennoch, dass eine Lösung her muss, die sowohl automatische als auch manuelle Trader unterstützt.

Und ganz wichtig:
Bei einer Änderung bitte informieren!!!

Ich hab noch immer keine offizielle Information über die veränderten Credits bekommen, das ist ungeheurlich so eine schwerwiegende Änderung ohne zumindest eine Information per Mail an alle API Nutzer!

bearbeitet von Serpens66
  • Thanks 1
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 2 Stunden schrieb Serpens66:

Wenn ich nur 2000€ für BTC reserviert habe und nun 2 Orders a 1500€ in BTC (hier also nur eine Währung) erstelle, dann wird soweit ich weiß aktuell diejenige eine Expressorder, welche sich höher im Orderbuch befindet. Hier gibt es also einen weitren Mechanismus, welcher einmal gesetzte Expressorders in SEPA umwandelt zugunsten einer potentiell besseren Order.

Korrekt, aber das wäre ein separater Fall, der kann ja weiterhin so gehandhabt werden wie heute.

Expressorder, die als Expressorder angelegt werden, bleiben eine Expressorder solange der User nicht seine Reservierung aufhebt (auch das Erneuern ist immer erst eine "Aufhebung")

Ich greife Dein Beispiel auf:

Reservierung über 4.000 Euro und zu 50% auf BTC und 50% auf ETH verteilt.

1. Order: Kauf 1.500 Euro BTC @ 6.700 Euro/BTC (wird Expressorder, weil 2.000 Euro reichen)
2. Order: Kauf 1.500 Euro BTC @ 6.500 Euro/BTC (wird SEPA-Order)
3. Order: Kauf 2.000 Euro ETH (wird Expressorder)

Fall 1: Wird nun die 1.500-Euro-BTC-Order @ 6.700 Euro angenommen, dann muss die ETH-Order zwingend als "Express-Order" stehen bleiben, denn sie wurde ja als Expressorder angelegt. Die zweite BTC-Order bleibt somit eine SEPA-Order.

Fall 2: Wird die die 1.500-Euro-BTC-Order nur mit 500 Euro bedient und diese Order so angelegt wurde, dass der Restwert nicht neu eingestellt wird, dann bleiben weiterhin 1.500 Euro freies Guthaben über und die zweite Order "könnte" zur Expressorder werden .... aber auch hier bin ich absolut bei Serpens: Die Order wurde als SEPA-Order angelegt und sollte auch eine solche bleiben - denn auch das kann ja eine Strategie von Bot-Tradern sein ... auch wenn das mit Aufwand und Handarbeit verbunden ist.

Ich bleibe also dabei: Order, die als Expressorder angelegt wurden sollten es auch bleiben solange die Reservierung nicht aufgehoben wird. 🙂

Da bitcoin.de in der Vergangenheit schon die ein oder andere Idee von mir umgesetzt hatte, hoffe ich auch hier auf Umsetzung, das würde mir mein Leben auch einfacher machen und etwas mehr Orderbuchfüllung reinbringen 🙂 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ach ja, das Thema hatten wir schon mal ausgiebig. Ich glaube, darüber haben wir intensiv diskutiert. Wie ihr ja auch schreibt, haben alle Varianten ihre Vor- und Nachteile. Ich leite den Thread aber mal weiter an die Technik, eventuell können die ausgereifteren Vorschläge sowie die gesammelten Daten etwas bewegen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Am 21.5.2019 um 16:51 schrieb Jokin:

SOLL

- die bestehenden Expresskauf-Order zu je 3.000 Euro bleiben im BCH- und ETH-Orderbuch als Expressorder stehen weil das reservierte Guthaben immernoch ausreichend ist. 

Das Ergebnis würde meinem Ansatz entsprechen, ich verstehe aber auch nicht, wie die Expressorder stehen bleiben soll, wenn sich das Guthaben ändert. Ich vermute, dass du die Verteilung der Reservierung nicht in %, sondern in EUR machen möchtest. Das wäre natürlich auch eine Möglichkeit, wobei man dann wieder die Rechnerei hat, dass man am Ende auf die Gesamtsumme kommt. Ich fände ein Widget mit Schiebereglern gut, wo man auf einer Achse nur die Verteilung prozentual verschiebt, am Ende aber immer auf der Gesamten Achse die 100% hat.

In jedem Fall müsste man bei der Verteilung ebenso vorgehen wie bei der Gesamtreservierung, und nicht nur die Gesamtreservierung, sondern auch die Anteile nach jeder Orderausführung anpassen. Wird von deinen 9000€ Reservierung eine BTC-Order von 3060€ verbraucht, dann wird die Reservierung auf den Restbetrag von 5940€ angepasst. Analog dazu müsste man die Verteilung von 34%,33%,33% (3x33% wären nicht 100) ebenfalls berücksichtigen, dass die 34% BTC verbraucht sind und die restlichen Anteile neu verteilt werden auf 50%,50%.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 5 Minuten schrieb mssm:

In jedem Fall müsste man bei der Verteilung ebenso vorgehen wie bei der Gesamtreservierung, und nicht nur die Gesamtreservierung, sondern auch die Anteile nach jeder Orderausführung anpassen. Wird von deinen 9000€ Reservierung eine BTC-Order von 3060€ verbraucht, dann wird die Reservierung auf den Restbetrag von 5940€ angepasst. Analog dazu müsste man die Verteilung von 34%,33%,33% (3x33% wären nicht 100) ebenfalls berücksichtigen, dass die 34% BTC verbraucht sind und die restlichen Anteile neu verteilt werden auf 50%,50%.

Au weia - das wäre der Usability-Super-GAU!

Auf gar keinen Fall sollen manuell vorgenommene Einstellungswerte automatisch geändert werden. Das verwirrt die User unnötig und ist am Ende für niemanden mehr nachvollziehbar.

vor 6 Minuten schrieb mssm:

Ich fände ein Widget mit Schiebereglern gut, wo man auf einer Achse nur die Verteilung prozentual verschiebt, am Ende aber immer auf der Gesamten Achse die 100% hat.

Der nächste Usability-Super-GAU!

Spiel das gedanklich durch - wenn Du den BTC-Schieberegler in Richtung 100% schiebst, dann wandern alle anderen Schieberegler nach unten. Nun schiebst Du einen anderen Regler in Richtung 100% und Dein eben eingestellter BTC-Wert reduziert sich.
Auch hier: Manuell vorgenommene Einstellungen sollen sich nicht automatisch verändern.

vor 8 Minuten schrieb mssm:

ich verstehe aber auch nicht, wie die Expressorder stehen bleiben soll, wenn sich das Guthaben ändert. Ich vermute, dass du die Verteilung der Reservierung nicht in %, sondern in EUR machen möchtest.

Falsch gedacht und falsch vermutet.

Wenn Du in der Lage warst mit einem Guthaben von 9.000 Euro in drei Orderbüchern jeweils Express-Kauforder zu 3.000 Euro anzulegen, dann ist es das Normalste der Welt, dass auch nach dem Kauf in einem Orderbuch die anderen Order weiterhin stehen bleiben - für die anderen beiden 3.000-Euro-Order stehen weiterhin 6.000 Euro zur Verfügung.

Warum also sollten diese in den SEPA-Modus gesetzt werden?
Die prozentuale Aufteilung sollte nur Relevanz haben wenn neue Kauf-Order eingestellt werden - besser wäre die gänzliche Abschaffung der prozentualen Aufteilung, sie ist aber wohl von irgendeinem Regulator so vorgegeben worden. Das ist sicher nicht der Wunsch der Bitcoin.de-Entwickler gewesen dies so umzusetzen.

Auch hier: Wenn ich etwas "manuell" einstelle, dann darf das nicht so einfach "automatisch" geändert werden. Das muss so stehen bleiben bis ich eine neue manuelle Änderung vornehme.

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Wenn ich statt Schiebereglern nur die Prozentzahlen editiere, muss ich dasselbe machen, denn nur die Summe von 100% wird erlaubt. Das Argument zählt also nicht.

Warum liege ich damit falsch, dass deine Reservierung auf € statt % basiert? Du sagst ja sogar, dass deine Express-Order von 3000€ stehenbleibt. Das bedeutet, dass deine Reservierung von 3000€ stehenbleibt. Wie ich sagte, wäre es eine Lösung, die Reservierung in € zu formulieren statt in %. Dann könnte man sie einfach unverändert lassen. Implizit ändert sich natürlich die prozentuale Verteilung, wenn deine 3000€ Reservierung stehen bleibt, die Gesamt-Reservierung aber kleiner wird.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 25 Minuten schrieb mssm:

Wenn ich statt Schiebereglern nur die Prozentzahlen editiere, muss ich dasselbe machen, denn nur die Summe von 100% wird erlaubt. Das Argument zählt also nicht.

Indem Du die Prozentzahl bei Bitcoin um "10" erhöhst, ist es Deine eigene Entscheidung ob Du dann bei BCH "10" abziehst oder bei ETH "10" abziehst oder jeweils eine andere Verteilung vornimmst.

Deine manuelle Eingabe wird nicht durch eine automatische Anpassung übersteuert.

Das Argument zählt also doch 🙂

vor 27 Minuten schrieb mssm:

Warum liege ich damit falsch, dass deine Reservierung auf € statt % basiert? Du sagst ja sogar, dass deine Express-Order von 3000€ stehenbleibt. Das bedeutet, dass deine Reservierung von 3000€ stehenbleibt. Wie ich sagte, wäre es eine Lösung, die Reservierung in € zu formulieren statt in %. Dann könnte man sie einfach unverändert lassen. Implizit ändert sich natürlich die prozentuale Verteilung, wenn deine 3000€ Reservierung stehen bleibt, die Gesamt-Reservierung aber kleiner wird.

Die "Reservierung" basiert nicht auf "Euro", sie basiert darauf, dass das einmal reservierte Verhältnis in Euros umgerechnet und eingefroren wird bis zu einer erneuten Reservierung.

Die Reservierung in Euro zu formulieren wäre dann der nächste Usability-Super-GAU - ich muss dann bei jeder neuen Reservierung auch die absoluten Euro-Werte anpassen.

Und ja, die prozentuale Verteilung ist nur für neue Reservierungen gültig.

Im Programmablauf sieht das dann so aus:

1. User reserviert Guthaben
2. User stellt Verteilung ein (oder belässt prozentuale Verteilung)
3. Intern wird die prozentuale Verteilung auf die jeweiligen Coins vorgenommen (das ist intern übrigens bereits der Fall!!!)
4. Sobald eine Kauforder angenommen wird, erfolgt KEINE Neuverteilung des Restguthabens gemäß der Aufteilung.

... udn nur der Schritt 4 muss aus der Software entfernt werden und alles ist gut ... keine automatische Neuverteilung des Restguthabens.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich bin erstaunt, dass XRP noch nicht im Handel auf bitcoin.de angeboten wird. Die neue bison app der Börse Stuttgart unterstützte es von Anfang an. Meine Empfehlung wäre hier nachzuziehen, um keine Kunden zu verlieren.

 

Ich persönlich mag den direkten Echtzeit-Handel über das fidor-Bankkonto, das erleichtert vieles. Aber wenn man zusätzlich vorher auch noch BTC/XRP-Spread und Gebühren auf einer anderen Böse zahlen muss um etwas von seinen XRP zu liquidieren, ist das nicht so toll. Ich überlege ich mir ernsthaft zu bison zu wechseln.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nun haben wir in der API zwei neue Features implementiert, die von einigen Usern erwünscht wurden:

1.) Man kann bestimmte IPs whitelisten, was ein Wunsch war, um Crypto-Auszahlungen per API zu handhaben

2.) Man kann den obligatorischen Notaus-Link deaktivieren, der per E-Mail versendet wird. Das wurde von Usern der Outbank-App gewünscht und könnte für manche API-Nutzer auch angenehm sein. Aber bitte beachtet, dass der Link ein Sicherheitsfeature ist, das ihr damit deaktiviert.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hat die Sortierung der Länder im Angebotsformular einen Hintergrund? Bei "Sitz der Bank des Käufers" finde ich die Sortierung nicht besonders intuitiv und würde mir wünschen, dass die Sortierung nachvollziehbar ist, z.B. alphabetisch. Weil Belgien, Malta, Bulgarien, Niederlande, Dänemark, etc. ergibt für mich wenig Sinn :)

Und wenn ich mir noch was wünschen dürfte: zusätzlich zur Abkürzung "Nur das Land der eigenen Bank" einen Link für "Nur Länder mit der Währung Euro". Hab keinen Bock auf hohe Banktransferspesen in die Schweiz und darf in der jetzigen Form bei jedem Angebot die Länder manuell auswählen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Am 21.5.2019 um 13:24 schrieb mssm:

Wir hatten schonmal darüber gesprochen, dass die Reservierung von Bankguthaben und die prozentuale Verteilung extrem unflexibel ist. Derzeit sind folgende Szenarien nicht möglich:...

Gibt es schon eine Rückmeldung, welche Lösung hier angedacht wird? Bitte dringend ansprechen für die nächsten Releases.

Es ist nun schon wieder passiert, dass übers Wochenende durch eine ausgeführte Order alle anderen Orders auf SEPA-Überweisung zurückfallen. Da ich meine Orders stets mit kleinsten Minimal-Beträgen ausstatte, d.h. mind. 60€, kann man dann nach dem Wochenende schonmal 15 Überweisungen tätigen, wenn man nicht sogar Sonntags aktiv werden muss, weil sonst die Transaktionen ge-canceled werden... Angedacht war eigentlich, dass der Direkthandel über Fidor auch eingesetzt wird.

Einziger Ausweg, den ich derzeit sehe, um den Direkthandel mit Fidor wirklich nutzen zu können, wäre die Beschränkung auf eine einzige Währung, die immer die 100% Reservierung erhält. Das kann doch für Bitcoin.de nicht die Lösung sein, zumal man sich ja Mühe gibt, auch weitere Währungen zu unterstützen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich wünsche mir ein Update der Websocket API auf eine neuere/die neueste Socket.io Version, damit sie auch mit Python nutzbar ist, siehe auch

Leider habe ich darauf noch keine Antwort bekommen. Könnte bei Interesse dann auch gerne ein kleines Tutorial schreiben, wie man das in Python nutzt. Mit Python kann man jedenfalls einfach den Einstieg in die Programmierung eines Trading Bots finden. Die von bitcoin.de verwendete Version 0.9.16 von Socket.io ist schon 5 Jahre alt und damit absolut outdated.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.