Игровой биткойн путем создания миллионов кошельков [дубликат]

Что может помешать кому-то играть в систему и создавать миллионы кошельков, увеличивая шансы на случайные депозиты? По крайней мере, вы могли бы представить себе своего рода DOS-атаку, когда все адреса сгорают. Это кажется мне большим недостатком... сколько бы возможностей ни было, они не бесконечны.

Я слышал такие вещи, как: «Биткойн уже поддерживает OP_HASH256 в скрипте, поэтому было бы тривиально увеличить количество адресов, если бы это когда-либо стало проблемой». здесь - bitcointalk.org/index.php?topic=24268.0
Упражнение: оцените вероятность того, что в течение 5000 лет такая установка обнаружит коллизию с уже используемым адресом, даже если у каждого человека на планете есть 1 миллион адресов, содержащих монеты. Я думаю, вы обнаружите, что он намного меньше, чем вы ожидали. 2^160 — очень большое число.
Для идентификаторов это 34 символа, которые могут быть 0..9, a..z и A..Z. Это 64^34. Если бы вы могли выполнять 5000 в секунду, это =(64^34)/(5000*60*60*24*365*1E+51), чтобы получить 16 процентов адресов за год, работая полный рабочий день со 100 000 000 000 000 016 384 608 344 632 472 552 568 168 956 984 984 984 984 984 . Думаю, это решает. Кто-нибудь может проверить мою математику?
Одна вещь, которая следует из этого, заключается в том, что, поскольку адрес закодирован в Base58, основываясь на моей математике выше, это 2 ^ 40, а не 2 ^ 106 возможностей, как предполагают другие. Гораздо меньшее число.
Я не понимаю, где вы берете 2 ^ 40? Ваше 64 ^ 34 (= 2 ^ 204) немного велико для начала. Во-первых, 0-9,AZ,az — это 62 символа, а не 64; кроме того, 0,O,I,l исключены (во избежание визуальной путаницы), где мы получаем 58. Таким образом, 58^34 будет ближе, что примерно равно 2^199. Но не каждая строка из 34 символов является юридическим адресом; некоторые биты являются сетевыми байтами, а другие — контрольной суммой. На самом деле адрес формируется из 160-битного хеша открытого ключа, поэтому возможных адресов действительно ровно 2^160.
(В принципе, может случиться так, что некоторые 160-битные строки на самом деле не являются хэшем любого открытого ключа, поэтому число может быть немного меньше. Это невероятно маловероятно.)

Ответы (1)

Ничто никому не мешает это сделать. Однако я не думаю, что вы найдете много людей, которые согласятся с тем, что это «серьезный недостаток». Если это серьезный недостаток, то у каждой существующей системы есть тысячи серьезных недостатков. Когда вы говорите что-то вроде «независимо от того, сколько существует возможностей», вы участвуете в дикой спекулятивной фантазии.

Одна вещь, которая следует из этого, заключается в том, что, поскольку адрес закодирован в Base58, основываясь на моей математике выше, это 2 ^ 40, а не 2 ^ 106 возможностей, как предполагают другие. Гораздо меньшее число. Никто не подтвердил это мышление... Я ищу здесь исправление...
@роб это 2^160. Я не знаю, как вы получили 2 ^ 40. Кодировка тут ни при чем. Число сто — это одно и то же количество независимо от того, как вы его закодировали (как «100», как «сто», как «10x10» или что-то еще). И что важно, так это реальная математическая величина, а не то, как она закодирована.
Я утверждаю, что в конце концов все перегоняется по адресу, а адресов может быть только определенное количество. Чтобы увидеть, как я добрался до 2 ^ 40, просто прочитайте мои комментарии к исходному вопросу. Если на улице есть адреса, в которых может быть только две цифры, каждая от 0 до 9, до столкновения существует 10 ^ 2 возможностей. Это простой аргумент, но это правда. 2^160 основан на генерации пары ключей, но хэш уменьшает количество возможных результатов. Я хочу оказаться неправым. Пожалуйста, делайте это с чистой математикой, а не перефразируя, почему мы говорим, что это 2 ^ 160... адресное пространство не 2 ^ 160.
@rob Злоумышленнику не нужно атаковать конец, он может атаковать самое слабое место, которое находится посередине. Ваш аргумент верен только в том случае, если вы предполагаете, что нападающий идиот. Адресное пространство 2 ^160. Существует тривиально обратимое однозначное соответствие между каждым из 2^160 возможных хэшей и каждым возможным действительным адресом. Следовательно, существует 2 ^ 160 возможных допустимых адресов.
Назовите меня дремучим, но вот пример адреса: 1F2Tzu4W8iLEWaMZEHhRMwedD8Di9gvqxK. Это ровно 34 символа. Они могут быть только прописными или строчными буквами или цифрами, что дает 26 * 2 + 10 = 62 возможных на символ. Это 62^34. Можете ли вы сломать недостаток с помощью этой линии мышления? Подсказка: вы должны на мгновение выйти за рамки и подумать о вопросе со свежей точки зрения, а не зацикливаться на том, в чем вы уже уверены... потому что этот вопрос еще не был должным образом решен по номинальной стоимости. . (забудьте вводную математику и посмотрите на вывод)
Другой способ задать вопрос: «Как адрес, состоящий из 34 символов в диапазоне от 0 до 63, дает 2 ^ 160 возможных адресов?»
@rob Точно так же кодирование любого количества символов английского алфавита и пробелов может кодировать только десять однозначных чисел - существует только десять однозначных чисел. Есть только 2 ^ 160 160-битных хэшей. Поэтому любой механизм кодирования, который может кодировать их все, может кодировать ровно 2^160 хэшей.
Понял. Я пытаюсь заполнить пробел между 64 ^ 34 = 2 ^ 40 возможными значениями в 34-символьной строке фиксированной длины из 62 возможных символов и 2 ^ 160 возможных хеш-выходов. Я предполагаю, что мне что-то не хватает в моих параметрах строки фиксированной длины, но это еще не указано.
Исправление, оно меньше 62 символов. «Набор из 58 буквенно-цифровых символов, состоящих из легко различимых прописных и строчных букв (0OIl не используются)»
Я вижу, где я сделал простую математическую ошибку, уменьшив 58 ^ 34 до степени двойки, добавив не умножая показатели степени ... Биткойн-адрес достаточен, чтобы содержать 2 ^ 160 возможных хэшей: 58 ^ 34 — это 904 октодециллиона (60 десятичных знаков). цифр), а 2^160 — это 1 квиндециллион (49 десятичных цифр)... большее число соответствует байту версии и контрольной сумме.