Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
3 марта 2011, 3:32:30 AM   # 1
 
 
Сообщений: 87
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Они, возможно, были обсуждены в другом месте, но я не мог найти ничего, связанное с поиском.

Насколько я понимаю из Bitcoin, он получает IP-адрес коллег из одного сервера (irc.lfnet.org). Если сервер не поддерживается упругим вычислительных ресурсов (EC2 или аналогичных), не вся сеть уязвимой к относительно слабой DDOS атаки? Кроме того, не развернув через один, центральный, сервер подорвать открытость и независимость Bitcoin?

Еще одна мысль: что, чтобы остановить злоумышленника от отправки сотни микротранзакциями засорять сети? Он мог либо отправить сделки .0000001 BTC и оплатить BTC плата за сделку с .01 (будет это увеличение приоритета транзакций за что свободной .01 сделки BTC?) Или отправить сделки .01 BTC (бесплатно за транзакцию, а также он может держать это до бесконечности с помощью многократного использования монет, которые он получает по каждой сделке). Я оцениваю из номеров на первой странице blockexplorer.com, что среднее число транзакций в блоке 20. Если предположить, что это занимает максимум 24 часов для сделки, чтобы попасть в блок (для повторного использования злоумышленником), злоумышленник может вызывать другие сделки с одинаковым приоритетом быть задержаны в два раз со вторым подходом менее чем за 30 BTC (6 блоков в час, 24 часов, 20 транзакций в блок, 0,01 BTC за транзакцию) в капитале.
theboos сейчас офлайн Пожаловаться на theboos   Ответить с цитированием Мультицитирование сообщения от theboos Быстрый ответ на сообщение theboos


Как заработать Биткоины?
Без вложений. Не майнинг.


3 марта 2011, 3:39:45 AM   # 2
 
 
Сообщения: 1246
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Получил 1806 Биткоинов
Реальная история.





Я не думаю, что уже подключены ровесники будут иметь какие-либо проблемы, если IRC пошел вниз. И я считаю, что есть некоторые жестко закодированные резервные сверстники, чтобы получить новых клиентов в петле.
FreeMoney сейчас офлайн Пожаловаться на FreeMoney   Ответить с цитированием Мультицитирование сообщения от FreeMoney Быстрый ответ на сообщение FreeMoney

3 марта 2011, 3:40:58 AM   # 3
 
 
Сообщений: 35
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Что-то вроде DHT бы неплохо реализовать в клиенте, хотя.
JesusTheCaffeine сейчас офлайн Пожаловаться на JesusTheCaffeine   Ответить с цитированием Мультицитирование сообщения от JesusTheCaffeine Быстрый ответ на сообщение JesusTheCaffeine

3 марта 2011, 3:51:37 AM   # 4
 
 
Сообщения: 1246
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Что-то вроде DHT бы неплохо реализовать в клиенте, хотя.

Вы имеете в виду возможность вручную ввести пэр для подключения к? Я думаю, что вы можете сделать это, просто не в графическом интерфейсе. Я никогда не имею, хотя, другие могут сказать больше.
FreeMoney сейчас офлайн Пожаловаться на FreeMoney   Ответить с цитированием Мультицитирование сообщения от FreeMoney Быстрый ответ на сообщение FreeMoney

3 марта 2011, 3:53:36 AM   # 5
 
 
Сообщения: 447
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Насколько я понимаю из Bitcoin, он получает IP-адрес коллег из одного сервера (irc.lfnet.org). Если сервер не поддерживается упругим вычислительных ресурсов (EC2 или аналогичных), не вся сеть уязвимой к относительно слабой DDOS атаки? Кроме того, не развернув через один, центральный, сервер подорвать открытость и независимость Bitcoin?

Как отмечает FreeMoney, есть узлы семян жестко закодированные для тех, кто хочет самонастройки без IRC. Вы можете запустить клиент с недокументированным "-noirc" флаг, чтобы проверить это.

С другой стороны, если вы можете найти IP-адрес одного узла в сети, вы можете самонастройки, запустив клиент с "-connect $ ф" а потом обмен пирами найти множество узлов для вас.
mndrix сейчас офлайн Пожаловаться на mndrix   Ответить с цитированием Мультицитирование сообщения от mndrix Быстрый ответ на сообщение mndrix

3 марта 2011, 4:11:58 AM   # 6
 
 
Сообщения: 1484
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Как отмечает FreeMoney, есть узлы семян жестко закодированные для тех, кто хочет самонастройки без IRC. Вы можете запустить клиент с недокументированным "-noirc" флаг, чтобы проверить это.

С другой стороны, если вы можете найти IP-адрес одного узла в сети, вы можете самонастройки, запустив клиент с "-connect $ ф" а потом обмен пирами найти множество узлов для вас.

Все совершенно верно ... хотя я думал, что было бы неплохо включить набор DNS самонастройки узлы, встроенные в Bitcoin клиента.

Давние члены сообщества с длинной безотказной работой узлов могут включать в своих DNS-имена хостов в этом списке. Изобретательные программисты могли заминировать addr.dat Bitcoin для адресов, и возвращать их в качестве DNS A записи.

jgarzik сейчас офлайн Пожаловаться на jgarzik   Ответить с цитированием Мультицитирование сообщения от jgarzik Быстрый ответ на сообщение jgarzik

3 марта 2011, 3:24:06 PM   # 7
 
 
Сообщения: 324
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета


Все совершенно верно ... хотя я думал, что было бы неплохо включить набор DNS самонастройки узлы, встроенные в Bitcoin клиента.

Давние члены сообщества с длинной безотказной работой узлов могут включать в своих DNS-имена хостов в этом списке. Изобретательные программисты могли заминировать addr.dat Bitcoin для адресов, и возвращать их в качестве DNS A записи.



Согласитесь ... Естественный выбор был бы список электронного кошелька провайдеров / обменов, которые должны быть до 24/7 по определению.

https://en.bitcoin.it/wiki/Category:EWallets

Cusipzzz сейчас офлайн Пожаловаться на Cusipzzz   Ответить с цитированием Мультицитирование сообщения от Cusipzzz Быстрый ответ на сообщение Cusipzzz

3 марта 2011, 4:39:30 PM   # 8
 
 
Сообщений: 87
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Что второй атаки? Существует не способ (что я знаю), чтобы отличить законную сделку от сделки спама. Стоимость атаки этого типа пропорциональна нормальный объем транзакций, средняя задержку интеграции транзакций (любые данные по этому?), И желаемому коэффициенту увеличения средней задержки.
theboos сейчас офлайн Пожаловаться на theboos   Ответить с цитированием Мультицитирование сообщения от theboos Быстрый ответ на сообщение theboos

4 марта 2011, 12:03:46 AM   # 9
 
 
Сообщений: 87
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

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

Непосредственная проблема, которую я вижу с этим является широко различными возможностями хэширования различного аппаратного обеспечения: многие клиенты имеют gigahash масштабных кластеров в то время как другие (в частности, мобильные клиенты) может иметь менее 1 Mhash / с. Это фактор 1000 так что это может быть невозможно найти трудности, которые сделают это достаточно дорого, чтобы посылать волны спам-транзакций, позволяя низким конечным клиентам завершить единичные сделки в короткий промежуток времени. Не говоря уже о том, что есть много законных крупных сделок (майнинг), которые при достаточной сложности занять несколько дней или дольше, чтобы очистить.

Что же, если бремя доказательства-из-работы был перенесен на приемном конце сделки? Вообще Bitcoins получены в нескольких крупных сделках и послал во многих. Розничные торговцы, которые будут получать меньшие сделки Bitcoin в больших количествах (mtgox и других бирж, торгов сайтов, электронных кошельков и т.д.), также, вероятно, установлены достаточно, чтобы иметь достаточную вычислительную мощность, чтобы принять их. Это также предотвратило бы деньги от выхода из экономики, идя в несуществующих или потерянные адреса.

Это лишь одна идея, чтобы противодействовать проблеме; была эта проблема уже рассматривалась или рассматривается?
theboos сейчас офлайн Пожаловаться на theboos   Ответить с цитированием Мультицитирование сообщения от theboos Быстрый ответ на сообщение theboos

4 марта 2011, 12:11:20 AM   # 10
 
 
Сообщения: 476
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

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

Непосредственная проблема, которую я вижу с этим является широко различными возможностями хэширования различного аппаратного обеспечения: многие клиенты имеют gigahash масштабных кластеров в то время как другие (в частности, мобильные клиенты) может иметь менее 1 Mhash / с. Это фактор 1000 так что это может быть невозможно найти трудности, которые сделают это достаточно дорого, чтобы посылать волны спам-транзакций, позволяя низким конечным клиентам завершить единичные сделки в короткий промежуток времени. Не говоря уже о том, что есть много законных крупных сделок (майнинг), которые при достаточной сложности занять несколько дней или дольше, чтобы очистить.

Что же, если бремя доказательства-из-работы был перенесен на приемном конце сделки? Вообще Bitcoins получены в нескольких крупных сделках и послал во многих. Розничные торговцы, которые будут получать меньшие сделки Bitcoin в больших количествах (mtgox и других бирж, торгов сайтов, электронных кошельков и т.д.), также, вероятно, установлены достаточно, чтобы иметь достаточную вычислительную мощность, чтобы принять их. Это также предотвратило бы деньги от выхода из экономики, идя в несуществующих или потерянные адреса.

Это лишь одна идея, чтобы противодействовать проблеме; была эта проблема уже рассматривалась или рассматривается?

Вы не понимаете, как Bitcoin работает.
Garrett Burgwardt сейчас офлайн Пожаловаться на Garrett Burgwardt   Ответить с цитированием Мультицитирование сообщения от Garrett Burgwardt Быстрый ответ на сообщение Garrett Burgwardt

4 марта 2011, 1:04:31 AM   # 11
 
 
Сообщений: 87
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Вы не понимаете, как Bitcoin работает.

Может быть, Я довольно новый. Не могли бы вы или кто-то еще объяснить мне, почему это не является потенциальной проблемой?
theboos сейчас офлайн Пожаловаться на theboos   Ответить с цитированием Мультицитирование сообщения от theboos Быстрый ответ на сообщение theboos

4 марта 2011, 2:43:03 AM   # 12
 
 
Сообщения: 447
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Насколько я понимаю приоритет транзакции, операции с монетами с более подтверждениями имеют более высокий приоритет. В ситуации, вы описываете, монеты атакующих (циклическое время назад и вперед), будет иметь низкий приоритет и не задержат обработки законных сделок, которые платят такую ​​же плату за транзакцию.

Похоже, что чистый эффект этой атаки будет требовать срочных сделок заплатить за операцию, но сеть будет продолжать обработку транзакций только штраф.
mndrix сейчас офлайн Пожаловаться на mndrix   Ответить с цитированием Мультицитирование сообщения от mndrix Быстрый ответ на сообщение mndrix

4 марта 2011, 11:03:33 AM   # 13
 
 
Сообщения: 476
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета

Вы не понимаете, как Bitcoin работает.

Может быть, Я довольно новый. Не могли бы вы или кто-то еще объяснить мне, почему это не является потенциальной проблемой?

Там нет никакого способа, чтобы положить бремя добычи на людей, которые хотят принять сделки. Сделки просто вещать по всей сети, и тот, кто генерирует блок с этой сделкой дает ему подтверждение. После 6 подтверждений, считается подтверждено.
Garrett Burgwardt сейчас офлайн Пожаловаться на Garrett Burgwardt   Ответить с цитированием Мультицитирование сообщения от Garrett Burgwardt Быстрый ответ на сообщение Garrett Burgwardt

4 марта 2011, 7:27:10 PM   # 14
 
 
Сообщения: 1246
Цитировать по имени
цитировать ответ
по умолчанию Re: Потенциальные уязвимости: зависимость от IRC и транзакций приоритета


Вы не понимаете, как Bitcoin работает.

Я предполагаю, что он не делает, но он к чему-то в любом случае. Обычно не существует никаких доказательств работы прилагается к сделке. Прикрепление платы деноминированной в Bitcoins, как прикрепление доказательства работы. И это окончательное решение по приоритетному вопросу.
FreeMoney сейчас офлайн Пожаловаться на FreeMoney   Ответить с цитированием Мультицитирование сообщения от FreeMoney Быстрый ответ на сообщение FreeMoney



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW