Trade history and transaction history for account about xchange HOT 20 CLOSED

Agreed. Go ahead and do it if you feel like it now or we can wait until after the next release.

On another related note, I was thinking about one issue we'll run into. In regards to the

public String requestBitcoinDepositAddress(String description, String notificationUrl)

method in PollingAccountService. MtGox needs that info (description, notificationUrl), but Bitstamp not. For this situation, I suggest we have a "String[] args" method argument for all uncommon parameters.

For example, this method would become:

public String requestBitcoinDepositAddress(String[] specialArgs)

withdrawFunds may in the future become:

public String withdrawFunds(BigDecimal amount, String address, String[] specialArgs) {

What do you think??

from xchange.

Use Object varargs for a cleaner API.
On 9 Jan 2013 07:40, "Tim Molter" [email protected] wrote:

Agreed. Go ahead and do it if you feel like it now or we can wait until
after the next release.

On another related note, I was thinking about one issue we'll run into. In
regards to the

public String requestBitcoinDepositAddress(String description, String
notificationUrl)

method in PollingAccountService. MtGox needs that info (description,
notificationUrl), but Bitstamp not. For this situation, I suggest we have a
"String[] args" method argument for all uncommon parameters.

For example, this method would become:

public String requestBitcoinDepositAddress(String[] specialArgs)

withdrawFunds may in the future become:

public String withdrawFunds(BigDecimal amount, String address, String[]
specialArgs) {

What do you think??

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-12034538.

from xchange.

Do you mean something like this:http://docs.oracle.com/javase/1.5.0/docs/guide/language/varargs.html ?

I never saw that before, but looks cool.

from xchange.

Exactly. You'll be able to take a wide range of parameters and then have
the implementations handle each one as they require. Always try to use
encourage the use of specific objects/interfaces rather than a generic
String - for example favour a MtGoxConfiguration over String,String.

On 9 January 2013 07:53, Tim Molter [email protected] wrote:

Do you mean something like this:
http://docs.oracle.com/javase/1.5.0/docs/guide/language/varargs.html ?

I never saw that before, but looks cool.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-12034762.

from xchange.

Here's what I did: public String requestBitcoinDepositAddress(final String... arguments);

If it's just Strings, I'd rather not encapsulate it in an object. But as complexity increases in the future a MtGoxConfiguration could be in order.

from xchange.

@gappie The PollingTradeService interface defines a getOpenOrders() method to get all your open orders, and from that you can know what prices your limits orders got filled at because by definition, a limit order defines the price you want to buy or sell. If you meant to say market order, then yes, it's not yet implemented.

I would put a getTransactionHistory method in PollingAccountService.java and a getTradesHistory method in PollingTradeService.java interfaces. If you want to submit a pull request for this, we'll be happy to accept it.

from xchange.

from that you can know what prices your limits orders got filled

I am pretty sure that is wrong, because

1. Putting a limit order at a certain price does not guarantee that it is going to be filled at that price, only that the price is not going to be "worse" than the limit (lower for ASK and higher for BID). If there is another order on the exchange which has "better" price, your order might get filled using that and you will get more USD than planned if you were selling BTC for example.
2. getOpenOrders() only shows non-completed orders. So in case it is called before the order is completed, it will not show the final price, and in case it is called after the order is completed, it will not return that order at all.

So basically it seems there is right now no way to see the actual order filling price (and also the fee) using the existing abstract XChange facilities?

from xchange.

1. getOpenOrders() is only about getting the open orders, and not about what they get filled at. The price you set the limit order to will always be the price returned in the open orders.
2. Of course. That's why they're open order and not closed or filled orders.

Correct. The XChange interfaces would need to be expanded as mentioned above in a previous comment. Perhaps a getTransactionHistory method in PollingAccountService.java and a getTradesHistory method in PollingTradeService.java interfaces would cover the missing functionality. With getTradesHistory, you could access the actual filling order price as well as the fee. It just needs to be implemented.

Cheers!

from xchange.

wallet history implemented here: #146

from xchange.

Is it planned to implement the trade history for other exchanges?

from xchange.

@benehsv It is not planned, but we'd be happy to accept a pull request. What exchange were you thinking of? Not all of them offer trade history in their API. I can help you by giving you some pointers. If it's just one thing, I may be able to find the time to do it quickly.

from xchange.

@timmolter If you are not doing it, I will look in to it. But it would take me some time to figure out how the API is working exactly. I was mostly thinking about Bitstamp but BTCE and others would be great as well.
I can't see any exchange that does not have a transaction/trade history implemented. Which one do you mean?
Bitstamp for example has POST https://www.bitstamp.net/api/user_transactions/
BTCE has TradeHistory

from xchange.

@benehsv You're right. Probably all the exchanges have it. I somehow wasn't quite remembering things correctly. If you want to implement this for Bitstamp and BTC-E, I'd be happy to work with you on it. To start, please read this: https://github.com/timmolter/XChange/wiki/New-Implementation-Best-Practices.

If you can get the actual JSON (step 3) and the corresponding Java DTO (step 4) and the unit test for both exchanges (step 5), I will finish the rest. I would be responsible for creating the XChange-level DTO and the adapter and setting up example classes to demonstrate it all working.

One hang up might be the authentication for one or both of the exchanges. I just looked and it looks like that work has been started (not by me), but I don't know what state it's in. I'm pretty sure it's working for Bitstamp, but I'm not sure about BTC-E.

from xchange.

@benehsv Please check out BitstampUserTradeHistoryDemo.java. Now, the same thing needs to be done for BTC-E. Do you have the time to do it? By looking through the code changes I just made for Bitstamp you should be able to see what needs to be done.

from xchange.

Thanks I am working on it with my co worker @omnibrain

from xchange.

Cool. Let me know if you guys have any questions or want to discuss any changes. I'd say what you're working on is a work in progress, and it can be adapted to suit your needs specifically while remaining generic enough to be a good fit for XChange.

Did you also see the BTC-China stuff that was just added: #157? Perhaps you guys are interested...

from xchange.

BTW, I bumped up the snapshot version to 1.9.0-SNAPSHOT.

from xchange.

The TradeHistory method seems to round order amounts. The rounding creates an interesting problem trying to determine if an order was filled 100% or partially-filled-then-cancelled.

For example, an executed order amount of 0.99353786 will have a TradeHistory entry of "0.993538" -- an overage of 0.00000014. There is no overage, and BTC-e has rounded the amount up...

BTC-e is also rounding down, which is particularly frustrating: an amount of 0.01000001 becomes "0.01" in Trade history -- is there 0.00000001 still on the orderbook? or was the order cancelled? or did it really fill 100% and tradeHistory is reporting incorrectly?

BTC-e TransHistory method could resolve/solve these TradeHistory amount inaccuracies (BTC-e Support confirmed to me this week it is a known issue). TransHistory contains more accurate order execution information (as well as deposits, withdrawals).

from xchange.

User transaction history (withdrawals, deposits etc.) is still missing though. But I guess it deserves a separate issue, and there are not many comments about this in this issue.

from xchange.

Yes, it will be nice to add transaction history for btc-e.

from xchange.