- Если они подключены к машине, которая имеет бумажник, содержащий ключ исходного txOut, владелец которого они пытаются найти, что узел будет отключать их в качестве узла плохого поведения, потому что ключи, которые они предоставляют, не совпадают.
- Если они подключены к машине, которая не имеет бумажник, содержащий ключ к исходному txOut, что узел будет просто отказаться от сделки за счет предотвращения копейка подпора и без оплаты.
- Потому что они могут сказать, какая вещь случилась, они могут сказать, принадлежит ли узел в данный IP-адрес, или собственности, адрес, соответствующий исходному txOut.
TXN с недействительной подписью будет считаться недействительным для всех узлов. Все узлы проверка подписи txns и не будут ретранслировать недопустимую txns. Узел отправки недействительного txns будет рассматриваться как плохое поведение и будет запрещен. Поведение бумажника отличается от поведения узла. Узел должен ответить последовательно на основе того, что известно публично (независимо от того, что частные ключи находятся в местном бумажнике или даже если есть местный кошелек). Если это не так, то есть информация утечка ошибки. Был а «пенни потоп» ошибка в прошлом, но это не связано с недействительных подписей и был исправлен последовательно от v0.80 (плюс некоторые более ранние версии).
котировка
И он смотрит на меня, как узел, который неоднократно посылает ТЙ с инвалидом сделка [Так в оригинале] подпись, обрывается и DoS запрещен, и если отправитель пытается восстановить в любое время в течение следующих 24 часов, то соединение отвергается.
В точку. Все узлы проверить txns перед тем ретрансляцию таким образом все узлы запретит узел отправляет TxN с недействительной подписью.
Полные узлы управляют многими пользователями не только шахтеров. Другими словами, каждый пользователь, который запускает ядро Bitcoin и открыл исходящие соединения работают полные узлы. Видеть https://getaddr.bitnodes.io.
Таким образом, если узел проверяет новый блок и отвергает его, что бы предотвратить распространение этого, не так ли? Так что, если (я только предполагаю здесь) типичный горняк подключается к 10 узлов при добыче, и эти узлы несут ответственность за вещание нового блока, чтобы все остальные, то только эти 10 узлов действительно должны были бы ID ложными сделки и не передать недопустимый блок вместе?
Спасибо за разъяснения, ребята!
Кроме того, в отношении другого вопроса:
есть ярлык для проверки каждого отправить адрес является реальным и имели средства?
Да.
Bitcoin делает использование "сокращенный",
В частности, не существует такого понятия, как "отправка адрес",
Вместо операция проводит и создавать неизрасходованные выходы, и каждый узел поддерживает индексированный список всех в настоящее время неизрасходованных выходов сделки (обычно называемого список UTXO).
Когда ты "получить биткойны по адресу", Что на самом деле происходит то, что сделка создает новые unspend выходов, которые обременены с требованием поставить сигнатуру ECDSA сгенерированную с определенным секретным ключом для того, чтобы эти неизрасходованные выходы, которые будут использоваться для финансирования будущей сделки.
Когда ты "отправить биткойны по адресу" Вы поставляете список неизрасходованных выходов, которые вы тратите, и действительную подпись для каждого из этих выходов. Каждый узел ищет их индексированную UTXO для каждого из неизрасходованных входов в транзакции. Если вы используете UTXO, что они не имеют в своем списке, то они не будут распространяться транзакции. Затем, когда каждый узел принимает блок, они проверяют каждую транзакцию в блоке таким же образом, как каждый вход транзакции проверяются по списку UTXO, он затем удаляются из списка, а также любые новые выходы, создаваемые транзакции будут добавлены к UTXO.
Таким образом, вы не можете создать транзакцию "1MickeyMouse34fg4 ... отправка 10000 BTC в 1YVEndj8D ...", Вы должны создать сделки:
- Список входов, узлы найти в их UTXO
- Допустимые Подписи для каждого входа
- Список мероприятий, созданных сделки
- Сценарии для каждого вывода, которые описывают то, что требование, чтобы он был включен в качестве вклада в будущем
https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
котировка
5. Ведет счет DoS каждого подключенного пэра и отсоединяется от сверстников, которые посылают сообщения, которые не в состоянии соблюдать правила.
6. Баны IP-адреса, которые плохо себя ведут в течение промежутка времени (24 часов по умолчанию)
7. Использование кэша сигнатур для предотвращения атак, которые пытаются постоянно инициировать повторную проверку хранимых операций бесхозных (защищает от атака)
8. Ограничение количества сохраненных подписей в кэше сигнатуры (50000 подписей по умолчанию)
9. Пытается поймать все возможные ошибки в сделках до подписания проверка имеет место, чтобы избежать DoS-атаку на использовании процессора.
10. Штрафует пэров, которые посылают много дубликата / истекли / недействительно подписи / все предупреждения, так что они в конечном итоге получить запретили.
6. Баны IP-адреса, которые плохо себя ведут в течение промежутка времени (24 часов по умолчанию)
7. Использование кэша сигнатур для предотвращения атак, которые пытаются постоянно инициировать повторную проверку хранимых операций бесхозных (защищает от атака)
8. Ограничение количества сохраненных подписей в кэше сигнатуры (50000 подписей по умолчанию)
9. Пытается поймать все возможные ошибки в сделках до подписания проверка имеет место, чтобы избежать DoS-атаку на использовании процессора.
10. Штрафует пэров, которые посылают много дубликата / истекли / недействительно подписи / все предупреждения, так что они в конечном итоге получить запретили.
Пять вопросов:
А) Таким образом, я правильно сделать вывод, что bitcoind запрещает IP-адрес ("24 часов по умолчанию") Одноранговых узлов, которые слишком часто отправляют недействительные сделки подписи?
B) И я правильно сделать вывод о том, что не менее ресурсоемкий алгоритм для определения, что в противном случае действует сделки (т.е. имеет действительные UXTO и т.д.) имеют недопустимую подпись, кроме как расходовать ресурсы процессора для проверки подписи (который, по-видимому по заказу до 50000 проверок в секунду на поздней модели топ-оф-линии одного Intel CPU)?
C) Я правильно, что даже если подписи действительны, то стоимость проверки того, что остальная часть сделки является правильным не является незначительной, особенно если (Compact или только) Конфиденциальные сделки осуществляются?
D) Я правильно, что эфемерные, не полный узел пэров (а.к.а. пользовательские программы "клиенты") Подключаются к полному узловым сверстникам с целью представления операций в bitcoind пиринговой сети?
E) Если мои предположения A, B, C и D выше являются правильными, то я правильно сделать вывод о том, что (хотя выше стратегия, очевидно, приемлемая в настоящее время в текущем масштабе) существующая стратегия борьбы с DDoS в этом случае может быть потенциально недостаточный, когда количество клиентов подающих транзакций в сеть сверстников значительно возрастает в масштабе (например, в сценарии микро-операций), потому что это часто бывает, что несколько клиентов один и тот же IP-адрес [1]. Таким образом, ботнеты могут быть использованы для спама полных узлов на равноправной сеть с недействительными сделками (не только для увеличения необходимых ресурсов пика процессора, но и затопить полосу пропускания входящего подключения и / или пул потоков полных узлов), а затем, если bitcoind реагирует запрещая IP адреса тогда невинные пользователи могут быть запрещены тоже.
Afaics единственным полностью надежное решение (в масштабе) является либо иметь достаточно полные узлы для обработки пиковой нагрузки потенциального ботнета (и глобальной базы данных, так что действительные клиентам знать, какой полные узлы не заблокировали их IP-адрес, так что клиенты не имеют связаться множество людей полных узлов, пытающихся найти тот, где их IP-адрес не заблокирован), или иметь некоторый незначительный алгоритм ресурсов, чтобы определить, если подпись действительна, а затем блокировать на UTXO вместо IP-адрес. Один из способов я предполагается достичь последнего является то, что (по крайней мере, когда Stealth или Cryptonote адреса назначения не используются), то только плательщик знает открытый ключ его хэш, который был публично распределенный (т.е. UTXO относится к хэш адрес открытого ключа). Таким образом, раскрывая публичный адрес ключа является 3-4 порядка величины равна быстрее[2] проверить, что отправитель, вероятно, знает секретный ключ, а также. Предостережение, что это эвристический и он страдает от перехвата, пока опубликованная транзакция не распространилась, хотя это может быть исправлено с помощью Меркель дерево подписи, но преимущество скорости проверки падает до 1-2 порядка из-величины [3]. Если адрес назначения Stealth или Cryptonote используются, то перед плательщик знает публичный адрес ключа получателя платежа, таким образом, может привести к адресу получателя должен быть запрещен, хотя это может быть смягчено при наличии получателя платежа, оплатила себе и не отпускает товар или услугу, пока что дополнительный шаг завершен (это еще одна причина, мгновенные транзакции будут полезны). Но его последнее решение требует, чтобы UTXO (или общие входы к сделке) не содержит (всего) значений, которые настолько малы, такие, что лишаясь их (и тем более, если запреты эфемерны) в спаме-атаке является несущественной стоимостью спамера , Но это место требования на (Compact или только) Секретных сделки, что он должен быть в состоянии доказать, что выходы больше определенный порог, а не только больше, чем 0.
Тангенциально, если один думает Lightning Networks (LN) является решением для масштабирования, первый отметить, что LN требуется блок цепи масштабирования, а также (поскольку участники должны выполнить позволяет блокировать цепи сделок, и они могут быть мусора в пиковые скорости, которые требуют большой пиковой нагрузки масштабирование цепной блок). И afaics LN не может поддерживать впритык принцип анонимности, так и на практике для того, чтобы хорошо работать (малое время задержки, широкая шкала) сеть будет по сути крупные корпоративные серверы делают клей для пользовательских каналов, которые, таким образом, можно записать все ваши транзакции NSA стиль.
Мысли?
Изменить: Я не имею в виду податливость атаки.
| [1] | |
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
14 ноября 2015, 4:02:25 AM
|
# 2 |
Сообщения: 1246
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Получил 1806 Биткоинов
Реальная история. А) Таким образом, я правильно сделать вывод, что bitcoind запрещает IP-адрес ("24 часов по умолчанию") Одноранговых узлов, которые слишком часто отправляют недействительные сделки подписи? Он запрещает не только те узлы, которые посылают неверные операции подписи, но в общих узлах, которые посылают какой-либо недопустимого сообщения слишком часто. Это может быть недопустимыми блоки, слишком много версий сообщений, другие сообщения, не послав сообщение о версии, слишком много адреса в IP-адресе в адре сообщении, сообщения, которые являются слишком большими, дублирует / истекло / недопустимая подпись / независимо от предупреждения, и недействительные сделки ,B) И я правильно сделать вывод о том, что не менее ресурсоемкий алгоритм для определения, что в противном случае действует сделки (т.е. имеет действительные UXTO и т.д.) имеют недопустимую подпись, кроме как расходовать ресурсы процессора для проверки подписи (который, по-видимому по заказу до 50000 проверок в секунду на поздней модели топ-оф-линии одного Intel CPU)? Там нет другого способа проверить сделку, кроме проверки всего. Как только Bitcoin ядро находит что-то недопустимое, он остановит проверку таким образом, чтобы не тратить мощность процессора.C) Я правильно, что даже если подписи действительны, то стоимость проверки того, что остальная часть сделки является правильным не является незначительной AFAIK стоимость проверки не является особенно значимой.D) Я правильно, что эфемерные, не полный узел пэров (а.к.а. пользовательские программы "клиенты") Подключаются к полному узловым сверстникам с целью представления операций в bitcoind пиринговой сети? даE) Если мои предположения A, B, C и D выше являются правильными, то я правильно сделать вывод о том, что (хотя выше стратегия, очевидно, приемлемая в настоящее время в текущем масштабе) существующая стратегия борьбы с DDoS в этом случае может быть потенциально недостаточный, когда количество клиентов подающих транзакций в сеть сверстников значительно возрастает в масштабе (например, в сценарии микро-операций), потому что это часто бывает, что несколько клиентов один и тот же IP-адрес [1]. Таким образом, ботнеты могут быть использованы для спама полных узлов на равноправной сеть с недействительными сделками (не только для увеличения необходимых ресурсов пика процессора, но и затопить полосу пропускания входящего подключения и / или пул потоков полных узлов), а затем, если bitcoind реагирует запрещая IP адреса тогда невинные пользователи могут быть запрещены тоже. Bitcoind запретит любой узел, который отправляет его спам, независимо от числа пользователей этого IP-адреса. Это не займет много времени, bitcoind заметить спам и начать запрет на эти узлы плохо себя. Кроме того, bitcoind по умолчанию позволит только общее 125 соединений. Это число может быть сконфигурировано, чтобы быть более или менее пользователем.Afaics единственным полностью надежное решение (в масштабе) является либо иметь достаточно полные узлы для обработки пиковой нагрузки потенциального ботнета (и глобальной базы данных, так что действительные клиентам знать, какой полные узлы не заблокировали их IP-адрес, так что клиенты не имеют связаться множество людей полных узлов, пытающихся найти тот, где их IP-адрес не заблокирован), или иметь некоторый незначительный алгоритм ресурсов, чтобы определить, если подпись действительна, а затем блокировать на UXTO вместо IP-адрес. Один из способов я предполагается достичь последнего является то, что (по крайней мере, когда Stealth или Cryptonote адреса назначения не используются), то только плательщик знает открытый ключ его хэш, который был публично распределенный (т.е. UXTO относится к хэш адрес открытого ключа). Таким образом, раскрывая публичный адрес ключа является 4-5 порядков величины равна быстрее проверить, что отправитель, вероятно, знает секретный ключ, а также. Предостережение, что это эвристическое и он страдает от перехвата, пока опубликованная транзакция не распространилась, хотя это может быть закреплено с помощью одноразового Лампорта подписи. Если адрес назначения Stealth или Cryptonote используются, то перед плательщик знает публичный адрес ключа получателя платежа, таким образом, может привести к адресу получателя должен быть запрещен, хотя это может быть смягчено при наличии получателя платежа, оплатила себе и не отпускает товар или услугу, пока что дополнительный шаг завершен (это еще одна причина, мгновенные транзакции будут полезны). Но его последнее решение требует, чтобы UXTO (или общие входы к сделке) не содержит (всего) значений, которые настолько малы, такие, что лишаясь их (и тем более, если запреты эфемерны) в спаме-атаке является несущественной стоимостью спамера , Но это поставит требование о конфиденциальных сделок, что он должен быть в состоянии доказать, что выходы больше определенного порога, а не только больше, чем 0. Со вторым предложением, не будет ли это сделать возможным для злоумышленников существенно DoS чей-либо адрес? Они могут просто продолжать создавать недопустимые операции, связанные с этими адресами, которые затем вызывают фактический владелец этих адресов, чтобы быть не в состоянии провести его Bitcoin. |
|
|
|
|
14 ноября 2015, 4:42:58 AM
|
# 3 |
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
C) Я правильно, что даже если подписи действительны, то стоимость проверки того, что остальная часть сделки является правильным не является незначительной, особенно если (Compact или только) Конфиденциальные сделки осуществляются? AFAIK стоимость проверки не является особенно значимой. Стоимость проверки подписи является критически значимым, если запрет на является UTXO вместо IP. Если предположить, что запрет является UTXO (вместо того, чтобы запрещать по IP), которые были правильно подписанного для но иным способом включены в недействительной сделке ранее, запрет бесполезна, если стоимость проверки значительна больше, чем стоимость, чтобы проверить, если UTXO запрещен (потому что противник может просто отправить недопустимые операции подписи всегда, чтобы избежать UTXO запрещающий). Так что вопрос действительно зависит от того, является проблематичным IP запрещая в масштабе, который является проблемой, которую я поднял. E) Если мои предположения A, B, C и D выше являются правильными, то я правильно сделать вывод о том, что (хотя выше стратегия, очевидно, приемлемая в настоящее время в текущем масштабе) существующая стратегия борьбы с DDoS в этом случае может быть потенциально недостаточный, когда количество клиентов подающих транзакций в сеть сверстников значительно возрастает в масштабе (например, в сценарии микро-операций), потому что это часто бывает, что несколько клиентов один и тот же IP-адрес [1]. Таким образом, ботнеты могут быть использованы для спама полных узлов на равноправной сеть с недействительными сделками (не только для увеличения необходимых ресурсов пика процессора, но и затопить полосу пропускания входящего подключения и / или пул потоков полных узлов), а затем, если bitcoind реагирует запрещая IP адреса тогда невинные пользователи могут быть запрещены тоже. Bitcoind запретит любой узел, который отправляет его спам, независимо от числа пользователей этого IP-адреса. Это не займет много времени, bitcoind заметить спам и начать запрет на эти узлы плохо себя. Кроме того, bitcoind по умолчанию позволит только общее 125 соединений. Это число может быть сконфигурировано, чтобы быть более или менее пользователем. Таким образом, я поднял вопрос, который, как TX / с масштабом, то вероятность запрета невинного пользователя по IP-адресу увеличивается. Я спрашиваю ли запрещая по IP-адресу является надежной защитой от DDoS в масштабе. В порождающей сущности концептуализации, делать какие-либо функции по IP-адресу нарушает фундаментальный принцип конца в конец интернета. Afaics единственным полностью надежное решение (в масштабе) является либо иметь достаточно полные узлы для обработки пиковой нагрузки потенциального ботнета (и глобальной базы данных, так что действительные клиентам знать, какой полные узлы не заблокировали их IP-адрес, так что клиенты не имеют связаться множество людей полных узлов, пытающихся найти тот, где их IP-адрес не заблокирован), или иметь некоторый незначительный алгоритм ресурсов, чтобы определить, если подпись действительна, а затем блокировать на UTXO вместо IP-адрес. Один из способов я предполагается достичь последнего является то, что (по крайней мере, когда Stealth или Cryptonote адреса назначения не используются), то только плательщик знает открытый ключ его хэш, который был публично распределенный (т.е. UTXO относится к хэш адрес открытого ключа). Таким образом, раскрывая публичный адрес ключа является 3-4 порядка величины равна быстрее проверить, что отправитель, вероятно, знает секретный ключ, а также. Предостережение, что это эвристическое и он страдает от перехвата, пока опубликованная транзакция не распространилась, хотя это может быть закреплено с помощью одноразового Лампорта подписи. Если адрес назначения Stealth или Cryptonote используются, то перед плательщик знает публичный адрес ключа получателя платежа, таким образом, может привести к адресу получателя должен быть запрещен, хотя это может быть смягчено при наличии получателя платежа, оплатила себе и не отпускает товар или услугу, пока что дополнительный шаг завершен (это еще одна причина, мгновенные транзакции будут полезны). Но его последнее решение требует, чтобы UTXO (или общие входы к сделке) не содержит (всего) значений, которые настолько малы, такие, что лишаясь их (и тем более, если запреты эфемерны) в спаме-атаке является несущественной стоимостью спамера , Но это поставит требование о конфиденциальных сделок, что он должен быть в состоянии доказать, что выходы больше определенного порога, а не только больше, чем 0. Со вторым предложением, не будет ли это сделать возможным для злоумышленников существенно DoS чей-либо адрес? Они могут просто продолжать создавать недопустимые операции, связанные с этими адресами, которые затем вызывают фактический владелец этих адресов, чтобы быть не в состоянии провести его Bitcoin. На втором предложении, недействительно подписанные сделки не запретят с вовлеченной UTXO. |
|
|
|
|
14 ноября 2015, 4:36:17 PM
|
# 4 |
|
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Таким образом, я поднял вопрос, который, как TX / с масштабом, то вероятность запрета невинного пользователя по IP-адресу увеличивается. Я спрашиваю ли запрещая по IP-адресу является надежной защитой от DDoS в масштабе. В порождающей сущности концептуализации, делать какие-либо функции по IP-адресу нарушает фундаментальный принцип конца в конец интернета. Так, например, запрет на IP-адрес является несравнимым с анонимностью mixnets, такие как Tor. |
|
|
|
|
19 ноября 2015, 10:23:15 AM
|
# 5 |
|
Сообщения: 217
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Во-первых, анти-DDOS мера есть, чтобы предотвратить злоумышленнику использовать распределенную сеть Bitcoin для DOS сети. Там нет ничего, что вы можете сделать в источнике Bitcoin для предотвращения DDOS атак из ботнеты, которые находятся под контролем злоумышленника.
Я думаю, вы правы, с предположениями. Так же, как можно DDOS сети из ботнета с помощью атак усиления DNS вы можете также использовать протокол Bitcoin. Я думаю, что разработчики знают о них, и это в основном риск того, что сеть Bitcoin должен жить. Так же, как это всегда можно принести большую ферму серверов вниз с изощренной атаки DOS это, вероятно, также будет возможность DOS сети Bitcoin. Вопрос, если атакующие имеет пропускную способность, чтобы выдержать атаку на все узлы. Обратите внимание, что все полные узлы должны быть атакованы индивидуальны для атаки, которую вы описали. Я думаю, что нет значительно более быстрый способ отличить случайное число от действительной подписи за исключением проверки подписи. Запрет на основе IP-адреса является лучшим вариантом мог бы сделать, со всеми его недостатками. |
|
|
|
|
20 ноября 2015, 9:20:27 AM
|
# 6 |
|
Сообщения: 2366
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Есть способы затвердевают против этих attacks-- например требуют дорогостоящего военнопленного при подключении инициирующей стороной; но у них есть свои собственные расходы. (И только в некоторой степени полезны здесь, так как ботнеты также, как правило, имеют много центральных процессоров)
Отправка недопустимой подписи немедленно получить вас выгнали, даже с ботнетом (или по П) это существенно ограничивает оцените на поведение, даже без военнопленного. Мы не считаем этот вид атаки 1-го уровня отказ в обслуживании, так как это, и потому, что практически любой хост, который может быть атакован таким образом, может быть атакован через исчерпание пропускной способности атаки. Там раньше вариации этого были вы могли бы достичь много неудачных Проверяет на соединение; но мы исключили их. Существует широко развернуты контрмеры, в любом случае: Не принимать входящие подключения по высокой стоимости узлов. Вместо этого, запустить пару общественных узлов, на месте вы не заботитесь о том, AddNode тех. Для этой конкретной атаки вы можете также продолжить подключение к случайным узлам (хотя есть и другие атаки, которые делают его более предпочтительным, чтобы не делать этого и подключить только из доверенных и semitrusted узлов). Я считаю, что мы в конечном итоге реализовать военнопленный при соединении, хотя больше для других видов истощения ресурсов атак ... |
|
|
|
|
20 ноября 2015, 8:04:17 PM
|
# 7 |
|
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Так же, как можно DDOS сети из ботнета с помощью атак усиления DNS вы можете также использовать протокол Bitcoin. Хлеще, чтобы указать на то, что предотвращение DoS существует не только для защиты от DoS на всех узлах непосредственно, а также защита от использования узлов, чтобы атаковать друг друга (то есть усиление). Вот почему, вероятно, не может работать на узлы для обмена информации, на которой IPs они имеют banned- то есть, если мы сохраним идеал Satoshi о необходимости не использовать доверие (т.е. узлы считаются ненадежными еще консенсусом алгоритма дольше цепь, имеет математически ПР). Обратите внимание, что все полные узлы должны быть атакованы индивидуальны для атаки, которую вы описали. В ОП, я объяснил, или по крайней мере смутно намекал на мое созерцание пользователей, имеющих трудность в поиске узла, который может принять транзакцию, если ботнеты были успешными в получении IP-адреса популярного пользовательского МНПА запрещенного на многих узлах (возможно, IPv6 может смягчить это? ). Я упомянул там должны были бы быть какой-то глобальный способ посмотреть, какие узлы еще не запрещен, которые IP-адреса. Тогда что глобальная база данных могла бы, возможно, станет еще одним центром уязвимости. Я не совсем уверен, если это действительно практическое нападение. Я размышляла о том, как это может быть проблемой в большом масштабе, когда, например, когда человек на земле посылает 10 TX / с в сети. Я много думал о масштабировании, и поэтому я пытаюсь думать, как выдавать приоритеты трансформироваться в масштабе. Я думаю, что нет значительно более быстрый способ отличить случайное число от действительной подписи за исключением проверки подписи. Запрет на основе IP-адреса является лучшим вариантом мог бы сделать, со всеми его недостатками. Видимо подпись Меркель заказы-от величины быстрее, чем по проверке ECDSA. Таким образом, моя идея состоит в том, чтобы использовать подписи Меркель вместо ECDSA (поэтому повышенная потребность транзакций пространства может быть смягчена, так как необходимо зафиксировать блок цепь масштабирования так, как до нападения я обрисовал становится потенциально практичным). Для подписей анонимности, такие как конфиденциальная сделок, а также поставить подпись Меркель (секретный ключ может быть передан в ECDH), но с тем недостатком, что получатель должен respend к себе (чтобы сбросить закрытый ключ, так что получатель не знает его в случае плательщик имеет ботнет) до завершения сделки. |
|
|
|
|
20 ноября 2015, 9:12:44 PM
|
# 8 |
|
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Это действительно помогает услышать перспективу основных разработчиков, так можно узнать, что они думают, что я мог бы не заметить или ошибку в моем мыслительном процессе и выяснении.
Есть способы затвердевают против этих attacks-- например требуют дорогостоящего военнопленного при подключении инициирующей стороной; но у них есть свои собственные расходы. (И только в некоторой степени полезны здесь, так как ботнеты также, как правило, имеют много центральных процессоров) Да, я думал об этом тоже. Как я думаю, вы также косвенно упоминались выше, одна из проблем является то, что она может быть асимметричной атакой, если противник рассчитывает свои хэш в централизованном месте в штате Вашингтон или в Китае, где электричество стоит всего 2 - 4 цента за киловатт час (который я думаю, что можно взять в аренде, и я помню, как в прошлом, как вы упомянули дальнейшую экономическую асимметрию аренды по сравнению с вечной сетью hashrate, которая имеет различные амортизационные отчисления) и с использованием новейшего ASIC (и распределениями хэш по проводам к его ботам ). Если мы пытаемся поддерживать децентрализацию, то предполагается, что верификатор будет иметь меньше оптимальный доступ к этим двум ресурсным затратам. Также плательщики (пользовательский уровень и получатели, если им нужно попасть на полный узел, особенно для поиска их Stealth адресных сделок) имеют еще более высокую асимметрию затрат вычислений для военнопленных. Таким образом, за счет повышения стоимости достаточно высокий достаточно на противника, может быть, в каком-то гипотетическом сценарии вся сеть может быть DoS'ed. В действительности, это может походить на некоторых аспектах 51% атаки а. Обратите внимание, пожалуйста, не думайте, я приравнивая доказательство правильности работы для блока цепных решений с ПР для представления сделок, а просто признать некоторые концептуальные дублирования между ними. Отправка недопустимой подписи немедленно получить вас выгнали, даже с ботнетом (или по П) это существенно ограничивает оцените на поведение, даже без военнопленного. Но запрет является IP. IP-адреса другой конечный ресурс (по крайней мере, в IPv4 и способ интернет-провайдеры используют его). Если IP-адрес не подозревающие пользователей получить запрещен из-за этого, они начинают видеть Bitcoin как ненадежные или прерывистые. Опять же гипотетической в будущем масштабе, в котором большинство пользователей отправки микро-транзакций каждый час или минут. И как это масштабирование к худшему, если сеть Bitcoin также масштабирование в неправильном направлении к более централизованной, то я размышляла она становится более уязвимой к такой атаке. Мы не считаем этот вид атаки 1-го уровня отказ в обслуживании, так как это, и потому, что практически любой хост, который может быть атакован таким образом, может быть атакован через исчерпание пропускной способности атаки. Я также рассматривается этот момент, когда я писал ОП. Но двумя вы сравнили не являются симметричными угрозами по отношению друг к другу, потому что относительно небольшое количество пропускной способности может запретить большое количество IP-адресов в текущей схеме анти-DDoS Bitcoin в. Кроме того, чтобы эффективно бороться с приступами пропускной способности, необходимо переместить фильтрацию из многочисленных точек сети. Таким образом, если фильтрация ресурсоемкий, где стоимость электроэнергии и СИС амортизация значительные потенциальные факторы асимметрии (который, как вы знаете, это так и для ECDSA, а не только PoW используя алгоритм SHA), то есть потенциально меньше гибкости. Если противник не может пройти к пропускной способности канала фильтрации по периметру, то он переходит на недействительные подписи (или иначе), где вы должны запретить по IP-адресу, так что не правильно считать, что противник, который может вызвать проблемы с запрете на IP также будет иметь возможность вызвать проблемы с атакой пропускной способности. Это еще одна причина, я пытаюсь перевернуть асимметричный стоимость фильтрации, заставляя противника сжечь UXTO (и, как я сказал в ОП это требует минимального количества транзакций). Я уже думал, что через это глубоко я думаю (хотя у меня есть 0 опыт в области сетевых технологий и все это просто размышления в моей голове). Существует широко развернуты контрмеры, в любом случае: Не принимать входящие подключения по высокой стоимости узлов. Вместо этого, запустить пару общественных узлов, на месте вы не заботитесь о том, AddNode тех. Для этой конкретной атаки вы можете также продолжить подключение к случайным узлам (хотя есть и другие атаки, которые делают его более предпочтительным, чтобы не делать этого и подключить только из доверенных и semitrusted узлов). Я прочитал, что упомянул некоторые где, прежде чем я написал ОП. Но для множества причин выше (например, потерь идеала не полагаясь на доверии, централизованные системы легче атаковать, и в то числе моего ответа на johoe включая вопрос пользователей, находя незапрещенным общественный узел), я не думаю, что полностью решает проблему в масштабе. |
|
|
|
|
21 ноября 2015, 8:58:24 AM
|
# 9 |
|
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
(Возможно, IPv6 может смягчить это?) (По крайней мере, в IPv4 и то, как интернет-провайдеры используют его) IPv6 не будет решением, потому что он переворачивает проблему установить рендеринг стоимость IP-существу свободного, так что противник может теоретически обойти запрет на IP. Видимо подпись Меркель заказы-от величины быстрее, чем по проверке ECDSA. Таким образом, моя идея состоит в том, чтобы использовать подписи Меркель вместо ECDSA (поэтому повышенная потребность транзакций пространства может быть смягчена, так как необходимо зафиксировать блок цепь масштабирования так, как до нападения я обрисовал становится потенциально практичным). Для подписей анонимности, такие как конфиденциальная сделок, а также поставить подпись Меркель (секретный ключ может быть передан в ECDH), но с тем недостатком, что получатель должен respend к себе (чтобы сбросить закрытый ключ, так что получатель не знает его в случае плательщик имеет ботнет) до завершения сделки. Примечание для CN разовых кольцевых подписей, эти целевые хэш (для вывода сделки) должны быть направлены в общественные группировки (для кольца) до операции, которые будут участвовать в этом кольце подписаны. Обратите внимание, я имею в виду предустановки хэша, который может быть использован для входа в CN единовременного кольцо, когда он позже провел, без определения, какие открытый ключа в кольце будет подписывать в будущем (аналогично для CT + CN или ЧМТА + CN ). Таким образом, это требование для анти-DDoS бы ввести форму требования одновременности на CN одноразовых колец, которые могут быть зажатой (), как содержащий спам и в случае CoinJoin (и даже улучшение CoinShuffle). Как я доказывал в gmaxwell в его CoinJoin потоке в 2013 году, что в черном список нарушителей неработоспособно, если нет опорной точки, потому что именно точка добавления анонимности уничтожить любую точку отсчета (кроме ортогонального, таких как IP-адреса, которые как я уже объяснил в этой теме также несостоятельна в масштабе). Таким образом, я обеспокоен тем, что анонимность может быть несостоятельной. Как мы знаем, что анонимность является основой для permissionless взаимозаменяемости (обратите внимание, даже правительства имеют историю периодически декрет перед выданной наличностью как незаконные). Я думаю, что это было в общем случае на протяжении всех криптографических исследований я рассмотрел, что весь анонимный mixnets есть DoS уязвимость, если есть не какой-то идентифицировать несвободный ресурс прикрепить к каждому участию. Обратите внимание, если у нас есть эти древовидные хэш Меркель, которые должны быть подписаны на, то есть blacklistable несвободного ресурс (UTXO и предполагая доказательства минимальных значений для КТ или ЧМТА), которые не могут быть сорваны. Таким образом, если мы можем идентифицировать противника на неудачную mixnet, то мы можем конфисковать UTXO. CoinShuffle предлагает детерминированный алгоритм разоблачить противник (так что любой ресурс, совершенный с каждым открытым ключом может быть конфискован). Для группы смесей хешей я предложил выше, если каждый CN одноразовой транзакции кольца тратит бы претендовать на одно из хешей (который является хэш может быть использован, чтобы провести выходные данных, созданные которые проводят сделки), проблема заключается в том, что подписант могут «т знать, какие открытые ключи, чтобы включить в них кольце, потому что остается требование одновременности на знание множества колец, которые соответствуют набору хэш (без увязки каждого хеша с расходуемым открытым ключом, который будет разгромить всю точку CN кольцевых подписей ). Единственное решение, которое я мог колдовать, чтобы использовать CoinShuffle для создания группы хэш, где каждый открытый ключ участвующего соответствуют некоторому UTXO, которые могут быть конфискованы. [Edit: Другое решение, которое я рассмотрел, чтобы заставить CN разовые кольца всегда смешивать с определенным набором (например, путем их упорядочения в блок цепи), так что подписанты знать, какие открытые ключи расписаться независимо от группы хэшей , Что я указал (c.f. моих последних дискуссий с Шэнью-Нётером в теме Reddit для ссылок) требуется какой-либо способ предотвратить комбинаторное разоблачение. Таким образом, то группа хэш может быть больше, чем количество входных открытых ключей для кольца, но проблема в том, что противник может тогда спам списка хэш и если спамер должен связать UTXO с каждым представлением в список, а затем снова открытые ключи, связанные с хэш.] Таким образом, в то время как я считаю, что я опроверг мое беспокойство, что анонимность полностью несостоятельна, теперь я считаю, что чисто по цепочке Анонимность несостоятельна. Что я думаю, что было также очевиден из того факта, что CN единовременных кольца могут быть разоблачены, если злоумышленник может соотносить IP-адрес постоянных идентичностей. Так что, если мы должны сделать CoinShuffle любым способом (который также смешивает IP адреса, с транжир, поэтому мы не должны полагаться на ненадежных анонимности, предлагаемые Tor из I2P), то нет никаких причин, чтобы сделать CN разово кольцо signtures. Просто используйте CoinShuffle либо КТ или ЧМТ. Таким образом, отметим, что Zerocash всегда будет (и Monero есть, пока они не заменяют CN с CoinShuffle) несостоятельным. |
|
|
|
|
28 ноября 2015, 5:39:11 PM
|
# 10 |
|
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
[...] Единственное решение, которое я мог колдовать, чтобы использовать CoinShuffle для создания группы хэш, где каждый открытый ключ участвующего соответствуют некоторому UTXO, которые могут быть конфискованы. [...] Так что, если мы должны сделать CoinShuffle любым способом (который также смешивает IP адреса, с транжир, поэтому мы не должны полагаться на ненадежных анонимности, предлагаемые Tor из I2P), то нет никаких причин, чтобы сделать CN разово кольцо signtures. Просто используйте CoinShuffle либо КТ или ЧМТ. [...] Так что нам нужно неавтономную mixnet, такие как CoinShuffle, чтобы создать коррелированы (для участников ввода) набор хэшей, которые не могут быть застрявших или Spammed (как я уже объяснил эти хэши быть ключи анти-DDoS в UTXO из-за на порядки величины равна быстрее скорости верификации Лампорт / Merkel криптографической хэш-сигнатуру, чем эллиптической кривой ECDSA или EdDSA и особенно по сравнению с медленной скоростью подтверждения Конфиденциальные сделки), А также дополнительное преимущество запутывания соотношения IP-адреса участников входа к выходам датумам протокола, и CoinShuffle можно связать каждый выход транзакций с конкретным хэшем в группировке, так как она передается вместе, как другая запись в каждый выходной элемент данных в протоколе, но, хотя CoinShuffle может размаскировать открытые ключи ввода (связанный с UTXO ресурсом, которые могут быть запрещены, если DoS), который джемом или коррумпированным протоколом, она не может обеспечить гомоморфную сумма выходов равна суммой входов. Я не уверен, что можно построить гомоморфное GROUPWISE сумму входов и выходов без помех (DoS). Я помню, какое-то смутное (не до конца продумана w.r.t. заклиниванию?) Обсуждение этого в конфиденциальном Transactions потоке, но, по крайней мере, в случае Компактные Конфиденциальные сделки, это не кажется, как это было бы возможно, потому что каждый из входов и выходов пуха имеет к скоординированы для всей сделки, кто-то, кто знает все частные значения. Таким образом, кажется, что мы все еще должны Шен-Нётер Кольцо конфиденциальных операций (Или мой утверждал, пока еще не опубликованы Нулевые Сделки знаний которая объединяет одноразовые кольца с Компактные Конфиденциальные сделки). Так Меркель дерево (не Лампорт, потому что вы, возможно, придется подписать снова еще где, если экземпляр протокола не удается) подписывает хэш (ы) для ввода (ов) сделки, чтобы войти в протокол CoinShuffle, затем отпустите кольцо Конфиденциальные Транзакции (или нулевым знанием Сделки) сделки (наряду с новым выходным хэшем) коррелированно с IP-адресом и входы транзакций по протоколу CoinShuffle. В случае, когда все входы и выходы являются одинаковыми (которые часто могут быть в случае с микро-транзакций), то нет необходимости использовать гомоморфные суммы и одноразовые кольцевые подписи, и просто освободить незафиксированные (не скрытые значения) выходы коррелированы к хеш-подписи через CoinShuffle (или любой mixnet, которая определяет собой входной набор и может идентифицировать тех, кто заклинить его) протокол. Таким образом, чтобы исправить мое предварительное сообщение, я до сих пор утверждают, что "чисто на цепи Анонимность несостоятельна" w.r.t. потенциальные сценарии для DDoS на микро-транзакций масштабе, то есть ни кольца, ни Доверительные Сделки с нулевым Транзакции знаний может масштабировать микро-транзакций и остаются полностью автономный, так как они требуют некоторой интеграции с неавтономных mixnet, такими как CoinShuffle. Я вновь предполагаемую точку из upthread, что afaics не представляется возможным смешивать хэши автономно. Изменить: обратите внимание на одноразовые кольца должны смешивать операционные входы участников протокола CoinShuffle (а не системный mixnet, такие как Tor или I2P, который не определяет входной набор). Таким образом, обеспечивает соблюдение правила, что группа UTXO всегда должна смешиваться друг с другом. Это правило должно нормально быть исполнено так, что кольца не могут быть комбинаторно разоблачены, что-то я подробно объяснил в моей дискуссии Reddit с Шэнью-Нетером. Кроме того, поскольку все входы могут быть, таким образом, помечается как израсходованы, они могут быть сокращены из UTXO и, таким образом, исполнение не будут смешиваться снова, и, таким образом, предотвращаются комбинаторное разоблачение. Изменить # 2: недостатки дизайн, который имеет лучшее разделение-на-проблем (может быть использован с любым IP запутывания mixnet, такие как Tor или I2P) в 1-м раунде для всех участников подписать хэш (ы) для их ввода (ов) к набору ЕСС общественности ключи участников. Те, кто не подписывайте, не будут включены в следующий раунд, и если не хватает знака, то раунд 1 возобновляется дополнительных участников замещающих тех, кто не знаком. Тогда в 2-м раунда всех участников, которые подписали освободить их Кольцевые конфиденциальные сделки и сделки с нулевым знанием. Недостаток в том, что раунд 2 может быть спамом, потому что нет никакой связи между теми, кто принимает участие в 2-м раунде с теми, кто подписал в 1-м раунде. Я пытался придумать какой-нибудь способ избежать CoinShuffle для микро-транзакции анонимности, потому что это так медленно из-за несколько раундов сети связи. Единственное другое решение, я думал, это использовать метод CoinShuffle выше анонимно разбить свои выходы на мелкие кусочки, а затем провести эти крохи без гомоморфного значения укрытия и с помощью запутывания mixnet IP, таких как Tor или I2P. Untraceability и несвязываемость в основном сохраняются как метод CoinShuffle будет использоваться, чтобы объединить остатки снова (и затем снова перераспределить анонимные выходные кусочков). |
|
|
|
|
2 декабря 2015, 1:10:49 AM
|
# 11 |
|
Сообщения: 412
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
котировка По Johoe: Так же, как можно DDOS сети из ботнета с помощью атак амплификации DNS вы можете также использовать протокол Bitcoin. DNS использует UDP, так что источник IP можно подделать (отсюда усиление работает хорошо). Bitcoin использует TCP, как вы собираетесь усилить, используя его? котировка Таким образом, я поднял вопрос, что в качестве масштаба TX / с, то вероятность запрета невинного пользователя по IP-адрес увеличивается Это временно, они будут транслироваться на другие узлы, а также (это может быть что-то, кроме плохого сига, так это зависит от того, что клиенты будут распространять ее). Помимо серьезных недостатков реализации в основном программном обеспечении, я не вижу, как это может произойти случайно, или думаю, что это плохо для человека, производящего недействительные подписи. |
|
|
|
|
4 декабря 2015, 12:09:44 AM
|
# 12 |
Сообщения: 420
цитировать ответ |
Re: Защита от ботнетов DDoS недействительной (подписи или иным образом) сделок?
Я составляю документ, содержащие сводной все мои мысли и исследование по этому вопросу, который я буду публиковать в течение нескольких дней, которые я надеюсь, более когерентный на целостном характере вопросов. Afaics, многие факторы взаимосвязаны. Мой upthread Выяснение несколько рассеянное и отсутствуют некоторые из этих деталей.
Цитата: Johoe Так же, как можно DDOS сети из ботнета с помощью атак усиления DNS вы можете также использовать протокол Bitcoin. DNS использует UDP, так что источник IP можно подделать (отсюда усиление работает хорошо). Bitcoin использует TCP, как вы собираетесь усилить, используя его? Я считаю, что Johoe не имел в виду усиления посредством отражения внешнего по отношению к сети Bitcoin, а с помощью сети Bitcoin повторить некоторые спам для всех одноранговых узлов. Мой приход исследование документ будет объяснить это целостный вопрос более подробно. Например, если черный список не распространяется, то злоумышленник не имеет асимметричную стоимости для рассылки спама, поскольку злоумышленник может перейти на другую атаковать сверстник в сети после того, как запрет на другом узле. Тем не менее, если черный список распространяется это может быть формой усиления. Опять же дьявол кроется в деталях. Мой документ будет обсуждать детали. Цитата: TPTB_need_war Таким образом, я поднял вопрос, что в качестве масштаба TX / с, то вероятность запрета невинного пользователя по IP-адрес увеличивается Это временно, они будут транслироваться на другие узлы, а также (это может быть что-то, кроме плохого сига, так это зависит от того, что клиенты будут распространять ее). Помимо серьезных недостатков реализации в основном программном обеспечении, я не вижу, как это может произойти случайно, или думаю, что это плохо для человека, производящего недействительные подписи. Я думаю, вы пропустили мою точку зрения о нецелесообразности черных списков по IP-адресам в масштабе (а не мизерный масштаб Bitcoin как сейчас) в том, что невиновные плательщики (кто не подписали недопустимую сделку) могут в конечном итоге запрещены (даже временно ) и найти узел, где они не запрещены еще одна стоимости невинного плательщика. И для IPv6, IP-адреса не хватает, так что теоретически злоумышленник может иметь неограниченное число их перебрать, что делает IP черные списки бесполезно. |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.