Я только начал технический документ, направленный на описывающем способ bitcoinica кодовые работает, как торговые работает и как один потенциально может настроить клон. Не стесняйтесь, чтобы помочь!
Это все Вот
|
14 июля 2012, 2:38:21 PM | # 1 |
Сообщения: 1372
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я только начал технический документ, направленный на описывающем способ bitcoinica кодовые работает, как торговые работает и как один потенциально может настроить клон. Не стесняйтесь, чтобы помочь!
Это все Вот |
14 июля 2012, 4:51:13 PM | # 2 |
Сообщения: 1708
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Получил 1806 Биткоинов
Реальная история. После количества душевных и финансовых потерь Bitcoinica причинил свои пользователь и широкой Bitcoin сообщества вы бы лучше выбросить и начать снова.
|
14 июля 2012, 5:30:13 PM | # 3 |
Сообщения: 1862
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
После количества душевных и финансовых потерь Bitcoinica причинил свои пользователь и широкой Bitcoin сообщества вы бы лучше выбросить и начать снова. На самом деле, нет. Код нужен аудит безопасности, но торговый код пристойно. |
14 июля 2012, 9:52:53 PM | # 4 |
Сообщения: 1372
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Начал тщательно изучать торговую часть, вот мое понимание кода квитовки.
Мои комментарии начинаются с "D:"Есть как 2 комментариев, сделанных ZT http://pastie.org/4257541 |
16 июля 2012, 6:11:30 AM | # 5 |
Сообщения: 1398
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность.
|
16 июля 2012, 11:07:13 AM | # 6 |
Сообщения: 565
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Ребята, я делаю маржинальную торговлю обмен на https://github.com/santacruz123/node-bitcoin-exchange
Это PostgreSQL \ NodeJS основе. согласование заказа осуществляется через SQL триггеры ... Я принимаю критику на ранних стадиях |
16 июля 2012, 3:33:49 PM | # 7 |
Сообщения: 1862
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность. Крутая история. Что делает рубин ненадежны / небезопасным? |
17 июля 2012, 9:53:17 PM | # 8 |
Сообщения: 2058
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Начал тщательно изучать торговую часть, вот мое понимание кода квитовки. не рубин есть что-то вроде перечислений? зачем делать медленные сравнения строк?Мои комментарии начинаются с "D:"Есть как 2 комментариев, сделанных ZT http://pastie.org/4257541 |
17 июля 2012, 10:11:29 PM | # 9 |
Сообщения: 1372
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Начал тщательно изучать торговую часть, вот мое понимание кода квитовки. не рубин есть что-то вроде перечислений? зачем делать медленные сравнения строк?Мои комментарии начинаются с "D:"Есть как 2 комментариев, сделанных ZT http://pastie.org/4257541 |
17 июля 2012, 10:57:55 PM | # 10 |
Сообщения: 1398
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность. Крутая история. Что делает рубин ненадежны / небезопасным? Вот некоторые причины, чтобы не сделать это в Ruby On Rails: 1.) Рубин на Rails является языком сценариев, построенный на вершине другого языка. Любые недостатки или ошибки в языке фундаментного могут распространяться на языке сценариев. Требуется время, чтобы зафиксировать эти изменения, пока не будет исправлена и составлена на языке Ruby. (PHP работает так же, где функции в PHP, в основном, обертки к функциям в других библиотеках.) 2.) Рубин на Rails не было вокруг до тех пор, как некоторые другие веб-языки. Это менее убедительно доказано. 3.) Есть меньше Ruby On Rails разработчиков, то другие языки. В случае с Bitcoinica, код был передан Intersango, который не имел опыта работы с Ruby On Rails. 4.) Рубин на Rails пытается писать код автоматически. Можно автоматически написанный код может быть пропущен. 5.) Там конкретные вопросы безопасности с RoR. (Я думаю, вы могли бы нагуглить.) |
18 Июля 2012, 11:10:08 AM | # 11 |
Сообщения: 262
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность. Крутая история. Что делает рубин ненадежны / небезопасным? Вот некоторые причины, чтобы не сделать это в Ruby On Rails: 1.) Рубин на Rails является языком сценариев, построенный на вершине другого языка. Любые недостатки или ошибки в языке фундаментного могут распространяться на языке сценариев. Требуется время, чтобы зафиксировать эти изменения, пока не будет исправлена и составлена на языке Ruby. (PHP работает так же, где функции в PHP, в основном, обертки к функциям в других библиотеках.) 2.) Рубин на Rails не было вокруг до тех пор, как некоторые другие веб-языки. Это менее убедительно доказано. 3.) Есть меньше Ruby On Rails разработчиков, то другие языки. В случае с Bitcoinica, код был передан Intersango, который не имел опыта работы с Ruby On Rails. 4.) Рубин на Rails пытается писать код автоматически. Можно автоматически написанный код может быть пропущен. 5.) Там конкретные вопросы безопасности с RoR. (Я думаю, вы могли бы нагуглить.) Позвольте мне пояснить, если я могу, как я думаю, что ты уволен рубин и рубин на рельсах, не признавая преимущества. Рубин динамический язык http://en.wikipedia.org/wiki/Dynamic_programming_language Rails является на основе архитектуры MVC для быстрой разработки веб-приложений. Архитектор Rails построен с использованием языка Ruby, и именно поэтому она называется Ruby On Rails. (ROR). Позвольте мне остановиться на некоторых моментах вы подняли. 1. Интерпретатор рубин написано в C Я считаю, это было примерно с середины 90-х годов и является стабильным и зрелым. 2. Архитектура Rails была примерно с 2005 года и находится в версии 3. полномочий большое количество сайтов, в том числе Twitter, GitHub, Scribd, Shopify и многое другое. 3. Есть много рубина на разработчиках рельсов, так что intersango не была, что набор навыков. 4. Rails динамически создает методы во время выполнения, так что вам не придется, можно утверждать, что это преимущество, как разработчик пишет меньше кода и, следовательно, может сделать меньше ошибок. 5. Там были конкретные проблемы безопасности с Rails. Они получают адреса быстро в моем опыте. Я разработки веб-приложений на протяжении более 12 лет, и RoR легко самый быстрый и лаконичный способ для создания веб-приложений, в моем опыте. |
18 июля 2012, 3:32:14 PM | # 12 |
Сообщения: 1862
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность. Крутая история. Что делает рубин ненадежны / небезопасным? Вот некоторые причины, чтобы не сделать это в Ruby On Rails: 1.) Рубин на Rails является языком сценариев, построенный на вершине другого языка. Любые недостатки или ошибки в языке фундаментного могут распространяться на языке сценариев. Требуется время, чтобы зафиксировать эти изменения, пока не будет исправлена и составлена на языке Ruby. (PHP работает так же, где функции в PHP, в основном, обертки к функциям в других библиотеках.) 2.) Рубин на Rails не было вокруг до тех пор, как некоторые другие веб-языки. Это менее убедительно доказано. 3.) Есть меньше Ruby On Rails разработчиков, то другие языки. В случае с Bitcoinica, код был передан Intersango, который не имел опыта работы с Ruby On Rails. 4.) Рубин на Rails пытается писать код автоматически. Можно автоматически написанный код может быть пропущен. 5.) Там конкретные вопросы безопасности с RoR. (Я думаю, вы могли бы нагуглить.) Позвольте мне пояснить, если я могу, как я думаю, что ты уволен рубин и рубин на рельсах, не признавая преимущества. Рубин динамический язык http://en.wikipedia.org/wiki/Dynamic_programming_language Rails является на основе архитектуры MVC для быстрой разработки веб-приложений. Архитектор Rails построен с использованием языка Ruby, и именно поэтому она называется Ruby On Rails. (ROR). Позвольте мне остановиться на некоторых моментах вы подняли. 1. Интерпретатор рубин написано в C Я считаю, это было примерно с середины 90-х годов и является стабильным и зрелым. 2. Архитектура Rails была примерно с 2005 года и находится в версии 3. полномочий большое количество сайтов, в том числе Twitter, GitHub, Scribd, Shopify и многое другое. 3. Есть много рубина на разработчиках рельсов, так что intersango не была, что набор навыков. 4. Rails динамически создает методы во время выполнения, так что вам не придется, можно утверждать, что это преимущество, как разработчик пишет меньше кода и, следовательно, может сделать меньше ошибок. 5. Там были конкретные проблемы безопасности с Rails. Они получают адреса быстро в моем опыте. Я разработки веб-приложений на протяжении более 12 лет, и RoR легко самый быстрый и лаконичный способ для создания веб-приложений, в моем опыте. Спасибо, что спасли мне время. Рубин рвет. Rails принимает имена. |
18 июля 2012, 5:10:53 PM | # 13 |
Сообщения: 1106
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Начал тщательно изучать торговую часть, вот мое понимание кода квитовки. не рубин есть что-то вроде перечислений? зачем делать медленные сравнения строк?Мои комментарии начинаются с "D:"Есть как 2 комментариев, сделанных ZT http://pastie.org/4257541 Я не могу говорить за Руби или что точный случай конкретно, но часто в современных языках сравнение строк гораздо быстрее, чем они выглядят. Например, типичная замена перечисления будет выглядеть следующим образом: Код: а = "Foo" если в == "Foo": делать вещи Хитрость заключается в том, что если строки являются неизменными, и короткие строки гарантированно иметь уникальные адреса памяти, а-== "Foo" сравнение фактически может быть реализован в виде прямого сравнения указателя, а не медленного сравнения строк. Это в основном так же быстро, как традиционное перечисление и на практике занимает столько же места. (Целые числа в структурах, как правило, не упаковываются) Конечно, сравнивая три буквы довольно быстро, а также, особенно в контексте интерпретируемого языка. FWIW, если я не ошибаюсь, строки Python работать таким образом, и это считается "вещий" использовать строки для замены перечислений. Преждевременная оптимизация является корнем всего зла. |
18 июля 2012, 5:24:47 PM | # 14 |
Сообщения: 1862
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Начал тщательно изучать торговую часть, вот мое понимание кода квитовки. не рубин есть что-то вроде перечислений? зачем делать медленные сравнения строк?Мои комментарии начинаются с "D:"Есть как 2 комментариев, сделанных ZT http://pastie.org/4257541 Я не могу говорить за Руби или что точный случай конкретно, но часто в современных языках сравнение строк гораздо быстрее, чем они выглядят. Например, типичная замена перечисления будет выглядеть следующим образом: Код: а = "Foo" если в == "Foo": делать вещи Хитрость заключается в том, что если строки являются неизменными, и короткие строки гарантированно иметь уникальные адреса памяти, а-== "Foo" сравнение фактически может быть реализован в виде прямого сравнения указателя, а не медленного сравнения строк. Это в основном так же быстро, как традиционное перечисление и на практике занимает столько же места. (Целые числа в структурах, как правило, не упаковываются) Конечно, сравнивая три буквы довольно быстро, а также, особенно в контексте интерпретируемого языка. FWIW, если я не ошибаюсь, строки Python работать таким образом, и это считается "вещий" использовать строки для замены перечислений. Преждевременная оптимизация является корнем всего зла. Рубиновые символы были бы предпочтительнее сравнения строк, но да, это действительно ненужная оптимизация. |
18 Июля 2012, 10:54:11 PM | # 15 |
Сообщения: 2058
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Хитрость заключается в том, что если строки являются неизменными, и короткие строки гарантированно иметь уникальные адреса памяти, а-== "Foo" сравнение фактически может быть реализован в виде прямого сравнения указателя, а не медленного сравнения строк. Это в основном так же быстро, как традиционное перечисление и на практике занимает столько же места. (Целые числа в структурах, как правило, не упаковываются) Конечно, сравнивая три буквы довольно быстро, а также, особенно в контексте интерпретируемого языка. FWIW, если я не ошибаюсь, строки Python работать таким образом, и это считается "вещий" использовать строки для замены перечислений. Преждевременная оптимизация может быть корень всех зол, но только если это делает код труднее читать, иначе замена строк с номерами состояния. Перечисления не снижает читаемость кода, так как он, по существу, такой же, как струны, (за исключением без кавычек). Во-вторых, перечислений являются превосходящий в строки, потому что они сильно типа проверяются, чтобы предотвратить неопределенное поведение, которое может возникнуть в результате опечаток. Кроме того, ИДА может распознавать перечисления и обеспечивает дополнительные функции, такие как завершение автоматического и обнаружение ошибок, что повышает производительность.Преждевременная оптимизация является корнем всего зла. |
18 Июля 2012, 11:09:53 PM | # 16 |
Сообщения: 109
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Я не рекомендую Ruby On Rails, но, возможно, логика может быть воссоздана в другом более надежном языке в дополнении к укрепляя безопасность. Крутая история. Что делает рубин ненадежны / небезопасным? Вот некоторые причины, чтобы не сделать это в Ruby On Rails: 1.) Рубин на Rails является языком сценариев, построенный на вершине другого языка. Любые недостатки или ошибки в языке фундаментного могут распространяться на языке сценариев. Требуется время, чтобы зафиксировать эти изменения, пока не будет исправлена и составлена на языке Ruby. (PHP работает так же, где функции в PHP, в основном, обертки к функциям в других библиотеках.) 2.) Рубин на Rails не было вокруг до тех пор, как некоторые другие веб-языки. Это менее убедительно доказано. 3.) Есть меньше Ruby On Rails разработчиков, то другие языки. В случае с Bitcoinica, код был передан Intersango, который не имел опыта работы с Ruby On Rails. 4.) Рубин на Rails пытается писать код автоматически. Можно автоматически написанный код может быть пропущен. 5.) Там конкретные вопросы безопасности с RoR. (Я думаю, вы могли бы нагуглить.) Я не уверен, если вы тролль Rails и пытаетесь распространить некоторые FUD, но я собираюсь прояснить некоторые вещи для вас. котировка 1.) Рубин на Rails является языком сценариев, построенный на вершине другого языка. Любые недостатки или ошибки в языке фундаментного могут распространяться на языке сценариев. Требуется время, чтобы зафиксировать эти изменения, пока не будет исправлена и составлена на языке Ruby. (PHP работает так же, где функции в PHP, в основном, обертки к функциям в других библиотеках.) Рубин на Rails не является языком сценариев. Это основа MVC построен на вершине Ruby. Так же, как и другие структуры, как CodeIgniter, Kohana, Yii, ASP.NET MVC 3, он направлен на обеспечение гибкого развития.Многие приложения были построены с ним. Такие сайты, как GitHub (в котором находится основной проект Bitcoin), Yellow Pages, Groupon, и большая часть последнего бедра Запускают компании используют его. котировка 2.) Рубин на Rails не было вокруг до тех пор, как некоторые другие веб-языки. Это менее убедительно доказано. Вы жили под скалой? http://rubyonrails.org/applicationsкотировка 3.) Есть меньше Ruby On Rails разработчиков, то другие языки. В случае с Bitcoinica, код был передан Intersango, который не имел опыта работы с Ruby On Rails. Общество & экосистема огромна. достаточно для многих компаний, чтобы использовать его большой, и на протяжении многих библиотек, которые будут написаны для него. https://github.com/rails/railsкотировка 4.) Рубин на Rails пытается писать код автоматически. Можно автоматически написанный код может быть пропущен. Он не писать код для вас. Это основа.котировка 5.) Там конкретные вопросы безопасности с RoR. (Я думаю, вы могли бы нагуглить.) Так же, как и любой другой Framework или язык, всегда будут существовать потенциальные уязвимости безопасности. Все они были быстро исправлены.Однако наличие уязвимостей, такие как XSS, инъекции SQL, CSRF атаки, то для разработчика, чтобы исправить их. Rails уже использует лучшие практики, так это практически невозможно просачиваться через для любого приложения. Вам не придется идти хвастаться своим посетителям, что вы используете "подготовлены заявления. |
18 Июля 2012, 11:20:47 PM | # 17 |
Сообщения: 1398
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Конечно, есть сайты, которые используют Rails, такие как Twitter. Основная причина, почему я говорю, что это менее убедительно доказано, потому что я не вижу очень много финансовых сайтов с использованием Rails.
Etrade, Ameritrade, Chase, Банк Америки, PayPal и т.д. не используют Rails. Но я готов дать Rails преимущество сомнения и может быть, я не прав на этот раз. |
18 Июля 2012, 11:21:14 PM | # 18 |
Сообщения: 1106
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Хитрость заключается в том, что если строки являются неизменными, и короткие строки гарантированно иметь уникальные адреса памяти, а-== "Foo" сравнение фактически может быть реализован в виде прямого сравнения указателя, а не медленного сравнения строк. Это в основном так же быстро, как традиционное перечисление и на практике занимает столько же места. (Целые числа в структурах, как правило, не упаковываются) Конечно, сравнивая три буквы довольно быстро, а также, особенно в контексте интерпретируемого языка. FWIW, если я не ошибаюсь, строки Python работать таким образом, и это считается "вещий" использовать строки для замены перечислений. Преждевременная оптимизация может быть корень всех зол, но только если это делает код труднее читать, иначе замена строк с номерами состояния. Перечисления не снижает читаемость кода, так как он, по существу, такой же, как струны, (за исключением без кавычек). Во-вторых, перечислений являются превосходящий в строки, потому что они сильно типа проверяются, чтобы предотвратить неопределенное поведение, которое может возникнуть в результате опечаток. Кроме того, ИДА может распознавать перечисления и обеспечивает дополнительные функции, такие как завершение автоматического и обнаружение ошибок, что повышает производительность.Преждевременная оптимизация является корнем всего зла. Смотри, в строго типизированного языка, я с вами согласен. Но Руби и Python динамически типизированный, что значительно уменьшают преимущества традиционных перечислений, потому что нет никакого механизма типа проверки их в любом случае. Заметим, однако, фактическое предпочтительным рубин перечисление подход, по-видимому символы - в качестве notme упоминалось, см http://stackoverflow.com/questions/75759/enums-in-ruby - которые в значительной степени неизменные строки с некоторым синтаксическим сахаром. (И, возможно, разделяет пространства имен) Тем не менее, используя строки может иметь смысл в некоторых случаях, например, взаимодействие с внешним кодом. Python пока что даже не имеет понятия символа. Является ли система динамической типизации правильный подход? Это очень сложный вопрос ... С одной стороны, помните, что печатая системы могут быть гораздо более сложным, чем простая модель C / C ++ в основном несовместимых типов. Посмотрите, как выведенный набрав Хаскеля, например. |
19 июля 2012, 4:23:30 AM | # 19 |
Сообщения: 109
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Конечно, есть сайты, которые используют Rails, такие как Twitter. Основная причина, почему я говорю, что это менее убедительно доказано, потому что я не вижу очень много финансовых сайтов с использованием Rails. Etrade, Ameritrade, Chase, Банк Америки, PayPal и т.д. не используют Rails. Но я готов дать Rails преимущество сомнения и может быть, я не прав на этот раз. Это, скорее всего, потому что, когда были построены бэкенды этих компаний, Rails не было виден, как жизнеспособный инструмент в то время. Rails был выпущен в 2004 году, и большинство из этих компаний были созданы до этого времени. Как примечание стороны, я не видел ни одного инцидента Bitcoinica, который возник из-за уязвимости в системе безопасности Rails или кода 17-летний разработчика. Хаки были связаны с почтовыми серверами инфраструктуры взломы (Linode) и общую тупость (исходный код, содержащий ключ API). Краткие обезжиренный в исходном коде, однако, я понимаю, код использует поплавки (.to_f), а не класс BigDecimal Руби. Это беспокоит меня, потому что поплавки склонны к ошибкам округления, BigDecimal идеально подходит для денежных операций, как он держит точность. |
19 июля 2012, 9:43:43 AM | # 20 |
Сообщения: 1372
цитировать ответ |
Re: Реверс-инжиниринг и документирование Bitcoinica
Как примечание стороны, я не видел ни одного инцидента Bitcoinica, который возник из-за уязвимости в системе безопасности Rails или кода 17-летний разработчика. Хаки были связаны с почтовыми серверами инфраструктуры взломы (Linode) и общую тупость (исходный код, содержащий ключ API). Эта. Также, пожалуйста, дайте троллям умереть. Часть меня кипит ботаники ярости, когда я вижу некоторые отсталые вещи, написанных о Ruby, или Rails, но я воздержусь от ответа, потому что это чистая потеря времени. Краткие обезжиренный в исходном коде, однако, я понимаю, код использует поплавки (.to_f), а не класс BigDecimal Руби. Это беспокоит меня, потому что поплавки склонны к ошибкам округления, BigDecimal идеально подходит для денежных операций, как он держит точность. Да, это является проблемой для меня. Мне все равно, если поплавки используются только для целей отображения (а не хранение), но она начинает беспокоить меня, когда я вижу их везде как знак разработчиков ленивости. |