Trading Bot possible? and how to get it?

[bradbrad]

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]

How do you do?

[btc_lurker]

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]

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]

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]

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]

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.