thrasher-corp / gocryptotrader

A cryptocurrency trading bot and framework supporting multiple exchanges written in Golang.
MIT License
2.96k stars 792 forks source link

multiple API secrets/keys for single exchange #234

Open kempeng opened 5 years ago

kempeng commented 5 years ago

New Issue

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

Some Crypto Exchanges, like Kraken, provide multiple API keys/secrets. In the case of Kraken, the API keys are specific to the currency pair.

Expected Behavior

Please describe the behavior you are expecting I propose to make a change/addition to the config.json file, by defining the following: { "name": ExchangeName .... apiKeys: [ { "name": APIKeyName1 "key": key1 "secret": secret1 }, { "name": APIKeyName2 "key": key2 "secret": secret2 } ]

Current Behavior

What is the current behavior? { name: ExchangeName .... apiKey: key apiSecret: secret }

Failure Information (for bugs)

Please help by providing information about the failure. If it is not a bug, please remove the rest of this template.

Steps to Reproduce

Please provide detailed steps for reproducing the issue.

  1. step 1
  2. step 2
  3. step 3...

Failure Logs

By default, GoCryptoTrader stores its debug.log file in %APPDATA%\GoCryptoTrader on Windows and ~/.gocryptotrader on Linux/Unix/macOS. Raw text or a link to a pastebin type site is preferred.

gloriousCode commented 5 years ago

While multiple keys per exchange is something I desire, the problem I haven't really solved is how do you define when to use what key? On an unauthorised error? Are we building a rule handler? Your example is for specific currency pairs which I suppose is a good start. But I'm sure there are more scenarios to consider, like API permissions: what if key A can withdraw but key B cannot?

{ "name": APIKeyName2 "key": key2 "secret": secret2, "appliesOnCurrencyPairs": ["btcusd","dogeusdt"] }

So to that end, this will likely be under consideration for awhile before it will be implemented

kempeng commented 5 years ago

I was thinking along the following lines:

  1. add to the IBotExchange interface a function like GetAPICredentials()
  2. Implement this function for each Exchange:, straightforward for an exchange that just uses a single API key/secret combination: basically passing on the current apiKey/apiSecret params from config
  3. For exchanges, like Kraken, that use multiple, they can use the proposed new apiKeys section to return the appropriate key/secret via GetAPICredentials(). I am not sure about situations with other exchanges that need multiple keys/secrets, but I propose a general approach by having the name (or perhaps "label") parameter to define the scope of the api secret/key. For Kraken, the name should define the applicable cryptopair (eg BTCEUR), for the api key/secret, but for other exchanges, this might be different. If the required label is missing, GetAPICredentials() should return an error
Christian-Achilli commented 4 years ago

I am not sure I understand the use case for multiple keys per exchange. What is the benefit? If you want to have some view-only keys and some trade-enabled keys, you could have them in 2 separate config.json files (e.g. config-view.json and config-trade.json) and start GCT with the config you need at the time. I am not sure why you would want to have them at the same time. Not saying it doesn't make sense, just that I don't understand the use case :)

mshogin commented 3 years ago

There's another usecase. Suppose we have several trading strategies and we want to see how they are performing. It's not very convenient to control the strategy's balance, much easier to transfer some amount to the new strategy and run it ahead. There're at least two possibilities how to achieve it:

  1. Run separate GCT instance for every strategy
  2. Implement strategy controller outside of GCT

It looks that adding support of multi-credentials inside GCT easier and is not a complex task.

If you wouldn't mind, please suggest how would you like it be implemented and I'll take care about it. Or I can prepare a POC (as simple as possible)