GOC.io – биржа! BTC/RUR; LTC/RUR | Объём > 5 000 000 RUR

[mastero]

Коллеги, мы получили от вас запрос на создании отдельной ветки по API.
У нас есть стандартный API для торговых роботов, совместимый с BTC-e.

Будем рады услышать ваши вопросы и предложения, и с еще большой радостью на них ответим!

---
АКЦИЯ!

При подключении трейдеров с роботами по API – бонус на счет 1000 RUR!
Описание API здесь: https://goc.io/docs/gocio_trade_api.pdf

Для подключения нужно создать ключ на странице торгов: https://goc.io/?cmd=x
---

GOC.io - Ввод/Вывод BTC/RUR доступны множеством самых удобных способов.
торги здесь: https://goc.io/?cmd=x
способы ввода: https://goc.io/?cmd=depo_ways
способы вывода: https://bitcointalk.org/index.php?topic=503501.msg5918586#msg5918586

3% - Вывод в RUR
0% - Ввод криптовалюты и RUR
0% - Возврат остатка депозита в криптовалюте
0,2% - Моментальные переводы между кошельками
0,2% - Сделка покупки/продажи криптовалюты

Ввод наличными (крупных сумм с комиссией) через отделения: http://wmmoscow.com и http://www.cashinout.ru

[1715009889]

1715009889

[1715009889]

1715009889

[1715009889]

1715009889

[hazarun]

Коллеги, мы получили от вас запрос на создании отдельной ветки по API.
У нас есть стандартный API для торговых роботов, совместимый с BTC-e.

У меня собственно, те же самые вопросы для начала, что уже задавал в ваших ветках:

Совместимость с АПИ БТЦе вовсе не полная.

1. Не работало в АПИ2 ограничение количества ордеров в стакане по запросу стакана.
         На БТЦе - такое работает. На ГОК не работало.
         Получаю ордера тысячами, хотя мне нужен десяток ближайших. Пример приводил.

2. На БТЦе уже год как работает АПИ3. Намного экономичнее и удобнее в плане трафика.
         Какие тут планы ? Ссылку на их АПИ3 давал.

3. Была обещана возможность оперирования средствами при помощи АПИ.
         Что то по срокам можно говорить ?

[mastero]

Коллеги, мы получили от вас запрос на создании отдельной ветки по API.
У нас есть стандартный API для торговых роботов, совместимый с BTC-e.

У меня собственно, те же самые вопросы для начала, что уже задавал в ваших ветках:

Совместимость с АПИ БТЦе вовсе не полная.

1. Не работало в АПИ2 ограничение количества ордеров в стакане по запросу стакана.
         На БТЦе - такое работает. На ГОК не работало.
         Получаю ордера тысячами, хотя мне нужен десяток ближайших. Пример приводил.

2. На БТЦе уже год как работает АПИ3. Намного экономичнее и удобнее в плане трафика.
         Какие тут планы ? Ссылку на их АПИ3 давал.

3. Была обещана возможность оперирования средствами при помощи АПИ.
         Что то по срокам можно говорить ?

Итак, по порядку:

1. Ограничение ордеров пока еще в процессе.

2. АПИ3 тоже в разработке.

3. Вывод через АПИ пока не документирован. Можем дать, если у вас серьезные намерения и остатки нормальные на счете.

[hazarun]

Вывод через АПИ пока не документирован. Можем дать, если у вас серьезные намерения и остатки нормальные на счете.

Смотрится магко говоря странно.
Не документированные и не тестированные возможности применять к серьезным суммам.   

Сперва - тестирование на копейках, потом , можно и начинать работать. А как еще может быть ?

[hazarun]

1. Ограничение ордеров пока еще в процессе.

Думаю, ограничение передаваемого стакана - самая актуальная фишка.
При увеличении количества роботов и валютных пар,
ежесекундная передача стаканов с тысячами ордеров - весьма затратно по трафику.

[rPman]

Я уже предлагал разным биржам предоставлять эту информацию, но по каким то непонятным для меня причинам, разработчики/владельцы биржи даже не думаю об этом, наверное трафик защиты ддос стоит недостаточно дорого.

Например лог сырых данных (это все события - размещение ордеров, отмена ордера, модификация объема ордера, факты пересечения ордеров) может иметь следующий формат (простая таблица с полями):
* идентификатор события - для событий типа order/cancel - это идентификатор отложенный сделки, для trade - просто идентификатор, я рекомендую здесь использовать единый сиквенс
* время - пожалуйста, не экономьте на точности, выдавайте microtime(true) хотя бы с 3 знаками после запятой (а в protobuf используйте float или даже int64 но в микросекундах)
* валютная пара - ltc_usd/btc_usd/... правильнее идентфикатор и выдавать информацию по ним отдельным запросом
* тип события - trade/order/cancel, order - клиент разместил ордер, cancel - отменил ордер, trade - факт пересечения одной сделки пользователя с другой, т.е. если клиент разместил ордер по рынку, в лог попадут как минимум две записи, одна order, и одна или несколько trade. Есть еще желательное действие move, но о его вводе я уже не мечтаю.
* тип ордера - bid/ask, это направление сделки относительно ее иннициатора, конечно можно так же завести значение в справочнике или boolean
* идентификатор ордера - для событий trade, это идентификатор сделки, с которой произошло пересечение (сейчас у вас это order_id), для событий типа order это значение пусто или равно идентификатору события если ордер создается, а для событий отмены ордера - идентификатор отменяемого ордера
* объем события - для order это объем всей сделки, для cancel - объем остатка сделки, для trade - объем пересечения (собственно объем самой операции)
* цена сделки

Полный лог этих данных полностью самодостаточен и позволит восстановить состояние биржевого стакана и историю торгов на любой момент. Для оптимизации этого процесса можно выдавать периодические дампы (например раз в сутки) того же стакана.
Если вы не готовы выдавать его по websocket (но это надо, обязательно), сохраняйте в статических файлах, разбивая по интервалам времени (часы к примеру, а позже и на минуты), в этом случае трейдеры будут периодически загружать только маленький текущий файл. Нагрузка на статику, в отличии от динамически генерируемых данных, отлично горизонтально масштабируется, на их отдачу можно выделить несколько серверов, даже разнесенных географически, и только один файл должен отдаваться самой торговой платформой - текущий.
Если вы опасаетесь, что трейдеры получат излишнюю информацию об идентификаторах, то замените их на новые - привязанные к ордер+цена, соответственно объедините ордера с одной ценой (cancel записи позволяют указать отмену части ордера).
Цены и объемы в виде целых чисел с фиксированной точностью, точность описывается так же в отдельном запросе к бирже (сделать один файл на бирже, описывающий список валютных пар, точности, значения идентификаторов и т.п.)

Про protobuf, люди, мы в каком веке? хватит уже роботам общаться в human readable форматах, кои на порядок более жрущие по ресурсам чем их бинарные аналоги, google protobuf есть чуть ли не под все популярные платформы и не только высокоффективный но и идеологически верный, неизменная логика, описывающая структуру данных, просто компилируется в виде классов на выбранном вами языке программирования.

p.s. я нечего не изобретаю, похожие логи выдают некоторые (или может даже все) мебанковские валютные биржи, только не всем клиентам, слишком этот поток тяжелый (я не согласен кстати, какие то гигабайты в месяц - ничто)

[vs2014]

Добавили возможность получения суточного объема.
Можно спросить у саппорта, как его запрашивать...

[hazarun]

Добавили возможность получения суточного объема.
Можно спросить у саппорта, как его запрашивать...

Вообще, это вроде стандартный запрос возвращает такие данные.
Или вы что то новенькое придумали ? Не хотелось бы....

А насчет саппорта, вроде и тему в разделе Кодеры завели специально,
что бы по 100 раз одними и теми же вопросами саппорт не грузить.

Тут и кодеры и очень хорошо если саппорт будет. Зачем ему куда то писать, не умно.
Потери времени. И у нас - и у вас.

Тут ведь не только саппорт может ответить, но и коллеги, что такой вопрос уже проработали.
Гораздо удобнее.
Не понимаю желания свести все в личную переписку.
Секретов  тут вроде нет никаких.

[vs2014]

Добавили возможность получения суточного объема.
Можно спросить у саппорта, как его запрашивать...

Вообще, это вроде стандартный запрос возвращает такие данные.
Или вы что то новенькое придумали ? Не хотелось бы....

А насчет саппорта, вроде и тему в разделе Кодеры завели специально,
что бы по 100 раз одними и теми же вопросами саппорт не грузить.

Тут и кодеры и очень хорошо если саппорт будет. Зачем ему куда то писать, не умно.
Потери времени. И у нас - и у вас.

Тут ведь не только саппорт может ответить, но и коллеги, что такой вопрос уже проработали.
Гораздо удобнее.
Не понимаю желания свести все в личную переписку.
Секретов  тут вроде нет никаких.

OK.
Информация отдается в тикере. В ответе добавлено поле.

[vvu351]

У нас есть стандартный API для торговых роботов, совместимый с BTC-e.
Будем рады услышать ваши вопросы и предложения, и с еще большой радостью на них ответим!

Совместимость с АПИ BTC-e отсутствует. Провокация. Жаль.

https://btc-e.com/api/3/documentation#main

https://btc-e.com/api/3/ticker/btc_usd:
{
   "btc_usd":{
      "high":109.88,
      "low":91.14,
      "avg":100.51,
      "vol":1632898.2249,
      "vol_cur":16541.51969,
      "last":101.773,
      "buy":101.9,
      "sell":101.773,
      "updated":1370816308
   }
   ...
}


{
"ticker":
{
"online":true,
"high": 25451.7601,
"low":24910.1029,
"avg":25180.9315,
"vol":4036488.14986,
"vol_cur":178.52999851,
"last":25409.1700,
"last_change":2.7029,
"buy":25409.1700,
"sell":25100.9812,
"updated":1388266919,
"server_time":1388309961
}
}

[vs2014]

У нас есть стандартный API для торговых роботов, совместимый с BTC-e.
Будем рады услышать ваши вопросы и предложения, и с еще большой радостью на них ответим!

Совместимость с АПИ BTC-e отсутствует. Провокация. Жаль.

https://btc-e.com/api/3/documentation#main

https://btc-e.com/api/3/ticker/btc_usd:
{
   "btc_usd":{
      "high":109.88,
      "low":91.14,
      "avg":100.51,
      "vol":1632898.2249,
      "vol_cur":16541.51969,
      "last":101.773,
      "buy":101.9,
      "sell":101.773,
      "updated":1370816308
   }
   ...
}


{
"ticker":
{
"online":true,
"high": 25451.7601,
"low":24910.1029,
"avg":25180.9315,
"vol":4036488.14986,
"vol_cur":178.52999851,
"last":25409.1700,
"last_change":2.7029,
"buy":25409.1700,
"sell":25100.9812,
"updated":1388266919,
"server_time":1388309961
}
}

---

С "версией 3", действительно отсутствует. Совместимо с той версией, которая здесь опубликована:
https://btc-e.com/api/documentation

[vvu351]

У нас есть стандартный API для торговых роботов, совместимый с BTC-e.
Будем рады услышать ваши вопросы и предложения, и с еще большой радостью на них ответим!

Совместимость с АПИ BTC-e отсутствует. Провокация. Жаль.
https://btc-e.com/api/3/documentation#main
https://btc-e.com/api/3/ticker/btc_usd:

С "версией 3", действительно отсутствует. Совместимо с той версией, которая здесь опубликована:
https://btc-e.com/api/documentation

В версии БТС-е АПИ 2 нет описания запроса ticker. Не так ли?
Такой запрос только в АПИ 3. Не ошибаюсь? Потому с АПИ 2 тоже не совместимо.

Не путайте народ.

[hazarun]

Добавлю.
В БТЦ-е АПИ 3 все запросы поддерживают несколько стаканов в запросе.
Например так:  https://btc-e.com/api/3/ticker/btc_usd-btc_eur

Планируете у себя такое делать ?

[mastero]

Коллеги, мы получили от вас запрос на создании отдельной ветки по API.
У нас есть стандартный API для торговых роботов, совместимый с BTC-e.

У меня собственно, те же самые вопросы для начала, что уже задавал в ваших ветках:

Совместимость с АПИ БТЦе вовсе не полная.

1. Не работало в АПИ2 ограничение количества ордеров в стакане по запросу стакана.
         На БТЦе - такое работает. На ГОК не работало.
         Получаю ордера тысячами, хотя мне нужен десяток ближайших. Пример приводил.

Просим любить и жаловать https://goc.io/api/btc_rur/depth/?25
Так, вы можете ограничивать количество получаемых строк в стакане.

[hazarun]

Просим любить и жаловать https://goc.io/api/btc_rur/depth/?25
Так, вы можете ограничивать количество получаемых строк в стакане.

Здорово.
А то уже пара стаканов с ГОК стали приходить медленнее чем 25 стаканов с БТЦе.   
Ща порежэм лишнюю инфу.

Еще бы стаканы по списку одним запросом выдавались, вообще экономично было бы.

[mastero]

Еще бы стаканы по списку одним запросом выдавались, вообще экономично было бы.

Примем во внимание, посмотрим, что сможем сделать.

[hazarun]

Еще бы стаканы по списку одним запросом выдавались, вообще экономично было бы.

Примем во внимание, посмотрим, что сможем сделать.

Есть просьба, не изобретать велосипед, если возможно, сделать как тут:
https://btc-e.com/api/3/documentation#main

[hazarun]

Просим любить и жаловать https://goc.io/api/btc_rur/depth/?25
Так, вы можете ограничивать количество получаемых строк в стакане.

Поставил ограничения.
Сетевой трафик уменьшился в десятки раз.

Если сделать все интересующие стаканы по списку в одном запросе -
еще в несколько раз уменьшится. Наверное.

[mastero]

Есть может у кого какие вопросы?
Может что-то упустили из виду?

[sonicby]

Сделайте в АПИ возможность получения истории например с транзакции по транзакцию. или с/по unixtime .