Nonce timestamp ms instead of .net ticks

[yaroslavlsd]

Caution

For existing api keys - this change is breaking change, they should be recreated

Motivation:

1. Unification - Same api key can be used in other projects, sdks, languages & runtimes where .NET ticks is rare to use.
2. To change alg to ms (as above), since ticks has more precision, we need recreate api key, but reverse change (ms->ticks) can be done without it in any time.
3. Simplify - Since we can have parallel requests (ex: parallel fetch orders, create etc) to get 5 seconds window we need set 50000000 nonce window instead of 5000, since 10 million ticks in a second.

Official recomendations

Examples for a nonce based upon the current UNIX time in milliseconds (a popular and effective choice for a nonce) would be:

• a nonce window setting of 5000 allowing a 5 second nonce window,

While a simple counter such as the above would provide a valid nonce, a more effective method of generating valid nonce values is to use a UNIX timestamp in milliseconds (the number of milliseconds since the 1st of January 1970 at 00:00:00 UTC). 

Using a millisecond or higher resolution timestamp for the nonce guarantees that all of the requirements of a valid nonce are met (uniqueness and always increasing), and provides sufficient values for traders making rapid successive API calls (market makers, high frequency trading bots, etc.).

Links:

• https://support.kraken.com/articles/360000906023-what-is-a-nonce-
• https://support.kraken.com/articles/360001148023-what-is-a-nonce-window-

[JKorf]

I agree that ms would be preferable, but as you noted it would mean all users need to recreate their API key.
I don't think it's worth to introduce such a breaking change mainly just to allow the API key to be used in other projects.

[yaroslavlsd]

I agree that ms would be preferable, but as you noted it would mean all users need to recreate their API key. I don't think it's worth to introduce such a breaking change mainly just to allow the API key to be used in other projects.

As always (about breaking change) you have different options here.

1. Create new option that by default is old behavior.
2. Schedule breaking change in one of next major updates (with allowed breaking changes).
3. Add auto open txt file after nuget package install (if missed).
4. Dynamically detect with nonce is used on account (handle error, cache and retry with old behavior).
5. etc