Closed goncalopp closed 11 years ago
[original comment by zuijlen on https://github.com/goncalopp/mexbtcapi/issues/13]
Concerning to the buy/sell order (action), I wonder how I can find and select (with the variable 'market') what order type I put in. A 'limit' or 'market' order are the types the btc exchanges are using now, but in the future, order types like 'stop order', 'stop limit', 'market if touched' and 'trail' (with all the sub-order types) orders will exist and have to be entered (together with their required variables) along the buy or sell variable.
For the heavy user (and later on the exchanges with more order types and functions) combined orders are available. Not only a buy and sell order 'in one package', but also a combination of more than one and the same order (buy or sell) and if one gets triggered the others are eliminated (bracket order).
Also the time frame is a known exchange variable. (Day, Good Till Cancel (default), Good Till Date, Day Till Cancel)
Exchanges are forced to state the types and time frames they offer and the variables/conditions for each type.
I think (in the future) the variables 'action' (buy/sell), 'type' and 'time in force' for a exchange order are desirable.
Hello zuijlen,
Concerning to the buy/sell order (action), I wonder how I can find and select (with the variable 'market') what order type I put in.
The library is very much in pre-alpha, so the short answer is: you don't, right now. Ideas about what would be the best interface are being extensively discussed, both here and on https://github.com/goncalopp/mexbtcapi/pull/16
If you're interested in helping shape the API, you're welcome to join the discussion. At this point, feedback from potential API users is extremely important.
A 'limit' or 'market' order are the types the btc exchanges are using now, but in the future, order types like 'stop order', 'stop limit', 'market if touched' and 'trail' (with all the sub-order types) orders will exist and have to be entered (together with their required variables) along the buy or sell variable.
It would be great to have a authoritative reference here, about this kind of features becoming exposed in the exchange's APIs
This is a lot of new info; we'll have to consider everything you said carefully while designing the interface.
I think (in the future) the variables 'action' (buy/sell), 'type' and 'time in force' for a exchange order are desirable. We've been discussing the first two already, though there's no consensus ATM
I think it may be worthwhile to start a wiki documenting this kind of decision-making - pull requests are too unstructured. I'll look into that soon
[original comment by zuijlen on #13]
Hi goncalopp,
...you're welcome to join the discussion.
Thank you.
It would be great to have a authoritative reference here...
The wiki link stated in my previous post. I bet each exchange has a different interface. Maybe the big FOREX interfaces/libraries can be used as reference ( http://en.wikipedia.org/wiki/Foreign_exchange_market ). After some googling Oanda has some programs to interact with their api: http://fxtrade.oanda.com/trade-forex/api/ Dukascopy also has some api's: Market order: http://www.dukascopy.com/wiki/#Set_Market_Order Set Stop Loss Price: http://www.dukascopy.com/wiki/#Set_Stop_Loss_price I have only limited knowledge of trading api's, and programming language, but I hope this (and probably some more references) should gives some more context.
This is a lot of new info; we'll have to consider everything you said carefully while designing the interface.
Thank you, this is my intention. To become a very good and widely used (multi currency) interface the library/interface should be able to adopt/extended with mentioned order variables in the future. In the future.
I noticed some questions/discussion about the level of knowledge someone must have to be able to use the interface. If this concerns a 'must have' variable I would like to ask you to add the variable and set a default. For example: order type deafault = limit order (due to all interfaces require to add quantity and exchange price). And for the 'Time in force' default GTC. This way a unfamiliar user gets the most safe, or most common, settings (they probably even expect it) and a professional user/exchange can select(/offer) a specific setting and do not turn down the interface because of some limitations.
I also post this in the other discussion because this one is already closed.
The wiki link stated in my previous post.
I meant in the Bitcoin exchanges. But of course, having support for these trades will only make MexBtcAPI more robust, so I think it's important to consider them, even if there's no expected support from the exchanges. Also, maybe this can become more than a Bitcoin library (and be renamed to MexAPI)
If this concerns a 'must have' variable I would like to ask you to add the variable and set a default.
The problem with that, as posed by StevenLooman, is that it's not a explicit choice, so the user may get a unintended result. Also, there's the big question of where to set that default - on order creation, or order placement. Also, whether it makes more sense to place an order with an Order object, or with its values
[original comment by zuijlen on #13]
...no expected support from the exchanges.
If I turn it the other way around, I think you try to say is: mexbtcapi only support variables if it is supported by ALL the exchanges. If this is you view, how about new entrants (exchanges)? MUST they meet all variables in play, or do you REMOVE ALL the variables they do not support?
My statement: the mexbtcapi must support (specific) variables, even if it is not supported by (all) the connected exchanges. Also, it seems to me very unlikely that bitcoin exchanges (in the future) do not support 'default' trade methods mentioned in the wiki. And if they don't it is because bitcoin stays a small market with known players...and a library will not be used.
Consequence: to be future robust, the library should support all 'must have' variables, defaults are set and connected exchanges MUST support the default settings.
...that it's not a explicit choice, so the user may get a unintended result.
That is why the connected exchanges must support the default settings. If you set the default settings to the 'most used choice':
...where to set that default
As mentioned before, I only have little knowledge how to build api functions. I think mexbtcapi should have the default values before it is sent to the exchange. This way mexbtcapi can ask/is able to ask a confirmation (with default values if no values are stated) before the order is executed.
Also, whether it makes more sense to place an order with an Order object, or with its values
Probably users do not care...if they are able to see and check what they actually sent to the exchange. I think the exchanges do not care either, if the function (order) is explicit (with help of some defaults), stable and do not require some inferior checks.
If I turn it the other way around, I think you try to say is: mexbtcapi only support variables if it is supported by ALL the exchanges.
Not at all. I agree with you: ideally, mexbtcapi MUST support a feature if ANY of the exchanges offers it.
Also, it seems to me very unlikely that bitcoin exchanges (in the future) do not support 'default' trade methods mentioned in the wiki. And if they don't it is because bitcoin stays a small market with known players...and a library will not be used.
I'm not too sure about that. It's certainly subjective whether a total market of 200 million USD, with a daily volume of 500k USD is a small market. API's are used all the time, though; big investors won't use API's at all - they'll hire a programmer to.
Also, whether it makes more sense to place an order with an Order object, or with its values
Probably users do not care...if they are able to see and check what they actually sent to the exchange. I think the exchanges do not care either, if the function (order) is explicit (with help of some defaults), stable and do not require some inferior checks.
I think you misunderstood what I meant by "user" - I didn't mean end users at all (those who click on a shiny GUI to make market orders). An API's user is the person who'll use it: the programmer who will code the said GUI. The exchange does not care at all, indeed, since it's not exposed to it. All exchanges (to date that I know of) expose a REST-like interface, parts of which mexbtcapi uses.
[original comment by zuijlen on #13] This person seems also interested in the idea to set up a BTC forex: http://www.reddit.com/r/Bitcoin/comments/185atl/i_have_a_university_education_in_finance_would/ I sent him a link to MExBtcAPI
The API now has explicit support for both 'market' and 'limit' orders. Since there's no exchange support for any other kind of order, I'm closing this issue for now. As soon as a exchange decides to support more orders we'll have to review our options.
As wikipedia describes, there's many different types of order types a market exchange may offer.
This issue was discussed briefly on https://github.com/goncalopp/mexbtcapi/issues/12 , and was reraised by zuijlen, originally at https://github.com/goncalopp/mexbtcapi/pull/13 (moved here)