Случае для перехода от 160 бит до 256 бит адреса Bitcoin

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

Разложение в ряд Тейлора экспоненциальной функции могут быть использованы для оценки вероятности столкновения следующим образом:

   р (п, д) = 1 - е^{-п (п - 1) / (2d)}

где п есть число хешей и d представляет собой общее число возможных хешей.

Учитывая хэш-функция размер ч в битах, а также ряд Bitcoin адресов генерируется 2^Икс это может быть упрощено следующим образом:

   р (п, д) = 1 - е^{-2^Икс(2^Икс - 1) / (2 (2^час))}

   = 1 - е^{-(2^2x - 2^Икс) / (2^{ч + 1})}

   = 1 - е^{-[2^2x/ (2^{ч + 1}) - 2^Икс/ (2^{ч + 1})]}

   = 1 - е^{-(2^{2x - ч - 1} - 2^{х - ч - 1})}

В рамках моей таблицы Excel для ч = 160 вероятность столкновения для различных значений х:

котировка

х р (2^Икс, 2¹⁶⁰)
83 1
82 0,999664537
81 0,864664717
80 0.39346934
79 0,117503097
78 0,030766766
77 0,007782062
76 0,001951219
75 0,000488162
74 0,000122063
73 3.05171E-05
72 7.62937E-06
71 1.90735E-06
70 4.76837E-07
69 1.19209E-07
68 2.98023E-08
67 7.45058E-09
66 1.86265E-09
65 4.65661E-10
64 1.16415E-10
63 2.91038E-11
62 7.27596E-12
61 1.81899E-12
60 4.54747E-13
59 1.13687E-13
58 2.84217E-14
57 7.10543E-15
56 1.77636E-15
55 0

Это дает интересный результат, после "используя" только 2⁸³ из наших 2¹⁶⁰ Bitcoins адреса мы почти наверняка будет иметь один или несколько адресов столкновений. На самом деле, мы действительно только хотим "израсходовать" около 2⁵⁵ Bitcoin адрес для того, чтобы сохранить вероятность столкновения очень близкую к нулю (в пределах функции оценки, мое упрощение и способности разрешения в таблице Excel).

Как быстро мы можем использовать или генерировать 2⁵⁵ адреса?

Ну как этот постинг в Проект коллайдер большой Bitcoin уже последовательно искали первые 2^52,19 Bitcoin адреса и находится на пути к поиску первые 2^54,46 адреса в течение года. Учитывая серьезные ресурсы для решения данной проблемы, на порядки более адресов могут быть сгенерированы и проверены в год.

Эта нить не о достоинствах или непредоставлении в LBC так будут удалены сообщения, связанные с LBC. Я использую только максимальную скорость генерации ключа в LBC в качестве примера того, как быстро ключи могут быть созданы.

До сих пор LBC была пиковую скорость генерации ключа примерно 2,5 х 10⁹ пары ключей в секунду. То есть о

(3,154 х 10⁷) (2,5 х 10⁹) = 7,885 × 10¹⁶

или приблизительно 2⁵⁶ ключевые пары в год.

Если бы мы должны были перейти от текущих 160 битого Bitcoin адреса в новую систему, которая бы в полной мере использовать все 256 бит для Bitcoin рассматривается ситуация намного лучше:

котировка

х р (2^Икс, 2²⁵⁶)
131 1
130 0,999664537
129 0,864664717
128 0.39346934
127 0,117503097
126 0,030766766
125 0,007782062
124 0,001951219
123 0,000488162
122 0,000122063
121 3.05171E-05
120 7.62937E-06
119 1.90735E-06
118 4.76837E-07
117 1.19209E-07
116 2.98023E-08
115 7.45058E-09
114 1.86265E-09
113 4.65661E-10
112 1.16415E-10
111 2.91038E-11
110 7.27596E-12
109 1.81899E-12
108 4.54747E-13
107 1.13687E-13
106 2.84217E-14
105 7.10543E-15
104 1.77636E-15
103 0

В этом случае мы должны иметь возможность безопасно использовать до 2¹⁰³ Bitcoin адреса, прежде чем столкновения будет проблемой.

Я думаю, что мы должны обсудить постепенный отказ от старого 160 битной Bitcoin адрес версию и заменить его новую 256 битную адресную версию.

Цитата: BurtW от 01 мая 2017 года, 4:53:00 AM

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

.........

В этом случае мы должны иметь возможность безопасно использовать до 2¹⁰³ Bitcoin адреса, прежде чем столкновения будет проблемой.

Еще одна интересная вещь: сколько частных ключей я должен проверить, чтобы получить все адреса? Есть "только" 2 ^ 160 адреса и 2 ^ 256 частных ключей, так что есть 2 ^ 96 частных ключей для каждого адреса.

котировка

Ожидаемое количество хэшей, пока все слоты хэш-таблице оккупированы. ожидаемый
количество элементов, необходимых, чтобы заполнить все слоты хэш-таблицы размера к между klnk + 1 / 2k и klnk + к.

# Закрытые ключи = # экспоната = п
# адреса = # слоты = к

Для того, чтобы получить все к = 2 ^ 160 адресов, достаточно использовать к * LNK + ключи к = 160 * 2 ^ 160 + 2 ^ 160 = 161 * 2 ^ 160 = 2 ^ (167.32).

Если вы используете только 2 ^ 160 частных ключей, вы будете иметь около 63% всех адресов:

котировка

Ожидаемое число пустых слотов в хэш-таблице. В хэширования п элементов в хэш-таблицу с
klocations, ожидаемое число пустых мест равно к (1-1 / к) ^ п.

Infact: # пустые местоположения (адреса никогда не генерируется) = 2 ^ 160 (1-1 / 2 ^ 160) ^ (2 ^ 160) = 2 ^ 160 * 1 / е = 0,37 * 2 ^ 160.

Вы можете найти другие интересные формулы, как это:

котировка

Ожидаемое число столкновений в хеширования. В хэширования п элементов в хэш-таблицу с
K местоположения, ожидаемое число столкновений п-к + к (1-1 / к) ^ п.

Вот --> https://math.dartmouth.edu/archive/m19w03/public_html/Section6-5.pdf

Цитата: BurtW от 01 мая 2017 года, 3:01:55 AM

Какова максимальная скорость генерации ключа у вас есть каждый записано, даже в течение короткого периода времени?

Я помню, около 2500 Mkeys / с.

Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM

Неа. Есть 2 ^ 97 частных ключей для каждого адреса. Доказательство остается математика.

котировка

Для того, чтобы получить все к = 2 ^ 160 адресов, достаточно использовать к * LNK + ключи к = 160 * 2 ^ 160 + 2 ^ 160 = 161 * 2 ^ 160 = 2 ^ (167.32).

Если вы используете только 2 ^ 160 частных ключей, вы будете иметь около 63% всех адресов:

Я обнаружил, что часто забывают клавишу 1 -> 2 адреса факт (если вычисления сжатой и несжатая pubkeys из privkey). Вы уверены, что вы считали, что?

Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM

Цитата: BurtW от 01 мая 2017 года, 3:01:55 AM

Я помню, около 2500 Mkeys / с.

Да - где-то между 2,3 - 2,5 Gkeys / s - интересная часть, что 1,9 Gkeys / с, что сделано одним человеком.

Цитата: rico666 от 01 мая 2017 года, 7:37:51 AM

Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM

Неа. Есть 2 ^ 97 частных ключей для каждого адреса. Доказательство остается математика.

Хорошо, ради меня простота не хочу говорить здесь о сжатых / несжатых ключах ...

Цитата: gmaxwell от 01 мая 2017 года, 10:57:32 AM

эта нить имеет много горячего воздуха, segwit p2wsh использует 256-битные хэши, и есть Формат 256bit адрес предложенный.

Является ли нить закончилась?

gmaxwell: Спасибо Грегу за ваш ответ. К сожалению, я случайно удалил свой пост в моем LBC удалить фест.

LBC: Эта нить никогда не должна была быть около LBC. Я хотел бы я никогда не говорил об этом вообще. Я пошел назад и удалил сообщения конкретно о достоинствах / недостатках LBC.

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

В частности, это математика представлена в OP правильной? Является ли это реальная проблема?

Есть только 2.100.000.000.000.000 satoshis.

Поэтому максимальное количество Bitcoins адресов, которые могут содержать значение в любой момент времени составляет лишь около 2⁵¹ и предполагает только один Satoshi за адрес.

В то время блок цепь содержит 2⁵⁵ сделки это будет где-то между петабайтом и Эксабайтом в размере. Таким образом, полный узел потребуется несколько петабайта диска для хранения всего блока цепи.

Цитата: BurtW от 01 мая 2017 года, 11:21:54 AM

Цитата: gmaxwell от 01 мая 2017 года, 10:57:32 AM

Скажем segwit не пройдет ... Мы бы нужно новое предложение, не так ли?

Кроме того, я думаю, что любой новый формат адрес должен быть полностью обратно совместим.

Цитата: BurtW от 01 мая 2017 г., 12:15:20 PM

Это умная точка! Если мы можем рассчитывать на то, что никогда не будет трудно вилки изменения этого всего, конечно.

Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне. Можно сказать, что это предназначалось, чтобы освободить место, но есть много других случаев, где много места было потрачено впустую. Например, факт публикации, в вводе транзакции, а также подпись в качестве открытого ключа является избыточной: можно восстановить открытый ключ подписи и сообщений, которое будет сохранить номер для ключа (256 бит в сжатом формат). Кроме того, странно иметь 256 битный хэш транзакций с: трудно думать, что нужно было бы 256 бит для транзакции, и только 160 бит для адреса.

Для меня было 2 возможные логические значения для размера адреса: 128 бит или 256 бит. 128 бит, потому что это характеристический уровень безопасности ECDS с 256-битными ключами; и 256 бит, потому что это полная энтропия в ключе. 160 бит странный компромисс. Идея, что могло бы быть задней дверью в SHA-256, и что RIPEMD-160, различного происхождения, может иметь другую заднюю дверь, но оба они вместе, "безопасно" звучит странно, и не хороший повод, чтобы изменить количество бит. Можно было бы использовать 2 раза RIPEMD-160 на 128 битовых частей 256 битовой хэш если бы это было проблемой, чтобы держать 256 бит.

Поскольку число satoshis составляет 2 ^ 51, на самом деле, не может, как вы справедливо указывают на то, никогда не будет больше, чем 2 ^ 51 действует UTXO в данный момент, так что 128 бит фактически будет достаточно; но, учитывая трату комнаты с 256 битными транзакциями хэша, и публикацию как подписи и ключа, сохраняя полную энтропию ключа с 256 разрядным адресом был бы максимально безопасным вариантом.

Если это не имеет непосредственное отношение к теме этой теме, например, тот факт, может в настоящее время быть только 3 транзакций в секунду, сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS, любые сообщения, которые заходят в "блок дебаты размера" территория будет немедленно удален. Есть достаточно темы о уже этой теме.

Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM

Это умная точка! Если мы можем рассчитывать на то, что никогда не будет трудно вилки изменения этого всего, конечно.

Предполагая, что мы будем придерживаться размера 64 битном для значения, сохранить Bitcoin колпачков 21 миллионов, и мы расширяемся до максимального количества знаков после запятой, предлагаемой 64-битового числом, мы могли бы с комфортом расширить разрешение на

2⁶⁴ = 18.446.744.073.709.551.616
= 2.100.000.000.000.000.000 "millisatoshis"

Таким образом, в 1000 или около 2¹⁰

Так что приведет к примерно 2⁶¹ адреса, содержащие millisatoshi каждый.

Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM

Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне.

Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

Цитата: jonald_fyookball от 01 мая 2017 года, 3:58:27 PM

Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM

Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

Да, я знаю, что эти аргументы, но они не держат воду (ну, они правильны, но ничего не оправдывает). Они в лучшем случае ответить на этот аргумент "почему Satoshi не использовал RIPEMD-160 в одиночку", Вопрос почему он не придерживаться только SHA-256, и сохранил 256 битный адрес. И если он действительно хочет, чтобы уменьшить число битов, от 256 до 160 (но почему на земле - чтобы сэкономить место, то зачем тратить много места в подписи + ключ?), Он может просто держать первые 160 бит хэш.

Давайте рассмотрим несколько аргументов, которые приведены здесь.
1) "взаимодействие между ECDS и хэш-функции", Это совершенно нелепо, так как при условии, что секретный ключ является случайным числом, открытый ключ случайное число тоже (есть биекция между обоими, то циклическая группа). Так что нет "взаимодействие" между случайным числом, и хэш-функции. Но если когда-либо был "смешно взаимодействие" между ECDS и функцией первой хэш (что не имеет смысла, так как я только что изложил: это случайное число), скажем, что он всегда дает один из 10 одинаковых хэшей, а затем приложени второй хэш-функция не собирается решить, на наоборот. Говоря о взаимодействии, с помощью каскадных вещей, вы можете только * увеличение * вероятность нежелательного взаимодействия.

2) "двойное хеширование, чтобы избежать атак расширения" в этом случае не является также странно, как оригинальный ключ всего 512 бит (в длинном формате) и, следовательно, нет необходимости в применении Merkle-Damgard, так как один единый блок хэш-примитив должен быть вызван, и там нет "расширение" возможное. Другими словами, это защита от вида атак, который совершенно не имеет значения в данном случае.

Но страннее всего они "защиты" заключается в следующем: Bitcoin позволяет адрес повторного использования. Это может быть запрещено в протоколе (а вторая сделка с тем же адресом в выходе будет недействительной, так же, как дважды провел вход недействителен). Но это не так. Таким образом, это супер пупер защиты из * общественности * ключ с свернутыми хэш, совершенно спорен, если ONE UTXO данного адреса проводится, потому что тогда открытый ключ известен. Все остальные UTXO одного и того же адреса (в различных сделок наиболее вероятно) имеют свой открытый ключ разоблачены, и только безопасность ECC защищает их, без хешей. Это удивительно странно, чтобы пройти через столько хлопот, чтобы избежать возможности открыть для себя открытый ключ от адреса, просто, чтобы позволить вам опубликовать этот открытый ключ для того же адреса, которые еще могут быть использованы в других UTXO.

Исторически не был оригинальный дизайн для отправки открытого ключа в качестве места назначения - не было хэша в оригинальном дизайне?

Затем, в целях экономии места, был добавлен весь хэширования на публичный адрес на вершине?

Это было мое понимание - что часто недостатков, когда речь идет об эзотерической истории.

Цитата: BurtW от 01 мая 2017 года, 4:51:47 PM

Насколько я понимаю, что есть дополнительные преимущества для хэширования Публичных. Например, если реализация бумажник был испорчен и использовал плохую K «значение».

Цитата: динофелис от 01 мая 2017 года, 4:15:04 PM

Цитата: jonald_fyookball от 01 мая 2017 года, 3:58:27 PM

Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM

Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

Я предполагаю, что они говорят, что с помощью unhashed открытого ключа, было бы более целесообразным разработать некоторые столкновения атаки, основываясь на его содержание, а не там быть небольшим числом возможных выходов. Имеет смысл на поверхности, как отказобезопасная предосторожность.

котировка

2) "двойное хеширование, чтобы избежать атак расширения" в этом случае не является также странно, как оригинальный ключ всего 512 бит (в длинном формате) и, следовательно, нет необходимости в применении Merkle-Damgard, так как один единый блок хэш-примитив должен быть вызван, и там нет "расширение" возможное. Другими словами, это защита от вида атак, который совершенно не имеет значения в данном случае.

Я не за тобой вообще. Почему «только 512 бит» сделать нападение расширение не работает? Я не глубоко понять, как работает эта атака, но почему бы нападение не возможно?

Цитата: BurtW от 01 мая 2017 года, 4:51:47 PM

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

1) если открытый ключ был опубликовано вместо его хэша, это не будет необходимо опубликовать его * второй раз * во время подписания: теперь люди публикуют первый хэш, а затем, открытый ключ при подписании. Если адрес был непосредственно открытым ключом, можно было бы выиграть хэш комнату, потому что не было бы никакой необходимости публиковать ключ РАЗА.

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

3) есть много другого "тратить комнаты" по сделке, и самое важное для меня является хэш 256 бит, указывающий транзакцию. Это слишком много. Существует также 32-битное число, указывающее "Выход номер сделки" как если сделки будут содержать 4 миллиарда выходов. Это неиспользуемое пространство.

На самом деле, повторное использование адреса является то, что делает "указывающий транзакцию" необходимо. Если адрес произошло только один раз, то не было бы никакой необходимости указать "сделка хэш": При условии, что адрес может соответствовать только одной прошлой выход, что выход (и соответствующая транзакция) будет однозначно определяться подписью (и, следовательно, соответствующий открытый ключ, и, следовательно, соответствующий адрес). Так что не было бы никакой необходимости, ни указать хэш транзакции (256 бит), сохраненные ни номер выхода (32 бит сохраняется).

Поэтому мне трудно представить, что 100 или так биты, сэкономленные на 160 битным кешем, вместо битового ключа 256, была серьезная причина.

Однако, тем не менее, есть очень хорошая причина, чтобы использовать хэш открытого ключа, который не публикуется. Это причина: если когда-либо крипто ECC не удается, один по-прежнему может использовать хэш-схему на основе сигнатур (даже если это просто переключиться на другую криптографическую систему подписи). "открытый ключ" является то "Секретный ключ" за хэш.

==> но эта схема не плачевно, если один имеет многократное использование одного и того же адреса, потому что если один использовал один из них в прошлом, то "Секрет открытого ключа" Теперь общественность.

Поэтому он смотрит на меня, что весь криптографической дизайн этого "Хешированный открытый ключ" это довольно грязный, даже если он работает. Всякий раз, когда один находит "дизайн обоснование" в одном направлении, есть что-то еще, что винты это:
1) победы комнаты на цепи -> ввернут тратить комнату в другом месте
2) защиты открытого ключа в случае ECC не удается -> ввинчивается адресным многократного использования возможных

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

Цитата: jonald_fyookball от 01 мая 2017 года, 5:38:03 PM

Я не знаю точно, что вы имеете в виду здесь. "взаимодействие между ECDS и хэш-функции" звучит совершенно странно, потому что это означало бы, что * inadvertedly * хэш-функция будет а) страдают от пониженного выходного пространства, если его входы открытые ключи ECDS или б) будет случайно обнажить закрытый ключ, или сделать это проще.
Оба аргумента не держат воду, потому что:
а) частный ключ является случайным числом, и отношений линии частного>Открытый ключ является биекция (экспоненцирование в циклической группе простого порядка) открытый ключ является столь же случайным, как любым случайным число, так что нет "состав" в открытом ключе.
б) если данный хеш-функция была решить случайно, даже частично, проблема дискретного логарифма ECDS, что было бы монументальное использовать !!

Я не спорил за помощью прямого открытого ключа (хотя можно было бы считать, что). Я приводил доводы в пользу использования SHA-256 хэш открытого ключа непосредственно, не направляя ее через RIPEMD-160 и использовать полные 256 хэш-бит.

котировка

Ну, атака расширения не имеет смысла здесь, по разным причинам, но атака расширения идет о том, когда один знает хэш данного документа. В конструкции Меркель-Damgard, документ, который будет хэшированного его разрезают на блоки по 512 битов, и хэш-выход первого блока подается в хэш-входом второго блока и так далее. Так что, если вы знаете, окончательный хэш, вы можете добавить блок с собственным содержанием, независимо от того, каково содержания Хешированного до этого момента, и использовать опубликованный хэш и новый блок, представить хэш документа, независимо от его был, прилагается с блоком.

Например, если был секретный текст дает целое объяснение плана битвы, были хэшируются (и вы не знаете, содержания), вы могли бы принять этот хэш, добавить блок из ваших пристрастий, например, говоря "PS: все вышеперечисленное неверно, атака состоится в полдень"И вы могли бы вычислить правильный хэш документа, с этим блоком, приложенным к нему. Это будет полностью изменить смысл документа, и вы по-прежнему быть в состоянии произвести правильный хэш.

Но когда хэширования ключа, там нет такого смысла присоединяя блок. Никто не будет смотреть на любом фальшивом сообщении с "больше вещей в нем не только оригинальном ключе", Кроме того, есть только один единственный вызов функции сжатия и Merkle-Damgard даже не используется для этого.

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

хорошо мы можем только догадываться, почему Satoshi разработан это таким образом. Если плохая кривое было выбрано для ECDSA да будет нарушено, но менее разбито на неиспользуемых адреса ... звучит как слабый аргумент, но может быть еще лучше, чем ничего? так я понимаю, что вы имеете в виду.

Я понимаю, что вы имеете в виду о 512 бит. Можно ли это как-то связано с тем фактом, что версия Публичных 512 несжатый, поэтому его безопаснее хэш его снова?

Цитата: BurtW от 01 мая 2017 года, 3:40:28 PM

сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS,

Я думаю, что вы не уловили реальную причину, по которой 256 бит адреса имеют важное значение. Любой N-битный адрес имеет только N / 2 бит защиты от столкновения, не так ли?

Так вот интересная атака: Вы даете мне свой Публичных, а затем я создаю мой Публичных для 2-из-2 (или какого-либо другого более сложного контракта), а затем мы платим получившийся адрес.

К сожалению. На заднем плане я ~ 2 ^ 80 работы и нашел адрес сталкивающихся которые не имеют ту же политику, и я использую его, чтобы украсть деньги.

2 ^ 80 много работы, но это не достаточно, чтобы считаться безопасным по современным стандартам.

Unrelated, это также дело, что многие хэш же старинные ripemd160 были значительно сломаны или существенно ослаблены.

Цитата: динофелис от 01 мая 2017 года, 5:39:04 PM

есть много другого "тратить комнаты" по сделке, и самое важное для меня является хэш 256 бит, указывающий транзакцию. Это слишком много. Существует также 32-битное число, указывающее "Выход номер сделки" как если сделки будут содержать 4 миллиарда выходов. Это неиспользуемое пространство.

Вы можете хранить транзакции, как вам нравится и negoiate с вашими коллегами, чтобы отправить их, как вам нравится, нет необходимости в пространстве, чтобы быть потрачены впустую, как продукт сериализации. Использование большего хэша это занимает больше ресурсов, но разница очень мала по сравнению с остальной частью сделки.

Цитата: gmaxwell от 01 мая 2017 г., 11:45:37 PM

Цитата: BurtW от 01 мая 2017 года, 3:40:28 PM

сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS,

Я не совсем понимаю. Вам нужно 2 ^ 80 работы, чтобы найти столкновение, то есть, чтобы найти 2 (новые) Пивная ключи хэш по тому же адресу. Но как это Порция в этом случае, потому что у меня нет свободного выбора * Публичного * контрагента? Я мог бы найти два разных ключа паба, что хэш-одному и тому же адресу, и использовать один из них в контракте, но то, что я сделал бы с другой?

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

EDIT: ах, я получил его: столкновение между ключом паба вы генерируете для фактического 2 - контракта 2, а другой паб ключом можно создавать, что приведет к тому же конечному адресу, но где вы освоите все условия, чтобы в конце концов, вы можете полностью удовлетворять условиям первого контракта, путем использования "доказательства" второй, при условии, что они приводят к тому же самому конечному хэшу. Да, на самом деле.

1 мая 2017, 4:53:00 AM	# 1
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru проблема рождения могут быть применены для оценки вероятности столкновения, учитывая размер хэш-функции. Разложение в ряд Тейлора экспоненциальной функции могут быть использованы для оценки вероятности столкновения следующим образом: р (п, д) = 1 - е^{-п (п - 1) / (2d)} где п есть число хешей и d представляет собой общее число возможных хешей. Учитывая хэш-функция размер ч в битах, а также ряд Bitcoin адресов генерируется 2^Икс это может быть упрощено следующим образом: р (п, д) = 1 - е^{-2^Икс(2^Икс - 1) / (2 (2^час))} = 1 - е^{-(2^2x - 2^Икс) / (2^{ч + 1})} = 1 - е^{-[2^2x/ (2^{ч + 1}) - 2^Икс/ (2^{ч + 1})]} = 1 - е^{-(2^{2x - ч - 1} - 2^{х - ч - 1})} В рамках моей таблицы Excel для ч = 160 вероятность столкновения для различных значений х: котировка х р (2^Икс, 2¹⁶⁰) 83 1 82 0,999664537 81 0,864664717 80 0.39346934 79 0,117503097 78 0,030766766 77 0,007782062 76 0,001951219 75 0,000488162 74 0,000122063 73 3.05171E-05 72 7.62937E-06 71 1.90735E-06 70 4.76837E-07 69 1.19209E-07 68 2.98023E-08 67 7.45058E-09 66 1.86265E-09 65 4.65661E-10 64 1.16415E-10 63 2.91038E-11 62 7.27596E-12 61 1.81899E-12 60 4.54747E-13 59 1.13687E-13 58 2.84217E-14 57 7.10543E-15 56 1.77636E-15 55 0 Это дает интересный результат, после "используя" только 2⁸³ из наших 2¹⁶⁰ Bitcoins адреса мы почти наверняка будет иметь один или несколько адресов столкновений. На самом деле, мы действительно только хотим "израсходовать" около 2⁵⁵ Bitcoin адрес для того, чтобы сохранить вероятность столкновения очень близкую к нулю (в пределах функции оценки, мое упрощение и способности разрешения в таблице Excel). Как быстро мы можем использовать или генерировать 2⁵⁵ адреса? Ну как этот постинг в Проект коллайдер большой Bitcoin уже последовательно искали первые 2^52,19 Bitcoin адреса и находится на пути к поиску первые 2^54,46 адреса в течение года. Учитывая серьезные ресурсы для решения данной проблемы, на порядки более адресов могут быть сгенерированы и проверены в год. Эта нить не о достоинствах или непредоставлении в LBC так будут удалены сообщения, связанные с LBC. Я использую только максимальную скорость генерации ключа в LBC в качестве примера того, как быстро ключи могут быть созданы. До сих пор LBC была пиковую скорость генерации ключа примерно 2,5 х 10⁹ пары ключей в секунду. То есть о (3,154 х 10⁷) (2,5 х 10⁹) = 7,885 × 10¹⁶ или приблизительно 2⁵⁶ ключевые пары в год. Если бы мы должны были перейти от текущих 160 битого Bitcoin адреса в новую систему, которая бы в полной мере использовать все 256 бит для Bitcoin рассматривается ситуация намного лучше: котировка х р (2^Икс, 2²⁵⁶) 131 1 130 0,999664537 129 0,864664717 128 0.39346934 127 0,117503097 126 0,030766766 125 0,007782062 124 0,001951219 123 0,000488162 122 0,000122063 121 3.05171E-05 120 7.62937E-06 119 1.90735E-06 118 4.76837E-07 117 1.19209E-07 116 2.98023E-08 115 7.45058E-09 114 1.86265E-09 113 4.65661E-10 112 1.16415E-10 111 2.91038E-11 110 7.27596E-12 109 1.81899E-12 108 4.54747E-13 107 1.13687E-13 106 2.84217E-14 105 7.10543E-15 104 1.77636E-15 103 0 В этом случае мы должны иметь возможность безопасно использовать до 2¹⁰³ Bitcoin адреса, прежде чем столкновения будет проблемой. Я думаю, что мы должны обсудить постепенный отказ от старого 160 битной Bitcoin адрес версию и заменить его новую 256 битную адресную версию.

1 мая 2017, 7:21:51 AM	# 2
arulbero Сообщения: 778 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Получил 1806 Биткоинов Реальная история. Цитата: BurtW от 01 мая 2017 года, 4:53:00 AM проблема рождения могут быть применены для оценки вероятности столкновения, учитывая размер хэш-функции. ......... В этом случае мы должны иметь возможность безопасно использовать до 2¹⁰³ Bitcoin адреса, прежде чем столкновения будет проблемой. Еще одна интересная вещь: сколько частных ключей я должен проверить, чтобы получить все адреса? Есть "только" 2 ^ 160 адреса и 2 ^ 256 частных ключей, так что есть 2 ^ 96 частных ключей для каждого адреса. котировка Ожидаемое количество хэшей, пока все слоты хэш-таблице оккупированы. ожидаемый количество элементов, необходимых, чтобы заполнить все слоты хэш-таблицы размера к между klnk + 1 / 2k и klnk + к. # Закрытые ключи = # экспоната = п # адреса = # слоты = к Для того, чтобы получить все к = 2 ^ 160 адресов, достаточно использовать к * LNK + ключи к = 160 * 2 ^ 160 + 2 ^ 160 = 161 * 2 ^ 160 = 2 ^ (167.32). Если вы используете только 2 ^ 160 частных ключей, вы будете иметь около 63% всех адресов: котировка Ожидаемое число пустых слотов в хэш-таблице. В хэширования п элементов в хэш-таблицу с klocations, ожидаемое число пустых мест равно к (1-1 / к) ^ п. Infact: # пустые местоположения (адреса никогда не генерируется) = 2 ^ 160 (1-1 / 2 ^ 160) ^ (2 ^ 160) = 2 ^ 160 * 1 / е = 0,37 * 2 ^ 160. Вы можете найти другие интересные формулы, как это: котировка Ожидаемое число столкновений в хеширования. В хэширования п элементов в хэш-таблицу с K местоположения, ожидаемое число столкновений п-к + к (1-1 / к) ^ п. Вот --> https://math.dartmouth.edu/archive/m19w03/public_html/Section6-5.pdf Цитата: BurtW от 01 мая 2017 года, 3:01:55 AM Какова максимальная скорость генерации ключа у вас есть каждый записано, даже в течение короткого периода времени? Я помню, около 2500 Mkeys / с.

1 мая 2017, 7:37:51 AM	# 3
rico666 Сообщения: 812 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM Еще одна интересная вещь: сколько частных ключей я должен проверить, чтобы получить все адреса? Есть "только" 2 ^ 160 адреса и 2 ^ 256 частных ключей, так что есть 2 ^ 96 частных ключей для каждого адреса. Неа. Есть 2 ^ 97 частных ключей для каждого адреса. Доказательство остается математика. котировка Для того, чтобы получить все к = 2 ^ 160 адресов, достаточно использовать к * LNK + ключи к = 160 * 2 ^ 160 + 2 ^ 160 = 161 * 2 ^ 160 = 2 ^ (167.32). Если вы используете только 2 ^ 160 частных ключей, вы будете иметь около 63% всех адресов: Я обнаружил, что часто забывают клавишу 1 -> 2 адреса факт (если вычисления сжатой и несжатая pubkeys из privkey). Вы уверены, что вы считали, что? Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM Цитата: BurtW от 01 мая 2017 года, 3:01:55 AM Какова максимальная скорость генерации ключа у вас есть каждый записано, даже в течение короткого периода времени? Я помню, около 2500 Mkeys / с. Да - где-то между 2,3 - 2,5 Gkeys / s - интересная часть, что 1,9 Gkeys / с, что сделано одним человеком.

1 мая 2017, 7:44:35 AM	# 4
arulbero Сообщения: 778 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: rico666 от 01 мая 2017 года, 7:37:51 AM Цитата: arulbero от 01 мая 2017 года, 7:21:51 AM Еще одна интересная вещь: сколько частных ключей я должен проверить, чтобы получить все адреса? Есть "только" 2 ^ 160 адреса и 2 ^ 256 частных ключей, так что есть 2 ^ 96 частных ключей для каждого адреса. Неа. Есть 2 ^ 97 частных ключей для каждого адреса. Доказательство остается математика. Хорошо, ради меня простота не хочу говорить здесь о сжатых / несжатых ключах ...

1 мая 2017, 11:21:54 AM	# 5
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: gmaxwell от 01 мая 2017 года, 10:57:32 AM эта нить имеет много горячего воздуха, segwit p2wsh использует 256-битные хэши, и есть Формат 256bit адрес предложенный. Является ли нить закончилась? gmaxwell: Спасибо Грегу за ваш ответ. К сожалению, я случайно удалил свой пост в моем LBC удалить фест. LBC: Эта нить никогда не должна была быть около LBC. Я хотел бы я никогда не говорил об этом вообще. Я пошел назад и удалил сообщения конкретно о достоинствах / недостатках LBC. Нить закончилась, если кто-то не имеет комментариев по поводу применения проблемы рождения в хэш-пространстве Bitcoin. В частности, это математика представлена в OP правильной? Является ли это реальная проблема?

1 мая 2017, 12:15:20 PM	# 6
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Есть только 2.100.000.000.000.000 satoshis. Поэтому максимальное количество Bitcoins адресов, которые могут содержать значение в любой момент времени составляет лишь около 2⁵¹ и предполагает только один Satoshi за адрес. В то время блок цепь содержит 2⁵⁵ сделки это будет где-то между петабайтом и Эксабайтом в размере. Таким образом, полный узел потребуется несколько петабайта диска для хранения всего блока цепи.

1 мая 2017, 2:28:15 PM	# 7
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: BurtW от 01 мая 2017 года, 11:21:54 AM Цитата: gmaxwell от 01 мая 2017 года, 10:57:32 AM эта нить имеет много горячего воздуха, segwit p2wsh использует 256-битные хэши, и есть Формат 256bit адрес предложенный. Является ли нить закончилась? gmaxwell: Спасибо Грегу за ваш ответ. К сожалению, я случайно удалил свой пост в моем LBC удалить фест. LBC: Эта нить никогда не должна была быть около LBC. Я хотел бы я никогда не говорил об этом вообще. Я пошел назад и удалил сообщения конкретно о достоинствах / недостатках LBC. Нить закончилась, если кто-то не имеет комментариев по поводу применения проблемы рождения в хэш-пространстве Bitcoin. В частности, это математика представлена в OP правильной? Является ли это реальная проблема? Скажем segwit не пройдет ... Мы бы нужно новое предложение, не так ли? Кроме того, я думаю, что любой новый формат адрес должен быть полностью обратно совместим.

1 мая 2017, 3:01:05 PM	# 8
динофелис Сообщения: 714 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: BurtW от 01 мая 2017 г., 12:15:20 PM Есть только 2.100.000.000.000.000 satoshis. Поэтому максимальное количество Bitcoins адресов, которые могут содержать значение в любой момент времени составляет лишь около 2⁵¹ и предполагает только один Satoshi за адрес. В то время блок цепь содержит 2⁵⁵ сделки это будет где-то между петабайтом и Эксабайтом в размере. Таким образом, полный узел потребуется несколько петабайта диска для хранения всего блока цепи. Это умная точка! Если мы можем рассчитывать на то, что никогда не будет трудно вилки изменения этого всего, конечно. Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне. Можно сказать, что это предназначалось, чтобы освободить место, но есть много других случаев, где много места было потрачено впустую. Например, факт публикации, в вводе транзакции, а также подпись в качестве открытого ключа является избыточной: можно восстановить открытый ключ подписи и сообщений, которое будет сохранить номер для ключа (256 бит в сжатом формат). Кроме того, странно иметь 256 битный хэш транзакций с: трудно думать, что нужно было бы 256 бит для транзакции, и только 160 бит для адреса. Для меня было 2 возможные логические значения для размера адреса: 128 бит или 256 бит. 128 бит, потому что это характеристический уровень безопасности ECDS с 256-битными ключами; и 256 бит, потому что это полная энтропия в ключе. 160 бит странный компромисс. Идея, что могло бы быть задней дверью в SHA-256, и что RIPEMD-160, различного происхождения, может иметь другую заднюю дверь, но оба они вместе, "безопасно" звучит странно, и не хороший повод, чтобы изменить количество бит. Можно было бы использовать 2 раза RIPEMD-160 на 128 битовых частей 256 битовой хэш если бы это было проблемой, чтобы держать 256 бит. Поскольку число satoshis составляет 2 ^ 51, на самом деле, не может, как вы справедливо указывают на то, никогда не будет больше, чем 2 ^ 51 действует UTXO в данный момент, так что 128 бит фактически будет достаточно; но, учитывая трату комнаты с 256 битными транзакциями хэша, и публикацию как подписи и ключа, сохраняя полную энтропию ключа с 256 разрядным адресом был бы максимально безопасным вариантом.

1 мая 2017, 3:40:28 PM	# 9
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Если это не имеет непосредственное отношение к теме этой теме, например, тот факт, может в настоящее время быть только 3 транзакций в секунду, сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS, любые сообщения, которые заходят в "блок дебаты размера" территория будет немедленно удален. Есть достаточно темы о уже этой теме.

1 мая 2017, 3:55:28 PM	# 10
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM Это умная точка! Если мы можем рассчитывать на то, что никогда не будет трудно вилки изменения этого всего, конечно. Предполагая, что мы будем придерживаться размера 64 битном для значения, сохранить Bitcoin колпачков 21 миллионов, и мы расширяемся до максимального количества знаков после запятой, предлагаемой 64-битового числом, мы могли бы с комфортом расширить разрешение на 2⁶⁴ = 18.446.744.073.709.551.616 = 2.100.000.000.000.000.000 "millisatoshis" Таким образом, в 1000 или около 2¹⁰ Так что приведет к примерно 2⁶¹ адреса, содержащие millisatoshi каждый.

1 мая 2017, 3:58:27 PM	# 11
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне. Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

1 мая 2017, 4:15:04 PM	# 12
динофелис Сообщения: 714 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: jonald_fyookball от 01 мая 2017 года, 3:58:27 PM Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне. Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad Да, я знаю, что эти аргументы, но они не держат воду (ну, они правильны, но ничего не оправдывает). Они в лучшем случае ответить на этот аргумент "почему Satoshi не использовал RIPEMD-160 в одиночку", Вопрос почему он не придерживаться только SHA-256, и сохранил 256 битный адрес. И если он действительно хочет, чтобы уменьшить число битов, от 256 до 160 (но почему на земле - чтобы сэкономить место, то зачем тратить много места в подписи + ключ?), Он может просто держать первые 160 бит хэш. Давайте рассмотрим несколько аргументов, которые приведены здесь. 1) "взаимодействие между ECDS и хэш-функции", Это совершенно нелепо, так как при условии, что секретный ключ является случайным числом, открытый ключ случайное число тоже (есть биекция между обоими, то циклическая группа). Так что нет "взаимодействие" между случайным числом, и хэш-функции. Но если когда-либо был "смешно взаимодействие" между ECDS и функцией первой хэш (что не имеет смысла, так как я только что изложил: это случайное число), скажем, что он всегда дает один из 10 одинаковых хэшей, а затем приложени второй хэш-функция не собирается решить, на наоборот. Говоря о взаимодействии, с помощью каскадных вещей, вы можете только * увеличение * вероятность нежелательного взаимодействия. 2) "двойное хеширование, чтобы избежать атак расширения" в этом случае не является также странно, как оригинальный ключ всего 512 бит (в длинном формате) и, следовательно, нет необходимости в применении Merkle-Damgard, так как один единый блок хэш-примитив должен быть вызван, и там нет "расширение" возможное. Другими словами, это защита от вида атак, который совершенно не имеет значения в данном случае. Но страннее всего они "защиты" заключается в следующем: Bitcoin позволяет адрес повторного использования. Это может быть запрещено в протоколе (а вторая сделка с тем же адресом в выходе будет недействительной, так же, как дважды провел вход недействителен). Но это не так. Таким образом, это супер пупер защиты из * общественности * ключ с свернутыми хэш, совершенно спорен, если ONE UTXO данного адреса проводится, потому что тогда открытый ключ известен. Все остальные UTXO одного и того же адреса (в различных сделок наиболее вероятно) имеют свой открытый ключ разоблачены, и только безопасность ECC защищает их, без хешей. Это удивительно странно, чтобы пройти через столько хлопот, чтобы избежать возможности открыть для себя открытый ключ от адреса, просто, чтобы позволить вам опубликовать этот открытый ключ для того же адреса, которые еще могут быть использованы в других UTXO.

1 мая 2017, 4:51:47 PM	# 13
BurtW Сообщения: 2114 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Исторически не был оригинальный дизайн для отправки открытого ключа в качестве места назначения - не было хэша в оригинальном дизайне? Затем, в целях экономии места, был добавлен весь хэширования на публичный адрес на вершине? Это было мое понимание - что часто недостатков, когда речь идет об эзотерической истории.

1 мая 2017, 5:19:02 PM	# 14
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: BurtW от 01 мая 2017 года, 4:51:47 PM Исторически не был оригинальный дизайн для отправки открытого ключа в качестве места назначения - не было хэша в оригинальном дизайне? Затем, в целях экономии места, был добавлен весь хэширования на публичный адрес на вершине? Это было мое понимание - что часто недостатков, когда речь идет об эзотерической истории. Насколько я понимаю, что есть дополнительные преимущества для хэширования Публичных. Например, если реализация бумажник был испорчен и использовал плохую K «значение».

1 мая 2017, 5:38:03 PM	# 15
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: динофелис от 01 мая 2017 года, 4:15:04 PM Цитата: jonald_fyookball от 01 мая 2017 года, 3:58:27 PM Цитата: динофелис от 01 мая 2017 года, 3:01:05 PM Я всегда задавался вопросом, почему Satoshi применяется RIPEMD-160 после SHA-256 для адреса, который, казалось несовместимым мне. Похоже, хороший пост здесь на том, что: https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad Да, я знаю, что эти аргументы, но они не держат воду (ну, они правильны, но ничего не оправдывает). Они в лучшем случае ответить на этот аргумент "почему Satoshi не использовал RIPEMD-160 в одиночку", Вопрос почему он не придерживаться только SHA-256, и сохранил 256 битный адрес. И если он действительно хочет, чтобы уменьшить число битов, от 256 до 160 (но почему на земле - чтобы сэкономить место, то зачем тратить много места в подписи + ключ?), Он может просто держать первые 160 бит хэш. Давайте рассмотрим несколько аргументов, которые приведены здесь. 1) "взаимодействие между ECDS и хэш-функции", Это совершенно нелепо, так как при условии, что секретный ключ является случайным числом, открытый ключ случайное число тоже (есть биекция между обоими, то циклическая группа). Так что нет "взаимодействие" между случайным числом, и хэш-функции. Но если когда-либо был "смешно взаимодействие" между ECDS и функцией первой хэш (что не имеет смысла, так как я только что изложил: это случайное число), скажем, что он всегда дает один из 10 одинаковых хэшей, а затем приложени второй хэш-функция не собирается решить, на наоборот. Говоря о взаимодействии, с помощью каскадных вещей, вы можете только * увеличение * вероятность нежелательного взаимодействия. Я предполагаю, что они говорят, что с помощью unhashed открытого ключа, было бы более целесообразным разработать некоторые столкновения атаки, основываясь на его содержание, а не там быть небольшим числом возможных выходов. Имеет смысл на поверхности, как отказобезопасная предосторожность. котировка 2) "двойное хеширование, чтобы избежать атак расширения" в этом случае не является также странно, как оригинальный ключ всего 512 бит (в длинном формате) и, следовательно, нет необходимости в применении Merkle-Damgard, так как один единый блок хэш-примитив должен быть вызван, и там нет "расширение" возможное. Другими словами, это защита от вида атак, который совершенно не имеет значения в данном случае. Я не за тобой вообще. Почему «только 512 бит» сделать нападение расширение не работает? Я не глубоко понять, как работает эта атака, но почему бы нападение не возможно?

1 мая 2017, 5:39:04 PM	# 16
динофелис Сообщения: 714 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: BurtW от 01 мая 2017 года, 4:51:47 PM Исторически не был оригинальный дизайн для отправки открытого ключа в качестве места назначения - не было хэша в оригинальном дизайне? Затем, в целях экономии места, был добавлен весь хэширования на публичный адрес на вершине? Это было мое понимание - что часто недостатков, когда речь идет об эзотерической истории. Я должен сказать, что я не знаю, если это было так исторически. Но аргумент "для экономии места" не держит воду в фактической реализации, из-за этих причин: 1) если открытый ключ был опубликовано вместо его хэша, это не будет необходимо опубликовать его * второй раз * во время подписания: теперь люди публикуют первый хэш, а затем, открытый ключ при подписании. Если адрес был непосредственно открытым ключом, можно было бы выиграть хэш комнату, потому что не было бы никакой необходимости публиковать ключ РАЗА. 2) первый аргумент на самом деле падает, потому что с подписью и текстом, можно получить открытый ключ. Таким образом, хэш может выиграть некоторую комнату, потому что открытый ключ не должен быть опубликован: от подписи, можно вывести его, вычислить хэш, и проверить, соответствует ли она по адресу. Но это не может быть причиной, потому что эта функция (то, что можно вычислить открытый ключ подписи) не используется. 3) есть много другого "тратить комнаты" по сделке, и самое важное для меня является хэш 256 бит, указывающий транзакцию. Это слишком много. Существует также 32-битное число, указывающее "Выход номер сделки" как если сделки будут содержать 4 миллиарда выходов. Это неиспользуемое пространство. На самом деле, повторное использование адреса является то, что делает "указывающий транзакцию" необходимо. Если адрес произошло только один раз, то не было бы никакой необходимости указать "сделка хэш": При условии, что адрес может соответствовать только одной прошлой выход, что выход (и соответствующая транзакция) будет однозначно определяться подписью (и, следовательно, соответствующий открытый ключ, и, следовательно, соответствующий адрес). Так что не было бы никакой необходимости, ни указать хэш транзакции (256 бит), сохраненные ни номер выхода (32 бит сохраняется). Поэтому мне трудно представить, что 100 или так биты, сэкономленные на 160 битным кешем, вместо битового ключа 256, была серьезная причина. Однако, тем не менее, есть очень хорошая причина, чтобы использовать хэш открытого ключа, который не публикуется. Это причина: если когда-либо крипто ECC не удается, один по-прежнему может использовать хэш-схему на основе сигнатур (даже если это просто переключиться на другую криптографическую систему подписи). "открытый ключ" является то "Секретный ключ" за хэш. ==> но эта схема не плачевно, если один имеет многократное использование одного и того же адреса, потому что если один использовал один из них в прошлом, то "Секрет открытого ключа" Теперь общественность. Поэтому он смотрит на меня, что весь криптографической дизайн этого "Хешированный открытый ключ" это довольно грязный, даже если он работает. Всякий раз, когда один находит "дизайн обоснование" в одном направлении, есть что-то еще, что винты это: 1) победы комнаты на цепи -> ввернут тратить комнату в другом месте 2) защиты открытого ключа в случае ECC не удается -> ввинчивается адресным многократного использования возможных То же самое кратное использование адреса и тратит много места, из-за необходимости с указанием какой сделки и какой номер выхода, которые имеют слишком большое потребление битов для их реальных потребностей.

1 мая 2017, 7:48:16 PM	# 17
динофелис Сообщения: 714 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: jonald_fyookball от 01 мая 2017 года, 5:38:03 PM Я предполагаю, что они говорят, что с помощью unhashed открытого ключа, было бы более целесообразным разработать некоторые столкновения атаки, основываясь на его содержание, а не там быть небольшим числом возможных выходов. Имеет смысл на поверхности, как отказобезопасная предосторожность. Я не знаю точно, что вы имеете в виду здесь. "взаимодействие между ECDS и хэш-функции" звучит совершенно странно, потому что это означало бы, что * inadvertedly * хэш-функция будет а) страдают от пониженного выходного пространства, если его входы открытые ключи ECDS или б) будет случайно обнажить закрытый ключ, или сделать это проще. Оба аргумента не держат воду, потому что: а) частный ключ является случайным числом, и отношений линии частного>Открытый ключ является биекция (экспоненцирование в циклической группе простого порядка) открытый ключ является столь же случайным, как любым случайным число, так что нет "состав" в открытом ключе. б) если данный хеш-функция была решить случайно, даже частично, проблема дискретного логарифма ECDS, что было бы монументальное использовать !! Я не спорил за помощью прямого открытого ключа (хотя можно было бы считать, что). Я приводил доводы в пользу использования SHA-256 хэш открытого ключа непосредственно, не направляя ее через RIPEMD-160 и использовать полные 256 хэш-бит. котировка котировка 2) "двойное хеширование, чтобы избежать атак расширения" в этом случае не является также странно, как оригинальный ключ всего 512 бит (в длинном формате) и, следовательно, нет необходимости в применении Merkle-Damgard, так как один единый блок хэш-примитив должен быть вызван, и там нет "расширение" возможное. Другими словами, это защита от вида атак, который совершенно не имеет значения в данном случае. Я не за тобой вообще. Почему «только 512 бит» сделать нападение расширение не работает? Я не глубоко понять, как работает эта атака, но почему бы нападение не возможно? Ну, атака расширения не имеет смысла здесь, по разным причинам, но атака расширения идет о том, когда один знает хэш данного документа. В конструкции Меркель-Damgard, документ, который будет хэшированного его разрезают на блоки по 512 битов, и хэш-выход первого блока подается в хэш-входом второго блока и так далее. Так что, если вы знаете, окончательный хэш, вы можете добавить блок с собственным содержанием, независимо от того, каково содержания Хешированного до этого момента, и использовать опубликованный хэш и новый блок, представить хэш документа, независимо от его был, прилагается с блоком. Например, если был секретный текст дает целое объяснение плана битвы, были хэшируются (и вы не знаете, содержания), вы могли бы принять этот хэш, добавить блок из ваших пристрастий, например, говоря "PS: все вышеперечисленное неверно, атака состоится в полдень"И вы могли бы вычислить правильный хэш документа, с этим блоком, приложенным к нему. Это будет полностью изменить смысл документа, и вы по-прежнему быть в состоянии произвести правильный хэш. Но когда хэширования ключа, там нет такого смысла присоединяя блок. Никто не будет смотреть на любом фальшивом сообщении с "больше вещей в нем не только оригинальном ключе", Кроме того, есть только один единственный вызов функции сжатия и Merkle-Damgard даже не используется для этого. Эта атака атака в совершенно иной обстановке использования хэша, чем с адресом Bitcoin, и, следовательно, не имеет смысла. Это имеет смысл, когда вы можете сделать атаку посредника с переданным документом, о котором вы не можете изменить содержание, но вы можете добавить в него содержимое, и вы можете указать другой хэш.

1 мая 2017, 8:03:06 PM	# 18
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin хорошо мы можем только догадываться, почему Satoshi разработан это таким образом. Если плохая кривое было выбрано для ECDSA да будет нарушено, но менее разбито на неиспользуемых адреса ... звучит как слабый аргумент, но может быть еще лучше, чем ничего? так я понимаю, что вы имеете в виду. Я понимаю, что вы имеете в виду о 512 бит. Можно ли это как-то связано с тем фактом, что версия Публичных 512 несжатый, поэтому его безопаснее хэш его снова?

1 мая 2017, 11:45:37 PM	# 19
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: BurtW от 01 мая 2017 года, 3:40:28 PM сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS, Я думаю, что вы не уловили реальную причину, по которой 256 бит адреса имеют важное значение. Любой N-битный адрес имеет только N / 2 бит защиты от столкновения, не так ли? Так вот интересная атака: Вы даете мне свой Публичных, а затем я создаю мой Публичных для 2-из-2 (или какого-либо другого более сложного контракта), а затем мы платим получившийся адрес. К сожалению. На заднем плане я ~ 2 ^ 80 работы и нашел адрес сталкивающихся которые не имеют ту же политику, и я использую его, чтобы украсть деньги. 2 ^ 80 много работы, но это не достаточно, чтобы считаться безопасным по современным стандартам. Unrelated, это также дело, что многие хэш же старинные ripemd160 были значительно сломаны или существенно ослаблены. Цитата: динофелис от 01 мая 2017 года, 5:39:04 PM есть много другого "тратить комнаты" по сделке, и самое важное для меня является хэш 256 бит, указывающий транзакцию. Это слишком много. Существует также 32-битное число, указывающее "Выход номер сделки" как если сделки будут содержать 4 миллиарда выходов. Это неиспользуемое пространство. Вы можете хранить транзакции, как вам нравится и negoiate с вашими коллегами, чтобы отправить их, как вам нравится, нет необходимости в пространстве, чтобы быть потрачены впустую, как продукт сериализации. Использование большего хэша это занимает больше ресурсов, но разница очень мала по сравнению с остальной частью сделки.

2 мая 2017, 3:09:49 AM	# 20
динофелис Сообщения: 714 Цитировать по имени цитировать ответ	Re: случай для перехода от 160 бит до 256 бит адреса Bitcoin Цитата: gmaxwell от 01 мая 2017 г., 11:45:37 PM Цитата: BurtW от 01 мая 2017 года, 3:40:28 PM сколько времени потребуется, чтобы сжечь через 2⁵⁵ адреса на только 3 TPS, Я думаю, что вы не уловили реальную причину, по которой 256 бит адреса имеют важное значение. Любой N-битный адрес имеет только N / 2 бит защиты от столкновения, не так ли? Так вот интересная атака: Вы даете мне свой Публичных, а затем я создаю мой Публичных для 2-из-2 (или какого-либо другого более сложного контракта), а затем мы платим получившийся адрес. К сожалению. На заднем плане я ~ 2 ^ 80 работы и нашел адрес сталкивающихся которые не имеют ту же политику, и я использую его, чтобы украсть деньги. 2 ^ 80 много работы, но это не достаточно, чтобы считаться безопасным по современным стандартам. Я не совсем понимаю. Вам нужно 2 ^ 80 работы, чтобы найти столкновение, то есть, чтобы найти 2 (новые) Пивная ключи хэш по тому же адресу. Но как это Порция в этом случае, потому что у меня нет свободного выбора * Публичного * контрагента? Я мог бы найти два разных ключа паба, что хэш-одному и тому же адресу, и использовать один из них в контракте, но то, что я сделал бы с другой? Я предполагаю, что я не должен сказать вам, что в атаке столкновения, я не могу "фиксировать" один из хэшей - это "второй прообраз" атака, а не столкновение атака, и не страдает от парадокса дней рождения. EDIT: ах, я получил его: столкновение между ключом паба вы генерируете для фактического 2 - контракта 2, а другой паб ключом можно создавать, что приведет к тому же конечному адресу, но где вы освоите все условия, чтобы в конце концов, вы можете полностью удовлетворять условиям первого контракта, путем использования "доказательства" второй, при условии, что они приводят к тому же самому конечному хэшу. Да, на самом деле.

Заголовок