API неудачу часть II: BTC-E Faceplant

Это нелепо.

Все нормальные обмены дают вам какой-то ключ подписи в формате Base64. Вы поворачиваете те Base64 байт в байт, использовать их в качестве ключа подписи, вы сделали.

Некоторое время назад Bitfloor облажался по ошибке используя коды ASCII для строки в кодировке base64 вместо того, чтобы декодировать его. Ошибка, но понятно.

Теперь Btc-E был взят не на совершенно новый уровень: они дают вам ключ в качестве 256-битного числа, но не использовать его в качестве ключа. Нет, это было бы слишком легко. Вместо вы должны преобразовать, что 256-битное число в большой обратный порядок байт шестнадцатеричное число, затем вынести шестнадцатеричное число в ASCII, а затем использовать байты, что ASCII в качестве ключа. Я не выдумываю, человек. Я реализовал это таким образом, и это работает, и, кроме того делать это любой другой способ не работает. Кстати это также означает, что они не используют 93% ключевого пространства.

Я уже говорил, что ничего из этого не объясняется, или даже упомянул где-нибудь в BTC-E неадекватны документации по API?

В знак признания этого clusterfuck, настоящим отзыве "худшая награда API" от CryptoXChange и одарить его на BTC-E.

Это были мое информативным чтение дня. Благодарю.

Большое спасибо за информацию! Так что я должен буду изменить свою реализацию, а также ...

Btw: bitparking изменение это формат торговли вчера. Больше нет тип поля ....

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

Edit 1: Что касается API документации: в приведенных примерах работали в какой-то момент. Но так как апи изменилось, по крайней мере в 2 раза сезам то, что они будут наиболее явно потерпеть неудачу сейчас. Просто чтобы дать понять, что это не то вина из авторов исходного кода ...

Редактирование 2: кажется, что вы используете старую версию моих источников. Я мог видеть его от метода TradeApp getCurrentGMTTimeMicros (). Я установил довольно некоторые ошибки с тех пор, и добавлены новые возможности. Хотя иерархия порядка все еще неоптимальная (отозвать заказы еще ненужную цена в них в качестве примера).

Цитата: daybyter 02 ноября 2012, 12:25:09 PM

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

Цитата: crazy_rabbit 02 ноября 2012, 12:43:05 PM

Цитата: daybyter 02 ноября 2012, 12:25:09 PM

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

Это должно быть сделано, как 2 года назад.

У меня есть некоторые источники Java, что я готов открыть. Они являются неполными и есть некоторые проблемы, но, возможно, достаточно хорошо, как начать ...

Цитата: daybyter 02 ноября 2012, 12:53:29 PM

Я считаю, что важной частью является документация до реализации. Но это может быть начало, по крайней мере, для тех, кто устраивает Java ...

Цитата: crazy_rabbit 02 ноября 2012, 12:43:05 PM

Цитата: daybyter 02 ноября 2012, 12:25:09 PM

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

+1

Кроме того, если несколько обменов принял его себе представить, как удивительным было бы добавить поддержку для 2-го, 3-го, 4-го обмена к вашим услугам / приложение, просто добавив еще один URL & ключ.

И ОП .... это просто безумие.

Цитата: daybyter 02 ноября 2012, 12:25:09 PM

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

Я просто хотел бы задать один вопрос ко всем людям здесь, думая об обмене API стандартизации:

Почему бы не использовать существующий стандарт, как, например. Протокол FIX?

http://en.wikipedia.org/wiki/Financial_Information_eXchange

Теоретически это alrady есть все, что требуется.

Так каковы препятствия? Являются ли они технические или идеологическим? Может быть, программная архитектура несоответствие? Является ли FIX просто слишком сложно? Или FIX считается испорченной по какой-то причине?

Заранее спасибо за любой свет, который вы можете блистать на этот вопрос.

Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM

Почему бы не использовать существующий стандарт, как, например. Протокол FIX?

http://en.wikipedia.org/wiki/Financial_Information_eXchange

Теоретически это alrady есть все, что требуется.

MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий.

Цитата: MPOE-PR 02 ноября 2012 года, 3:24:39 PM

MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий.

Можете ли вы описать эти изменения в абзац или два? Было ли что-то отсутствует? Я actualy больше заинтересован в мотивации к изменениям, чем фактические изменения программного обеспечения.

Я хотел бы понять мотивы, если это возможно. Технические детали, которые я хотел бы рассмотреть вторичны.

Цитата: 2112 от 02 ноября 2012 года, 3:35:20 PM

Цитата: MPOE-PR 02 ноября 2012 года, 3:24:39 PM

MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий.

Ну давайте начнем с примера сравнения:

котировка

8 = FIX.4.2 | 9 = 178 | 35 = 8 | 49 = PHLX | 56 = PERS | 52 = 20071123-05: 30: 00,000 | 11 = ATOMNOCCC9990900 | 20 = 3 | 150 = E | 39 = E | 55 = MSFT | 167 = CS | 54 = 1 | 38 = 15 | 40 = 2 | 44 = 15 | 58 = PHLX EQUITY ТЕСТИРОВАНИЕ | 59 = 0 | 47 = C | 32 = 0 | 31 = 0 | 151 = 15 | 14 = 0 | 6 = 0 | 10 = 128 |

против

котировка

Дивидендная | B.MPCD.A | 35000000000 | 350000

FIX использует предопределенные тег, которые затем получают значение. Это замечательно, если большинство сообщений будет использовать только малую часть доступных тегов, потому что это экономит пространство. Однако, если большинство сообщений использовать большинство тегов быстро становится излишним. В более FIX-иш подходе выше строка MPEx бы прочитать

котировка

1 = ДИВИДЕНДНАЯ | 2 = B.MPCD.A | 3 = +35000000000 | 6 = 350000]

или что-то типа того. Поскольку подавляющее большинство сообщений будет ссылаться на тип действия (1) и MPSIC (2), большинство из них включают в себя значение (3), и лишь немногие используют более 4-5 полей, упрощенная схема представляется предпочтительным.

Стиль FIX позволит также для смешивания тегов, что-то MPEx не терпит. Преимущество что-то подобное, кажется, не стоит упоминания, однако (опять же из-за коротких сообщений).

FIX использует контрольные суммы и некоторые braindamaged реализации подписи. Мы обойтись без всего этого, полагаясь вместо этого на GPG ClearSign и бронированных зашифровать, который на самом деле, кажется гораздо лучшим решением.

Вы можете проверить Вопросы-Ответы для получения более подробной информации о протоколе MPEx.

Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM

Цитата: daybyter 02 ноября 2012, 12:25:09 PM

Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации.

BitFloor была шлюз FIX в течение нескольких месяцев. Я хотел бы связать вас с нашей документацией, но сервер отсутствует, потому что центр обработки данных потерял власть -> прошел в Нью-Йорке и шторм сделал серьезное количество ситуации с электроэнергией.

Если вернуться на сайте в ближайшее время.

Marketcetera использует FIX, я пытаюсь получить, что работать на моей машине сейчас, последний раз, когда я пытался мне не удалось, но на этот раз я, по крайней мере, некоторые его части работают.

Для графического интерфейса конечного пользователя использует http://www.marketcetera.org/confluence/display/PN/Photon который является частью я с трудом с. По-видимому, работает из коробки на Windows, но Linux его способность использовать более чем один вид базовых библиотек браузера для рендеринга вызывает конфликты, так что один они обеспечивают для Linux аварий и до сих пор так есть каждый я попытался собрать для себя ,

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

-MarkM-

Цитата: MarkM 02 ноября 2012, 11:20:56 PM

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

Для традиционного Finserv домов это редко является проблемой. В их очень конкурентен мире главная проблема, когда клиент не смог разместить сделку, когда он / она хочет. Кроме того, независимо от аутентификации используется на уровне протокола он никогда не будет одна линия обороны. Есть всегда некоторые другие формы инструментов мониторинга порядка потока отстает.

Для небольших долгожителей торги являются обратимыми и они застрахованы.

Для больших долгожителей есть виртуальные частные сети и выделенные соединения.

И в значительной степени все, большое или малое, может разместить заказ по аналоговой телефонной линии, в том числе беспроводного, где еще есть аналоговые беспроводной доступны.

Edit: также, FIX (и другие), ориентированный на соединение дает дополнительные меры контроля и безопасности.

Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM

Так каковы препятствия? Являются ли они технические или идеологическим? Может быть, программная архитектура несоответствие? Является ли FIX просто слишком сложно? Или FIX считается испорченной по какой-то причине?

Я думал, что то же самое! Тогда я начал изучать FIX. К сожалению, это катастрофа.

В худшем случае дизайн-по-комитета я когда-либо видел. Больше из Trainwreck чем все стандарты XML свернутых в один.

Я думаю, что мета-проблема здесь состоит в том, что FIX была создана крупными фирмами Уолл-стрит, а также для их найма десять программистов вместо одного, чтобы реализовать некоторые понапрасну-усложненной протокол не большая сделка. На самом деле, ИТ-менеджеры вроде как это потому, что он увеличивает размер их вотчину. Так, к сожалению, до Bitcoin организации в состоянии стандартизации такого рода вещи также был стимул, чтобы сделать это так сложно, как это возможно.

В принципе, я в пользу стандартизации, но если API разработан хорошо он должен действительно только вас 2-4 часа, чтобы написать плагин для него. Я предполагаю, что это одна из причин, почему я так склонен к разглагольствовать о дрянных API. Если обмен делает хорошую работу, тот факт, что нет никакого стандарта не является на самом деле что большая часть большой сделки.

Цитата: 2112 от 03 ноября 2012, 12:39:10 AM

И в значительной степени все, большое или малое, может разместить заказ по аналоговой телефонной линии, в том числе беспроводного, где еще есть аналоговые беспроводной доступны.

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

Теперь, вызов не записывается, но все же ... нет крипто, ничего. Йоу.

Цитата: eldentyrell от 03 ноября 2012, 10:11:29 AM

В худшем случае дизайн-по-комитета я когда-либо видел. Больше из Trainwreck чем все стандарты XML свернутых в один.

Это верно, но, как говорится, "он просто работает", Цена, кто знает, сколько сломаны пальцы сейчас.

Во всяком случае, учитывая интерес г-н P написал спецификацию немного, для этой вещи условно называемой BTC-UXP. Все комментарии более чем приветствуются.

Цитата: eldentyrell от 03 ноября 2012, 10:12:19 AM

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

Это сила "люди знают людей", Если вы выяснили, сколько из сегодняшних денег, политика и так далее движется по простым кивком и рукопожатие ....

Поскольку каждая часть Bitcoin и в основном веб использует JSON, было бы лучше подходит.

Просто установить некоторый протокол о том, как форматировать сообщения.

Цитата: ElectricMucus от 03 ноября 2012 года, 3:16:11 PM

Я inclinded согласиться с этим. Но только не любой JSON. JSON, используемый в страты и Stratum Mining. Г-н слякоть сделала хороший компромисс между простотой реализации и надежностью и масштабируемостью (энергоэффективностью) требованиями.

Так Stratum Торговый протокол будет большой краткосрочный выбор.

Это также является хорошим долгосрочным выбором, если ваша цель состоит в том, чтобы остаться в Bitcoin детский бассейн навсегда. Но если вы хотите, чтобы плыть семь морей через некоторое время вы будете иметь, чтобы узнать, какие протоколы ~~мореходные навигаторы~~ реальные трейдеры используют.

2 ноября 2012, 7:19:02 AM	# 1
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Это нелепо. Все нормальные обмены дают вам какой-то ключ подписи в формате Base64. Вы поворачиваете те Base64 байт в байт, использовать их в качестве ключа подписи, вы сделали. Некоторое время назад Bitfloor облажался по ошибке используя коды ASCII для строки в кодировке base64 вместо того, чтобы декодировать его. Ошибка, но понятно. Теперь Btc-E был взят не на совершенно новый уровень: они дают вам ключ в качестве 256-битного числа, но не использовать его в качестве ключа. Нет, это было бы слишком легко. Вместо вы должны преобразовать, что 256-битное число в большой обратный порядок байт шестнадцатеричное число, затем вынести шестнадцатеричное число в ASCII, а затем использовать байты, что ASCII в качестве ключа. Я не выдумываю, человек. Я реализовал это таким образом, и это работает, и, кроме того делать это любой другой способ не работает. Кстати это также означает, что они не используют 93% ключевого пространства. Я уже говорил, что ничего из этого не объясняется, или даже упомянул где-нибудь в BTC-E неадекватны документации по API? В знак признания этого clusterfuck, настоящим отзыве "худшая награда API" от CryptoXChange и одарить его на BTC-E.

2 ноября 2012, 11:45:11 AM	# 2
MPOE-PR Сообщения: 756 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Получил 1806 Биткоинов Реальная история. Это были мое информативным чтение дня. Благодарю.

2 ноября 2012, 12:25:09 PM	# 3
daybyter Сообщения: 965 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Большое спасибо за информацию! Так что я должен буду изменить свою реализацию, а также ... Btw: bitparking изменение это формат торговли вчера. Больше нет тип поля .... Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. Edit 1: Что касается API документации: в приведенных примерах работали в какой-то момент. Но так как апи изменилось, по крайней мере в 2 раза сезам то, что они будут наиболее явно потерпеть неудачу сейчас. Просто чтобы дать понять, что это не то вина из авторов исходного кода ... Редактирование 2: кажется, что вы используете старую версию моих источников. Я мог видеть его от метода TradeApp getCurrentGMTTimeMicros (). Я установил довольно некоторые ошибки с тех пор, и добавлены новые возможности. Хотя иерархия порядка все еще неоптимальная (отозвать заказы еще ненужную цена в них в качестве примера).

2 ноября 2012, 12:43:05 PM	# 4
crazy_rabbit Сообщения: 1176 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: daybyter 02 ноября 2012, 12:25:09 PM Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. +1

2 ноября 2012, 12:49:02 PM	# 5
ElectricMucus Сообщения: 1596 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: crazy_rabbit 02 ноября 2012, 12:43:05 PM Цитата: daybyter 02 ноября 2012, 12:25:09 PM Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. +1 Это должно быть сделано, как 2 года назад.

2 ноября 2012, 12:53:29 PM	# 6
daybyter Сообщения: 965 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant У меня есть некоторые источники Java, что я готов открыть. Они являются неполными и есть некоторые проблемы, но, возможно, достаточно хорошо, как начать ...

2 ноября 2012, 1:09:45 PM	# 7
ElectricMucus Сообщения: 1596 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: daybyter 02 ноября 2012, 12:53:29 PM У меня есть некоторые источники Java, что я готов открыть. Они являются неполными и есть некоторые проблемы, но, возможно, достаточно хорошо, как начать ... Я считаю, что важной частью является документация до реализации. Но это может быть начало, по крайней мере, для тех, кто устраивает Java ...

2 ноября 2012, 1:10:02 PM	# 8
TangibleCryptography Сообщения: 476 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: crazy_rabbit 02 ноября 2012, 12:43:05 PM Цитата: daybyter 02 ноября 2012, 12:25:09 PM Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. +1 +1 Кроме того, если несколько обменов принял его себе представить, как удивительным было бы добавить поддержку для 2-го, 3-го, 4-го обмена к вашим услугам / приложение, просто добавив еще один URL & ключ. И ОП .... это просто безумие.

2 ноября 2012, 2:53:55 PM	# 9
2112 Сообщения: 1988 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: daybyter 02 ноября 2012, 12:25:09 PM Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. Я просто хотел бы задать один вопрос ко всем людям здесь, думая об обмене API стандартизации: Почему бы не использовать существующий стандарт, как, например. Протокол FIX? http://en.wikipedia.org/wiki/Financial_Information_eXchange Теоретически это alrady есть все, что требуется. Так каковы препятствия? Являются ли они технические или идеологическим? Может быть, программная архитектура несоответствие? Является ли FIX просто слишком сложно? Или FIX считается испорченной по какой-то причине? Заранее спасибо за любой свет, который вы можете блистать на этот вопрос.

2 ноября 2012, 3:24:39 PM	# 10
MPOE-PR Сообщения: 756 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM Почему бы не использовать существующий стандарт, как, например. Протокол FIX? http://en.wikipedia.org/wiki/Financial_Information_eXchange Теоретически это alrady есть все, что требуется. MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий.

2 ноября 2012, 3:35:20 PM	# 11
2112 Сообщения: 1988 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: MPOE-PR 02 ноября 2012 года, 3:24:39 PM MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий. Можете ли вы описать эти изменения в абзац или два? Было ли что-то отсутствует? Я actualy больше заинтересован в мотивации к изменениям, чем фактические изменения программного обеспечения. Я хотел бы понять мотивы, если это возможно. Технические детали, которые я хотел бы рассмотреть вторичны.

2 ноября 2012, 9:34:12 PM	# 12
MPOE-PR Сообщения: 756 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: 2112 от 02 ноября 2012 года, 3:35:20 PM Цитата: MPOE-PR 02 ноября 2012 года, 3:24:39 PM MPEx род-начал оттуда, но изменения хранятся доводятся до точки, что мы используем сейчас едва напоминающий. Можете ли вы описать эти изменения в абзац или два? Было ли что-то отсутствует? Я actualy больше заинтересован в мотивации к изменениям, чем фактические изменения программного обеспечения. Я хотел бы понять мотивы, если это возможно. Технические детали, которые я хотел бы рассмотреть вторичны. Ну давайте начнем с примера сравнения: котировка 8 = FIX.4.2 \| 9 = 178 \| 35 = 8 \| 49 = PHLX \| 56 = PERS \| 52 = 20071123-05: 30: 00,000 \| 11 = ATOMNOCCC9990900 \| 20 = 3 \| 150 = E \| 39 = E \| 55 = MSFT \| 167 = CS \| 54 = 1 \| 38 = 15 \| 40 = 2 \| 44 = 15 \| 58 = PHLX EQUITY ТЕСТИРОВАНИЕ \| 59 = 0 \| 47 = C \| 32 = 0 \| 31 = 0 \| 151 = 15 \| 14 = 0 \| 6 = 0 \| 10 = 128 \| против котировка Дивидендная \| B.MPCD.A \| 35000000000 \| 350000 FIX использует предопределенные тег, которые затем получают значение. Это замечательно, если большинство сообщений будет использовать только малую часть доступных тегов, потому что это экономит пространство. Однако, если большинство сообщений использовать большинство тегов быстро становится излишним. В более FIX-иш подходе выше строка MPEx бы прочитать котировка 1 = ДИВИДЕНДНАЯ \| 2 = B.MPCD.A \| 3 = +35000000000 \| 6 = 350000] или что-то типа того. Поскольку подавляющее большинство сообщений будет ссылаться на тип действия (1) и MPSIC (2), большинство из них включают в себя значение (3), и лишь немногие используют более 4-5 полей, упрощенная схема представляется предпочтительным. Стиль FIX позволит также для смешивания тегов, что-то MPEx не терпит. Преимущество что-то подобное, кажется, не стоит упоминания, однако (опять же из-за коротких сообщений). FIX использует контрольные суммы и некоторые braindamaged реализации подписи. Мы обойтись без всего этого, полагаясь вместо этого на GPG ClearSign и бронированных зашифровать, который на самом деле, кажется гораздо лучшим решением. Вы можете проверить Вопросы-Ответы для получения более подробной информации о протоколе MPEx.

2 ноября 2012, 10:44:52 PM	# 13
shtylman Сообщения: 243 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM Цитата: daybyter 02 ноября 2012, 12:25:09 PM Я думаю, что мы должны сделать с открытым исходным кодом торговли LIB в качестве эталонной реализации. Я просто хотел бы задать один вопрос ко всем людям здесь, думая об обмене API стандартизации: Почему бы не использовать существующий стандарт, как, например. Протокол FIX? http://en.wikipedia.org/wiki/Financial_Information_eXchange Теоретически это alrady есть все, что требуется. Так каковы препятствия? Являются ли они технические или идеологическим? Может быть, программная архитектура несоответствие? Является ли FIX просто слишком сложно? Или FIX считается испорченной по какой-то причине? Заранее спасибо за любой свет, который вы можете блистать на этот вопрос. BitFloor была шлюз FIX в течение нескольких месяцев. Я хотел бы связать вас с нашей документацией, но сервер отсутствует, потому что центр обработки данных потерял власть -> прошел в Нью-Йорке и шторм сделал серьезное количество ситуации с электроэнергией. Если вернуться на сайте в ближайшее время.

2 ноября 2012, 11:20:56 PM	# 14
MarkM Сообщения: 2002 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Marketcetera использует FIX, я пытаюсь получить, что работать на моей машине сейчас, последний раз, когда я пытался мне не удалось, но на этот раз я, по крайней мере, некоторые его части работают. Для графического интерфейса конечного пользователя использует http://www.marketcetera.org/confluence/display/PN/Photon который является частью я с трудом с. По-видимому, работает из коробки на Windows, но Linux его способность использовать более чем один вид базовых библиотек браузера для рендеринга вызывает конфликты, так что один они обеспечивают для Linux аварий и до сих пор так есть каждый я попытался собрать для себя , Я рад слышать, что FIX имеет какие-то подписи, даже если "мозг умер", Так как я был обеспокоен тем, что реальные мировые финансовые институты, похоже, не беспокоиться о возможности когда-либо доказать, кто заказал то, что ... -MarkM-

3 ноября 2012, 12:39:10 AM	# 15
2112 Сообщения: 1988 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: MarkM 02 ноября 2012, 11:20:56 PM как я был обеспокоен тем, что реальные мировые финансовые институты, похоже, не беспокоиться о возможности когда-либо доказать, кто заказал то, что ... Для традиционного Finserv домов это редко является проблемой. В их очень конкурентен мире главная проблема, когда клиент не смог разместить сделку, когда он / она хочет. Кроме того, независимо от аутентификации используется на уровне протокола он никогда не будет одна линия обороны. Есть всегда некоторые другие формы инструментов мониторинга порядка потока отстает. Для небольших долгожителей торги являются обратимыми и они застрахованы. Для больших долгожителей есть виртуальные частные сети и выделенные соединения. И в значительной степени все, большое или малое, может разместить заказ по аналоговой телефонной линии, в том числе беспроводного, где еще есть аналоговые беспроводной доступны. Edit: также, FIX (и другие), ориентированный на соединение дает дополнительные меры контроля и безопасности.

3 ноября 2012, 10:11:29 AM	# 16
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: 2112 от 02 ноября 2012 года, 2:53:55 PM Так каковы препятствия? Являются ли они технические или идеологическим? Может быть, программная архитектура несоответствие? Является ли FIX просто слишком сложно? Или FIX считается испорченной по какой-то причине? Я думал, что то же самое! Тогда я начал изучать FIX. К сожалению, это катастрофа. В худшем случае дизайн-по-комитета я когда-либо видел. Больше из Trainwreck чем все стандарты XML свернутых в один. Я думаю, что мета-проблема здесь состоит в том, что FIX была создана крупными фирмами Уолл-стрит, а также для их найма десять программистов вместо одного, чтобы реализовать некоторые понапрасну-усложненной протокол не большая сделка. На самом деле, ИТ-менеджеры вроде как это потому, что он увеличивает размер их вотчину. Так, к сожалению, до Bitcoin организации в состоянии стандартизации такого рода вещи также был стимул, чтобы сделать это так сложно, как это возможно. В принципе, я в пользу стандартизации, но если API разработан хорошо он должен действительно только вас 2-4 часа, чтобы написать плагин для него. Я предполагаю, что это одна из причин, почему я так склонен к разглагольствовать о дрянных API. Если обмен делает хорошую работу, тот факт, что нет никакого стандарта не является на самом деле что большая часть большой сделки.

3 ноября 2012, 10:12:19 AM	# 17
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: 2112 от 03 ноября 2012, 12:39:10 AM И в значительной степени все, большое или малое, может разместить заказ по аналоговой телефонной линии, в том числе беспроводного, где еще есть аналоговые беспроводной доступны. Я был абсолютно поражен, когда я узнал, что $ 100 млн MBS сделки осуществляются с помощью голосового телефонного звонка. Теперь, вызов не записывается, но все же ... нет крипто, ничего. Йоу.

3 ноября 2012, 12:03:57 PM	# 18
MPOE-PR Сообщения: 756 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: eldentyrell от 03 ноября 2012, 10:11:29 AM В худшем случае дизайн-по-комитета я когда-либо видел. Больше из Trainwreck чем все стандарты XML свернутых в один. Это верно, но, как говорится, "он просто работает", Цена, кто знает, сколько сломаны пальцы сейчас. Во всяком случае, учитывая интерес г-н P написал спецификацию немного, для этой вещи условно называемой BTC-UXP. Все комментарии более чем приветствуются. Цитата: eldentyrell от 03 ноября 2012, 10:12:19 AM Я был абсолютно поражен, когда я узнал, что $ 100 млн MBS сделки осуществляются с помощью голосового телефонного звонка. Это сила "люди знают людей", Если вы выяснили, сколько из сегодняшних денег, политика и так далее движется по простым кивком и рукопожатие ....

3 ноября 2012, 3:16:11 PM	# 19
ElectricMucus Сообщения: 1596 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Поскольку каждая часть Bitcoin и в основном веб использует JSON, было бы лучше подходит. Просто установить некоторый протокол о том, как форматировать сообщения.

3 ноября 2012, 3:39:08 PM	# 20
2112 Сообщения: 1988 Цитировать по имени цитировать ответ	Re: API неудача части II: BTC-E Faceplant Цитата: ElectricMucus от 03 ноября 2012 года, 3:16:11 PM Поскольку каждая часть Bitcoin и в основном веб использует JSON, было бы лучше подходит. Просто установить некоторый протокол о том, как форматировать сообщения. Я inclinded согласиться с этим. Но только не любой JSON. JSON, используемый в страты и Stratum Mining. Г-н слякоть сделала хороший компромисс между простотой реализации и надежностью и масштабируемостью (энергоэффективностью) требованиями. Так Stratum Торговый протокол будет большой краткосрочный выбор. Это также является хорошим долгосрочным выбором, если ваша цель состоит в том, чтобы остаться в Bitcoin детский бассейн навсегда. Но если вы хотите, чтобы плыть семь морей через некоторое время вы будете иметь, чтобы узнать, какие протоколы ~~мореходные навигаторы~~ реальные трейдеры используют.

Заголовок