TAPI: Express-Only auch bei Kauf-Order

[4ley]

Dieses Thema wurde bereits schon früher von Serpens angesprochen, kann aber leider den Thread dazu nicht mehr finden, vllt kann Serpens ihn hier verlinken.

 

 

Wie beim Express-Verkauf, muss auch beim Express-Kauf die TAPI option "createOrder([..]payment_option = 1[..]) IMMER berücksichtigt werden. Eine Express-Kauf-Order darf sich NICHT selbständig in eine normale Kauf-Order umwandeln, wenn das reservierte Fidor Guthaben nicht ausreicht.

 

Ich denke, dass ich nicht der einzige bin, dem das schon mehrmals passiert ist. Ich muss diese Trades leider immer stornieren, was sowohl mir, also auch dem Verkäufer Umstände bereitet.

 

Mein Vorschlag: Sobald das reservierte Guthaben nicht mehr ausreicht, soll die Kauf-Order automatisch auf "hidden" gestellt werden, so dass sie für andere Marktteilnehmer nicht zusehen ist, sondern nur für mich sichtbar ist, mit einem Hinweis, dass die Order nicht bedient werden kann.

[Serpens66]

ich hatte es im bitcointalk angesprochen:

https://bitcointalk.org/index.php?topic=39542.msg16821881#msg16821881

Habe da lang und breit auch mit Bergmann diskutiert und im Endeffekt doch eher "aufgegeben", bzw mich mit einem "es kommt gaaanz unten auf die ToDo Liste" zufrieden gegeben.

Gelöst habe ich das Problem für mich selbst, indem mein Bot nun immer von ~10 cent oderso weniger ausgeht, als er eigentlich hat, so lässt es sich meistens vermeiden.

[Christoph Bergmann]

Das Ergebnis der Umfrage ist zwar deutlich, aber mit drei Teilnehmern auch irgendwie ... kein so starkes Argument

[4ley]

Hallo Christoph, bedenke bitte, dass 1. die Umfrage erst gestern Abend erstellt wurde und 2. nicht alle Betroffenen im Forum aktiv sind, geschweige denn diesen Thread gelesen haben. Um eine repräsentatives Ergebnis zu erhalten, könntest du, als Forum Moderator, die Umfrage hervorheben, oder andere Kanäle nutzen, um auf diese Umfrage aufmerksam zu machen. Ich denke, dass bereits viele auf die Express-Kauf-Problematik gestoßen sind und sich über eine lange Überweisungsdauer geärgert haben. So wie es jetzt implementiert ist, ist es nicht intuitiv zu verstehen.

[Serpens66]

Das Ergebnis der Umfrage ist zwar deutlich, aber mit drei Teilnehmern auch irgendwie ... kein so starkes Argument

bitte fang nicht wieder eine sinnlose diskussion an, das hatte ich doch bereits im bitcointalk geklärt, siehe diesen kurzen post:

https://bitcointalk.org/index.php?topic=39542.msg16884534#msg16884534

 

edit:

Um mal ganz genau zu sein, gibt es nur ~10 User die man überhaupt dazu befragen muss. Denn nur soviele nutzen die API so häufig, dass ihnen ein solches Problem überhaupt auffallen könnte.

Und dagegen nun zu argumentieren "wenns es nur 10 user gibt, ists ja nicht so wichtig" wäre ebenso falsch, denn 1. machen diese einen sehr hohen Teil des gesamten Umsatzes bei bitcoin.de aus, und 2. könnte man dann auch argumentieren, dass man ja garkeine API braucht, wenn weniger als 100 leute diese nutzen.

Bearbeitet 3. Mai 2017 von Serpens66

[Christoph Bergmann]

@Serpens: Das war nicht in dem Sinne gemeint, dass es das Problem nicht gibt. 3 User sind für mich halt eine schlechte Grundlage, um bei unserem Team zu drängeln. Ich werde versuchen, nochmal nachzuhaken, daran zu erinnern. Aber da einige spannende Änderungen für die kommenden Monate anstehen, weiß ich nicht, ob das jetzt in den Plan reinpasst.

 

Vermutlich macht ihr es genau richtig: immer wieder nachhaken und fragen.

[Jokin]

Mich betrifft es auch. In meiner Anfangszeit hatte ich so einen Dusselfehler drin und über Nacht wurde ich von anderen leer gekauft.

 

Es war dann etwas knifflig alle Transaktionen fristgerecht per Überweisung zu bedienen, aber auch gleichzeitig der Ansporn das Skript entsprechend abzusichern.

 

Ich bin gerade im Urlaub, daher hab ich die Umfrage nicht gesehen ... ich würde jedoch auf "lassen wie es ist" klicken, da es wichtigere Dinge umzusetzen gibt.

 

Und mal ehrlich: Wer Bots programmiert, der wird es ja wohl zustande bringen nicht mehr Order aufzumachen als er bedienen kann.

... dazu braucht es keine API-Änderung.

[4ley]

3 User sind für mich halt eine schlechte Grundlage, um bei unserem Team zu drängeln.

Christoph, wie ich schon sagte, ist dieser Thread 1. nicht alt genug und 2. wird ihn nicht jeder lesen. Wenn euch die Meinung wirklich interessiert, dann nutze die entsprechenden Kanäle.

 

Ich werde versuchen, nochmal nachzuhaken, daran zu erinnern. Aber da einige spannende Änderungen für die kommenden Monate anstehen, weiß ich nicht, ob das jetzt in den Plan reinpasst.

Ich kann mir nicht anmaßen zu sagen "das dauert doch nicht lange", da ich eure IT nicht kenne, jedoch habe ich folgenden Vorschlag, den du gerne deinen Kollegen in der IT unterbreiten kannst.

 

Der Fall: Sobald nicht genug Guthaben reserviert ist, wird die Order automatisch in eine Nicht-Express-Order umgewandelt.

Der Vorschlag: Ich weiß bereits, dass es eine Hidden-Order Funktion gibt, deshalb schlage ich vor, dass die Order nicht in eine Nicht-Express-Order umgewandelt wird, sondern in eine Hidden-Order.

 

Mich betrifft es auch. In meiner Anfangszeit hatte ich so einen Dusselfehler drin und über Nacht wurde ich von anderen leer gekauft.

Jokin, schon alleine deine Aussage "Mich betrifft es auch." begründet eine Änderung, denn die Express-Kauf Option ist nicht intuitiv verständlich. Offensichtlich gibt es da einen Stolperstein, über den jeder mind. einmal stolpern muss, um daraus zu lernen.

 

Es war dann etwas knifflig alle Transaktionen fristgerecht per Überweisung zu bedienen, aber auch gleichzeitig der Ansporn das Skript entsprechend abzusichern.

Das resultierende Ergebnis hast du wunderbar erkannt. Nicht-Express-Überweisungen müssen manuell bedient und abgeschlossen werden. Geschieht dies nicht, weil du übersehen hast, dass es ein normaler Kauf war, bekommst du sogleich eine negative Bewertung. Verdient? Nein, denn du hast dich darauf verlassen, dass es eine Express-Order war und die Überweisung automatisch durchgeführt wird. Wäre die Order nur zu einer Hidden-Order geworden, hättest du nicht den ganzen Überweisungsstress, jedoch den Ansporn dein Script zu verbessern, da eine Hidden-Order nicht angenommen werden kann, du aber möchtest, dass deine Order bedient wird.

 

Es gibt noch weitere Fälle in denen deine Express-Kauf-Order in eine Nicht-Express-Order umgewandelt wird. Kennst du § 8 Beschränkung der Größe einzelner Verkaufsangebote auf € 25.000? Wie du siehst, ist hier die Rede von "Verkaufsangebote" und nicht auch "Kaufangebote". Nun passiert folgendes, der Preis steigt und deine Express-Kauf-Order übersteigt in der Summe die € 25k. Deine Express-Kauf-Order wird in eine Nicht-Express-Order umgewandelt und angenommen. Würdest du dich ärgern? Ich auch.

 

Es gab noch andere Fälle, über die ich erst stolpern musste, um dann entsprechend mein Script anzupassen.

 

Und mal ehrlich: Wer Bots programmiert, der wird es ja wohl zustande bringen nicht mehr Order aufzumachen als er bedienen kann.

... dazu braucht es keine API-Änderung.

Wie du bereits in den Zeilen davor lesen konntest, geht es nicht um Programmiertkünste, sondern darum, dass eine Funktion semantisch korrekt ist. Wenn ich eine Express-Order aufmache, dann darf sie zu keinem Zeitpunkt eine Nicht-Express-Order sein.

[Serpens66]

Es gibt noch weitere Fälle in denen deine Express-Kauf-Order in eine Nicht-Express-Order umgewandelt wird. Kennst du § 8 Beschränkung der Größe einzelner Verkaufsangebote auf € 25.000? Wie du siehst, ist hier die Rede von "Verkaufsangebote" und nicht auch "Kaufangebote". Nun passiert folgendes, der Preis steigt und deine Express-Kauf-Order übersteigt in der Summe die € 25k. Deine Express-Kauf-Order wird in eine Nicht-Express-Order umgewandelt und angenommen. Würdest du dich ärgern? Ich auch.

oh, die Regelung kannte ich noch garnicht O.ô Ist die neu ?

Aber wann passiert dabei eine Umwandlung?

Wenn man versucht eine zu große Express-Verkaufsorder zu erstellen, bekommt man diese Fehlermeldung:

{'errors': [{'field': 'max_amount', 'code': 'invalid', 'message': 'The sales offer set by you exceeds the limitation ofthe size of individual sales offers according to §8 supplementary agreement on the introduction of accelerated transaction processing.'}], 'credits': 19}

 

Allerdings wundert es mich, dass die Größe nicht angepasst wurde.

Schließlich wurde für den Expresskauf die maximalMenge auf 30k€ erhöht, während es beim Verkauf weiterhin 25k sind.

@Christoph:

Kannst ja mal weiterleiten, dass kauf und verkauf gleichhoch begrenzt sein sollten (wenn es diese begrenzung unbedingt geben muss). Bin sicher, dass bitcoin.de es einfach vergessen hat.

Bearbeitet 5. Mai 2017 von Serpens66

[4ley]

Serpens, du kannst 30k€ reservieren, jedoch kann eine Kauf-Order nur bis 25k€ Express sein. Ich glaube nicht, dass das neue ist.

[Serpens66]

Serpens, du kannst 30k€ reservieren, jedoch kann eine Kauf-Order nur bis 25k€ Express sein. Ich glaube nicht, dass das neue ist.

ich glaube das führt gerade zu sehr viel Verwirrung und ist eig auch ein anderes Thema, da es soweit ich erkennen kann, nichts mit der Umwandlung von Express in Normal zu tun hat.

Deswegen werde ich Kommentare dazu besser sein lassen. (vllt ein neuer Thread?)

Bearbeitet 5. Mai 2017 von Serpens66

[4ley]

Gerne können wir einen neuen Thread erstellen, jedoch denke ich, dass ein Teil dieser Thematik hier rein passt.

 

1. Man kann 30k€ reservieren, aber eine Express-Order nur bis zu 25k€ aufmachen.

2. Wenn eine Kauf-Order mit einem Volumen höher als 25k€ erstellt wird, wird diese Order eine normale Kauf- und keine Express-Order sein, auch wenn du 30k€ reserviert hast.

[Jokin]

Wieviel Bitcoin-User haben denn dieses 25k-Problem?

 

Ich sehe nur einen regelmäßig Betroffenen.

 

Wäre ich Bitcoin.de-Projektleiter, würde ich solche Anforderungen hinten anstellen und lieber die dadurch verursachten Negativbewertungen kulant manuell löschen.

Immerhin braucht es solche Poweruser, die man sich nicht vergraulen sollte. Und insbesondere die handvoll Arbitage-Bots wird Bitcoin.de eher zuvorkommend behandeln ... die Umsätze und die daraus generierten Gebühren sind immens.

 

Natürlich kann man nun auch fordern, dass mit diesen Einnahmen auch "Korrekturen" an der Bitcoin.de-Software vorgenommen werden sollten ... absolut legitim.

 

Auf der anderen Seite steht die Fork-Geschichte an und das wird bei Bitcoin.de sicher tiefgreifende Änderungen bedeuten - tiefer als bei kraken, die eh schon viele Währungen implementiert haben.

 

Und lieber Christoph, bitte stellt den Intensiv-API-Nutzern eine Beta-API zur Verfügung und holt Euch die Bug-Reports von ihnen ... es sind ja nur eine Handvoll User.

 

Eventuell über ein separates Unterforum? Wenn nicht eh schon vorhanden ...

 

Schöne Grüße!

[Christoph Bergmann]

Hallo zusammen,

 

hier noch mal den Standpunkt, den Bitcoin.de zu diesem Problem auf absehbare Zukunft einnimmt (sprich: sofern sich nicht die Beschwerden massiv häufen, wird es erstmal dabei bleiben):

 

"Die Frage, wie man mit Kauf-Ordern umgeht, wenn die Reservierung ausläuft, wurde intern sehr lange diskutiert. Nach der Durchsicht und Diskussion verschiedener Szenarien hat sich Bitcoin.de dafür entschieden, dass sich Express-Kauf-Order im Falle des Auslaufens der Reservierung automatisch in SEPA-Order verwandeln.

Der Grund ist, dass wir keine Kaufanfragen löschen wollen, wenn die Reservierung ausläuft. Es wurde auch diskutiert, ob man Kaufanfragen unsichtbar machen kann, bis wieder ein entsprechendes Guthaben vorhanden ist.

Dies wurde verworfen, weil es dann passieren kann, dass alte Kaufanfragen nach einer erneuten Reservierung plötzlich wieder "aufpoppen" und so unter Umständen Anfragen mit "historischen Preisvorstellungen" erscheinen. Natürlich könnte man mit Warnmeldungen arbeiten, aber diese würden das System und das Handling für die User komplexer machen.

Nutzer der API könnten das "Switchen auf SEPA" verhindern, indem sie per API den Stand der Reservierung abfragen und in dem Fall auslaufenden Reservierungen entweder eine neue Reservierung (leider manuell) veranlassen oder die verbleibenden Kaufanfragen löschen."

[4ley]

Der Grund ist, dass wir keine Kaufanfragen löschen wollen, wenn die Reservierung ausläuft. Es wurde auch diskutiert, ob man Kaufanfragen unsichtbar machen kann, bis wieder ein entsprechendes Guthaben vorhanden ist.

 

Dies wurde verworfen, weil es dann passieren kann, dass alte Kaufanfragen nach einer erneuten Reservierung plötzlich wieder "aufpoppen" und so unter Umständen Anfragen mit "historischen Preisvorstellungen" erscheinen.

Dies sehe ich als kleineres "usability" Problem an, als es momentan ist, zumal es vorhersehbar ist. Man kennt die Orders, die offen sind. Man kann sonst auch eine Hinweisbox auf der Reservierungsseite hinzufügen, die sagt "Kauf-Orders werden sichtbar, sobald sie eine Reservierung vornehmen."

 

Nutzer der API könnten das "Switchen auf SEPA" verhindern, indem sie per API den Stand der Reservierung abfragen und in dem Fall auslaufenden Reservierungen entweder eine neue Reservierung (leider manuell) veranlassen oder die verbleibenden Kaufanfragen löschen."

Mir ist es schon paar mal passiert, dass beim Reserviervorgang, in der kurzzeitig die Express-Order zu einer normalen Order umgewandelt wird, die Order angenommen wurde. Ich werde in solchen Fällen jetzt immer auf eine Stornierung bestehen und auf diesen Thread verweisen.

 

Per API prüfen, ob genug reserviert ist, wird leider zu viele Credits kosten.

[Jokin]

Dass während des Reservierungsvorgangs eine Order angenommen wurde, passierte mir auch schon - super ärgerlich, da es dann einen oder zwei Tage dauert bis alles abgewickelt ist.

 

Hier würde ich mir auch wünschen, dass sobald der Reservierungsvorgang gestartet wird die Kauforder entweder unsichtbar werden oder gelöscht werden.

 

Kann man ja auf der Reservierungsseite einbauen:

[ ] offene Kauforder unsichtbar schalten

[ ] ... löschen

[ ] zur SEPA-Order werden lassen

 

:-)