There is a java cryptsy API that would make an excellent addition to XChange framework or cryptocoin-tradelib here:
https://github.com/abwaters/cryptsy-api
Topic: [Announce] XChange - A Financial Exchange Library for Java V1.3.0 (Read 4283 times)
February 13, 2014, 02:13:51 PM
July 21, 2013, 06:49:02 AM
Oh, more Java coders here! Very cool! I'm working on similar code:
https://github.com/ReAzem/cryptocoin-tradelib
If you need help tom implement other exchanges, let me know. I have some code.
https://github.com/ReAzem/cryptocoin-tradelib
If you need help tom implement other exchanges, let me know. I have some code.
July 18, 2013, 10:26:11 PM
I started making a Scala library to connect to CampBX. It's open source and hosted here https://github.com/nanop/btcsauce. Scala users will find this the easiest to use. So far, it's not as comprehensive as XChange but it's up to date with all of CampBX's features including testnet(https://testnet.campbx.com/), and missing services from XChange for CampBX such as https://campbx.com/api/recenthistory.php. All the methods are listed under Basics in the README. For Scala users out there, it uses scala futures for async requests and play's json and WS packages for web services which I find very easy to use.
June 02, 2013, 04:46:56 PM
Just a thought but it seems BTCe is broken by design. Their API spec shows only limit orders, and xchange sends only market orders. This causes the following error it appears.
Possibly altering the order to actually complete by making it a limit order would be great.
Code:
java.lang.UnsupportedOperationException: Market orders not supported by BTCE API.
at com.xeiam.xchange.btce.service.trade.polling.BTCEPollingTradeService.place
MarketOrder(BTCEPollingTradeService.java:68)
at com.xeiam.xchange.btce.service.trade.polling.BTCEPollingTradeService.place
MarketOrder(BTCEPollingTradeService.java:68)
Possibly altering the order to actually complete by making it a limit order would be great.
All exchanges in XChange also have a placeLimitOrderMethod.
April 22, 2013, 03:29:38 PM
Just a thought but it seems BTCe is broken by design. Their API spec shows only limit orders, and xchange sends only market orders. This causes the following error it appears.
Possibly altering the order to actually complete by making it a limit order would be great.
Code:
java.lang.UnsupportedOperationException: Market orders not supported by BTCE API.
at com.xeiam.xchange.btce.service.trade.polling.BTCEPollingTradeService.place
MarketOrder(BTCEPollingTradeService.java:68)
at com.xeiam.xchange.btce.service.trade.polling.BTCEPollingTradeService.place
MarketOrder(BTCEPollingTradeService.java:68)
Possibly altering the order to actually complete by making it a limit order would be great.
January 20, 2013, 10:18:24 AM
Hi Freemoney,
I think you're right. The next logical step would be to create an app, where one could buy and sell Bitcoin (and eventually other forex, stocks, futures, etc.) from several different exchanges. The GUI would give you an overview of all your accounts and quick access to place orders, transfer funds, etc.
If someone is planning on doing this in a Java desktop app or Android app, using XChange would give them a huge base to work off of.
Cheers, Tim
I think you're right. The next logical step would be to create an app, where one could buy and sell Bitcoin (and eventually other forex, stocks, futures, etc.) from several different exchanges. The GUI would give you an overview of all your accounts and quick access to place orders, transfer funds, etc.
If someone is planning on doing this in a Java desktop app or Android app, using XChange would give them a huge base to work off of.
Cheers, Tim
January 18, 2013, 05:25:19 PM
Hi Freemoney,
I think what you are describing - p2p trading - is something of a holy grail that is easy to state but very difficult to implement.
Even Open Transactions, which is probably the most advanced architecture similar to this, relys on a server-client architecture.
For instance you say:
"I suggest to set up a p2p escrow functionality directly as an extension to the client"
We don't even have regular escrow usable to everyone yet, nevermind a p2p multisig implementation !
That is not to say it is not possible, but we are a long way from what you are describing at the moment.
:-)
Jim
I think what you are describing - p2p trading - is something of a holy grail that is easy to state but very difficult to implement.
Even Open Transactions, which is probably the most advanced architecture similar to this, relys on a server-client architecture.
For instance you say:
"I suggest to set up a p2p escrow functionality directly as an extension to the client"
We don't even have regular escrow usable to everyone yet, nevermind a p2p multisig implementation !
That is not to say it is not possible, but we are a long way from what you are describing at the moment.
:-)
Jim
January 18, 2013, 05:07:35 PM
I like this project a lot.
I have a suggestion which might be a bit off-topic, maybe you can point me in a better direction where to address this.
Now that you have some exchange data happily being displayed in e.g. MultiBit, the next logical step will be to integrate a mechanism to buy and sell bitcoins.
I see the following possible approaches:
1. Integrating the APIs of one or more centralized exchanges like e.g. MtGox etc. Possibly the easiest and most useful approach today.
Personally, I do not like these exchanges because these exchanges require a lot of trust in their honesty and integrity, technical skills to run the exchange and to secure it against attacks and because fiat money transfers to/from the exchanges usually take long or a lot of fees are involved. Also, there is a double risk involved: You can loose the deposited bitcoins AND you can loose the deposited fiat money.
2. Integrating Ripple-like mechanisms that already have been proposed elsewhere. The beauty is that it ends up in a p2p decentralized form of exchange. But there is still trust involved that all involved parties will be honest and settle their balances. Of course a rating system for every user can be included, but this involves setting up three p2p networks in parallel: Bitcoin, Ripple-like credit balances and a p2p trust rating system. It seems very high-end, but also very complex and therefore will take a long time to develop and to convince people to use it.
3. Integrating the API to a site like BitMarket.eu into the Bitcoin client. This is a mixture of 1 and 2. The real exchange is done on a person-to-person basis. All BitMarket.eu does in the first step is to bring together seller and buyer when certain criteria match: Agreed price and settlement method, basically. This could also be done in a p2p approach or using standardized IRC messages. In the second step BitMarket.eu acts as an escrow service where the offered bitcoins are only released to the buyer if the seller confirms that the price has been paid. But there is still trust needed in the escrow functionality, if a centralized site like BitMarket.eu is used.
In order to get rid of a centralized escrow service from 3, I suggest to set up a p2p escrow functionality directly as an extension to the client. This leads to a fourth approach:
4. Integrating the mechanisms to bring together buyers and sellers if prices and settlement method match (maybe standardized IRC messages are sufficient) AND THEN to use multisignature transactions as an escrow service within the p2p client exchange network. It basically means the same user experience as in BitMarket.eu, but all completely within the Bitcoin client. So there is no need for a centralized exchange and no need to trust a centralized institution as escrow.
Do you think this is feasible? Do you know a better place where to post this?
I have a suggestion which might be a bit off-topic, maybe you can point me in a better direction where to address this.
Now that you have some exchange data happily being displayed in e.g. MultiBit, the next logical step will be to integrate a mechanism to buy and sell bitcoins.
I see the following possible approaches:
1. Integrating the APIs of one or more centralized exchanges like e.g. MtGox etc. Possibly the easiest and most useful approach today.
Personally, I do not like these exchanges because these exchanges require a lot of trust in their honesty and integrity, technical skills to run the exchange and to secure it against attacks and because fiat money transfers to/from the exchanges usually take long or a lot of fees are involved. Also, there is a double risk involved: You can loose the deposited bitcoins AND you can loose the deposited fiat money.
2. Integrating Ripple-like mechanisms that already have been proposed elsewhere. The beauty is that it ends up in a p2p decentralized form of exchange. But there is still trust involved that all involved parties will be honest and settle their balances. Of course a rating system for every user can be included, but this involves setting up three p2p networks in parallel: Bitcoin, Ripple-like credit balances and a p2p trust rating system. It seems very high-end, but also very complex and therefore will take a long time to develop and to convince people to use it.
3. Integrating the API to a site like BitMarket.eu into the Bitcoin client. This is a mixture of 1 and 2. The real exchange is done on a person-to-person basis. All BitMarket.eu does in the first step is to bring together seller and buyer when certain criteria match: Agreed price and settlement method, basically. This could also be done in a p2p approach or using standardized IRC messages. In the second step BitMarket.eu acts as an escrow service where the offered bitcoins are only released to the buyer if the seller confirms that the price has been paid. But there is still trust needed in the escrow functionality, if a centralized site like BitMarket.eu is used.
In order to get rid of a centralized escrow service from 3, I suggest to set up a p2p escrow functionality directly as an extension to the client. This leads to a fourth approach:
4. Integrating the mechanisms to bring together buyers and sellers if prices and settlement method match (maybe standardized IRC messages are sufficient) AND THEN to use multisignature transactions as an escrow service within the p2p client exchange network. It basically means the same user experience as in BitMarket.eu, but all completely within the Bitcoin client. So there is no need for a centralized exchange and no need to trust a centralized institution as escrow.
Do you think this is feasible? Do you know a better place where to post this?
January 17, 2013, 05:53:50 AM
Good stuff - that caching simplifies what I have to do as I then don't have to worry if I am hitting the server too often.
Here's some example code from the xchange-examples jar to demonstrate using the api key and requesting the data from OpenExchangeRates:
Code:
// Use the factory to get the Open Exchange Rates exchange API
ExchangeSpecification exchangeSpecification = new ExchangeSpecification("com.xeiam.xchange.oer.OERExchange");
exchangeSpecification.setUri("http://openexchangerates.org");
exchangeSpecification.setApiKey("ea88c922bca263ba9345b4717914ee1f");
Exchange openExchangeRates = ExchangeFactory.INSTANCE.createExchange(exchangeSpecification);
// Interested in the polling market data feed
PollingMarketDataService marketDataService = openExchangeRates.getPollingMarketDataService();
// Get the latest ticker data showing EUR/USD
Ticker ticker = marketDataService.getTicker(Currencies.EUR, Currencies.USD);
System.out.println("Last: " + ticker.getLast().toString());
// Request another ticker JPY/USD. it will return a cached object
ticker = marketDataService.getTicker(Currencies.JPY, Currencies.USD);
System.out.println("cached Last: " + ticker.getLast().toString());
ExchangeSpecification exchangeSpecification = new ExchangeSpecification("com.xeiam.xchange.oer.OERExchange");
exchangeSpecification.setUri("http://openexchangerates.org");
exchangeSpecification.setApiKey("ea88c922bca263ba9345b4717914ee1f");
Exchange openExchangeRates = ExchangeFactory.INSTANCE.createExchange(exchangeSpecification);
// Interested in the polling market data feed
PollingMarketDataService marketDataService = openExchangeRates.getPollingMarketDataService();
// Get the latest ticker data showing EUR/USD
Ticker ticker = marketDataService.getTicker(Currencies.EUR, Currencies.USD);
System.out.println("Last: " + ticker.getLast().toString());
// Request another ticker JPY/USD. it will return a cached object
ticker = marketDataService.getTicker(Currencies.JPY, Currencies.USD);
System.out.println("cached Last: " + ticker.getLast().toString());
...and the result...
Code:
Last: EUR 0.752646
cached Last: JPY 88.740257
cached Last: JPY 88.740257
January 17, 2013, 05:51:09 AM
Checked out the various announcements and they all look good.
Next step is to get the merchant arbitrage API designed, I think.
And more exchanges!
Next step is to get the merchant arbitrage API designed, I think.
And more exchanges!
January 17, 2013, 05:36:57 AM
Good stuff - that caching simplifies what I have to do as I then don't have to worry if I am hitting the server too often.
January 17, 2013, 05:26:38 AM
Ok - I will add in a little entry field and explanatory message box when I move up to this version.
OpenExchangeRates has 161 rates available so it is hardly any hassle for what you get.
Also, the 'best' polling time varies from exchange to exchange. For instance OpenExchangeRates updates hourly and with 1000 free polls per month it is pointless to poll faster than that.
Is that available on the exchange metadata or will I have to hardcode it ?
OpenExchangeRates has 161 rates available so it is hardly any hassle for what you get.
Also, the 'best' polling time varies from exchange to exchange. For instance OpenExchangeRates updates hourly and with 1000 free polls per month it is pointless to poll faster than that.
Is that available on the exchange metadata or will I have to hardcode it ?
Hi Jim,
You can call getRefreshRate() on any exchange that implements CachedDataSession, such as OpenExchangeRates exchange, and it will give you the time in seconds representing the refresh rate for that particular data provider. CachedDataSessions cache the data internally as well, and make sure to only call out for new data at an appropriate interval. Another example of this is bitcoincharts. The refresh rate for that one is 15 minutes.
I hope that helps!
January 17, 2013, 05:04:46 AM
Ok - I will add in a little entry field and explanatory message box when I move up to this version.
OpenExchangeRates has 161 rates available so it is hardly any hassle for what you get.
Also, the 'best' polling time varies from exchange to exchange. For instance OpenExchangeRates updates hourly and with 1000 free polls per month it is pointless to poll faster than that.
Is that available on the exchange metadata or will I have to hardcode it ?
OpenExchangeRates has 161 rates available so it is hardly any hassle for what you get.
Also, the 'best' polling time varies from exchange to exchange. For instance OpenExchangeRates updates hourly and with 1000 free polls per month it is pointless to poll faster than that.
Is that available on the exchange metadata or will I have to hardcode it ?
January 17, 2013, 04:56:57 AM
Great stuff Tim !
A question: for the OpenExchangeRate exchange, does it need a per-user authentification code ? (the open exchange rate anti-spam measure).
A question: for the OpenExchangeRate exchange, does it need a per-user authentification code ? (the open exchange rate anti-spam measure).
Yes, each user needs an authentication code which they can get for free by signing up at OpenExchangeRates (https://openexchangerates.org/). The free version limits you to 1000 requests per month I believe.
January 17, 2013, 04:49:23 AM
Great stuff Tim !
A question: for the OpenExchangeRate exchange, does it need a per-user authentification code ? (the open exchange rate anti-spam measure).
A question: for the OpenExchangeRate exchange, does it need a per-user authentification code ? (the open exchange rate anti-spam measure).
January 17, 2013, 04:13:20 AM
Our Financial Exchange Library for Java, XChange, has seen a lot of active development since the previous release in October 2012. We went from 2 to 7 exchange implementations thanks mostly to the growing community starting to support the project more.
Following is a list of the supported exchanges. More detailed info can be found here: https://github.com/timmolter/XChange/wiki/Exchange-Support, which includes planned future exchange implementations.
In this release, we introduced a new and improved REST interface that sits between our exchange classes and the class responsible for fetching JSON. It also gives XChange clients access to the raw unmarshalled JSON data if they want it, which was something XChange needed for a long time.
All exchange implementations have full-coverage unit tests.
We've been able to reduce the number of dependencies a lot. One of the main focuses of XChange is to be very lightweight. Most notably is the outdated org.json jar. We dug into the Socket.io code, and painstakingly swapped out the old code with our already-used Jackson JSON code. This is good news for apps like Bitcoinium and Multibit, which both use XChange, for keeping their executable footprint small.
Another major accomplishment with this release, is that the artifacts are now hosted on Maven Central.
We're thinking about adding an arbitrage API within XChange next as the MtGox, BTC-E, and Bitstamp implementations all contain trading functionality.
Open Source Code (MIT license)
https://github.com/timmolter/XChange
Wiki on GitHub
https://github.com/timmolter/XChange/wiki
Project Home
http://xeiam.com/xchange.jsp
Artifacts on Maven Central
http://search.maven.org/#search%7Cga%7C1%7Cxeiam%20xchange
Feedback is appreciated!!
https://github.com/timmolter/XChange/issues
Following is a list of the supported exchanges. More detailed info can be found here: https://github.com/timmolter/XChange/wiki/Exchange-Support, which includes planned future exchange implementations.
- MtGox - polling and streaming market data, authenticated trading
- Bitstamp - polling market data, authenticated trading
- BTC-E - polling market data, authenticated trading
- VirtEx - polling market data
- CampBX - polling market data
- BitcoinCharts - polling market data (Bitcoin Exchange Rates)
- OpenExchangeRates - polling market data (Fiat Currency Exchange Rates)
In this release, we introduced a new and improved REST interface that sits between our exchange classes and the class responsible for fetching JSON. It also gives XChange clients access to the raw unmarshalled JSON data if they want it, which was something XChange needed for a long time.
All exchange implementations have full-coverage unit tests.
We've been able to reduce the number of dependencies a lot. One of the main focuses of XChange is to be very lightweight. Most notably is the outdated org.json jar. We dug into the Socket.io code, and painstakingly swapped out the old code with our already-used Jackson JSON code. This is good news for apps like Bitcoinium and Multibit, which both use XChange, for keeping their executable footprint small.
Another major accomplishment with this release, is that the artifacts are now hosted on Maven Central.
We're thinking about adding an arbitrage API within XChange next as the MtGox, BTC-E, and Bitstamp implementations all contain trading functionality.
Open Source Code (MIT license)
https://github.com/timmolter/XChange
Wiki on GitHub
https://github.com/timmolter/XChange/wiki
Project Home
http://xeiam.com/xchange.jsp
Artifacts on Maven Central
http://search.maven.org/#search%7Cga%7C1%7Cxeiam%20xchange
Feedback is appreciated!!
https://github.com/timmolter/XChange/issues
Jump to: