Bitcoin Forum
December 08, 2024, 07:36:06 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Trading Bot possible? and how to get it?  (Read 940 times)
bradbrad (OP)
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile
May 11, 2013, 06:40:08 AM
 #1

Hi Guys, a bit of a newbie when it comes to trading bots. I would like to have one for bitstamp where I can set the sell price, as well as the buy back price. In other words set a few variables that if it reaches x amount, sell. If it returns true, then buy back at x amount. If it reaches y amount sell, and then buy back at y amount. How would I go about doing this? Can you get someone to code it? Where would I go? freelancer? and help would be appreciated!
seannnyx
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 11, 2013, 09:36:32 AM
 #2

How do you do?
btc_lurker
Member
**
Offline Offline

Activity: 78
Merit: 10



View Profile
May 11, 2013, 02:57:01 PM
 #3

I feel very uncomfortable in trading at Bitstamp (and some other exchanges) through the API, and I hope they did different decisions in their internal code. Why, oh why, did they think it was a good idea to send user and password when making requests ? This is too sensitive, and users very often pick the same password for different services. This data is ultimately going through HTTPS, but still..

Anyway, it would be easy to implement the private part of the API in https://github.com/knowitnothing/btcx/blob/master/btcx/bitstamp.py. Then it is a matter of creating a interface for placing the combined sell/buy order together with data pooling to decide when to actually sell and buy at the given value or condition.
fluidjax
Hero Member
*****
Offline Offline

Activity: 750
Merit: 601



View Profile
May 11, 2013, 08:02:51 PM
 #4

I feel very uncomfortable in trading at Bitstamp (and some other exchanges) through the API, and I hope they did different decisions in their internal code. Why, oh why, did they think it was a good idea to send user and password when making requests ? This is too sensitive, and users very often pick the same password for different services. This data is ultimately going through HTTPS, but still..

I understand the gut reaction, but it's https! The real risk lies at each end of the connection. But then there would still be risk at each end even if they used something like gox's secret.
DO you not have faith in https?
btc_lurker
Member
**
Offline Offline

Activity: 78
Merit: 10



View Profile
May 11, 2013, 09:46:43 PM
 #5

I feel very uncomfortable in trading at Bitstamp (and some other exchanges) through the API, and I hope they did different decisions in their internal code. Why, oh why, did they think it was a good idea to send user and password when making requests ? This is too sensitive, and users very often pick the same password for different services. This data is ultimately going through HTTPS, but still..

I understand the gut reaction, but it's https! The real risk lies at each end of the connection. But then there would still be risk at each end even if they used something like gox's secret.
DO you not have faith in https?

There is a huge difference in using generated key/secret pairs from using the actual username/password pairs. For a starter, the former can be restricted to perform only certain operations, the latter can perform everything always. Even if some key/secret from MtGox or BTC-e were leaked, it could be the case that the attacker wouldn't be able to do anything interesting with them.
KS
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


View Profile
May 12, 2013, 08:54:09 PM
 #6

I feel very uncomfortable in trading at Bitstamp (and some other exchanges) through the API, and I hope they did different decisions in their internal code. Why, oh why, did they think it was a good idea to send user and password when making requests ? This is too sensitive, and users very often pick the same password for different services. This data is ultimately going through HTTPS, but still..

I understand the gut reaction, but it's https! The real risk lies at each end of the connection. But then there would still be risk at each end even if they used something like gox's secret.
DO you not have faith in https?

There is a huge difference in using generated key/secret pairs from using the actual username/password pairs. For a starter, the former can be restricted to perform only certain operations, the latter can perform everything always. Even if some key/secret from MtGox or BTC-e were leaked, it could be the case that the attacker wouldn't be able to do anything interesting with them.

agree. why not use a hash of the pwd/login combo instead??
fluidjax
Hero Member
*****
Offline Offline

Activity: 750
Merit: 601



View Profile
May 13, 2013, 06:16:33 AM
 #7

I feel very uncomfortable in trading at Bitstamp (and some other exchanges) through the API, and I hope they did different decisions in their internal code. Why, oh why, did they think it was a good idea to send user and password when making requests ? This is too sensitive, and users very often pick the same password for different services. This data is ultimately going through HTTPS, but still..

I understand the gut reaction, but it's https! The real risk lies at each end of the connection. But then there would still be risk at each end even if they used something like gox's secret.
DO you not have faith in https?

There is a huge difference in using generated key/secret pairs from using the actual username/password pairs. For a starter, the former can be restricted to perform only certain operations, the latter can perform everything always. Even if some key/secret from MtGox or BTC-e were leaked, it could be the case that the attacker wouldn't be able to do anything interesting with them.

I can understand that the ability to disallow withdrawals for the key/secret type access can improve security.
But I guess what key is that in the case of the key/secret, at no time is data sent to the server, that if it fell into the wrong hands, that would allow someone else to create another api request. (They don't have the secret). However with the username/password if the server is compromised, the data sent by a user would contain enough data to make any api request they want.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!