Серхио Лернер сделал предложение на своем блоге для редизайна заголовка Bitcoin блока.
http://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
Цель состоит в том, чтобы повысить уровень безопасности несколько, (в силу "страшно технические подробности о пути хэширования Algo работы"), Что позволяет пространство для некоторой дополнительной информации, оставляя структуру совместимы с существующими инвестициями в СБИС и т.д.
Я заинтересован в этом вопросе, и хотел бы услышать, что думают люди о пересмотре его.
Одна вещь, которую я не понимаю, почему последние 48 байт второго блока его предлагаемой модернизации должны оставаться с "ноль, не используют."
|
|
||||||
26 мая 2014, 10:32:20 PM
|
# 1 |
Сообщения: 840
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru |
|
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
27 мая 2014, 4:46:58 AM
|
# 2 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Получил 1806 Биткоинов
Реальная история. SHA-256 обрабатывает сообщения размером более 512 бит, разбив сообщение на блоки, которые имеют длину 512 бит. Первый входной блок подается в хэш-функции и что выход (h0) в сочетании со вторым входным блоком, и что выход (h1) сочетается с третьим входом, и т.д., и т.д., до тех пор, пока все исходные данные были хэшированного. Это, как сообщение произвольного размера (даже сказать 4GB ISO) может быть сведена к одному 256-битового значения.
"обнуляет" просто интервалы между битами. Они могли бы быть чем-либо до тех пор, как формат конечного блока (частичное хэш не Биткойн блоков) остается той же длиной и заканчивается 32 бит одноразового номер. Заголовок текущего Bitcoin блока имеет длиной 640 бит Это означает, что первые 512 бит хешируются и выходная функция хранится h0 Следующие 128 бит затем хэшированный с выходом h0 для получения h1. Затем это хэшируются снова, потому что Bitcoin использует SHA256d. Теперь ASICS является "тупой" они действительно не имеют ни малейшего представления о том, что они хэширования. Так как h0 остается относительно неизменным (данный случай находится во втором блоке), добывающее программное обеспечение (локальная минер) вычисляет частичную h0 хэш и корм, что плюс 96 бит во втором блоке в ASIC. СИС добавляет 32-битный счетчик (нонс) и вычисляет хэш увеличивающийся внутри по мере необходимости и возвращать результаты. Таким образом, чтобы сохранить совместимость с существующими ASICS требует двух вещей: а) 256 бит (х) частичное значение хеш-функции б) последний блок (частичный ввод хэша) должен состоять ровно из 96 бит + 32 бита Nonce. Все, что отличается приведет в формате, существующая ASICS не понимает. Комментарий о "должен быть равен нулю, не используйте" просто означает, что заполнение и должны быть согласованы в протоколе, что может быть что-то все нули, все те, ASCII код для "Satoshi правила 123 ...." до тех пор, как она состоит из 48 байтов. Там нет никакого фактического требования о том, что протокол / стандарт должен использовать только нули. Если другой формат был использован обивка будет меньше или больше, чтобы гарантировать, что 96 бит + 32 бит Nonce являются единственными элементами в окончательной частичной хэш. Таким образом, независимо от того, насколько велика вы хотите, чтобы заголовок будет он все равно будет хэш вплоть до Н (х) частичный хэш плюс 96 бит + 32 бита Нонс и быть совместимым с существующим оборудованием. Лично я рассмотрел изменения, как это, но я бы предложил модифицированную структуру. Я хотел бы использовать 64-битный одноразовый номер в последнем сегменте (замена нонса, nonce2 и nonce3). Эта поддержка будет для шахтеров, как мощные, как 18446 PH / с без перелива одноразового номера. Больше Nonce поля могут быть поддержаны существующими аппаратными средствами в режиме обратной совместимости аналогичным образом с тем, как 32-битные значения сохраняются в регистрах 64-битный процессор. Верхний 32 бит просто обнуляются. Существующие шахтеры (которые только понимают концепцию 32 битного нонса) просто хэш значения, которое заканчивается 00000000 плюс 32 битного одноразового номером. Локальная минер (cgminer) может увеличивать верхний 32 бит для обеспечения поддержки высших hashrate аппаратных средств. Со временем разработчики ASIC отпустит "повышенная" аппаратное обеспечение, которое использует большее пространство внутри одноразового номера для обработки более высокой пропускной способности. |
|
|
|
|
27 мая 2014, 3:19:58 PM
|
# 3 |
|
Сообщения: 840
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Хорошо ... Что аппаратные СИСЫ получить хэш, представляющий предыдущие блоки 64 байт, а последний блок. В стандартном SHA256, последние 8 байт последнего блока используются для добавления длины, так что последний блок может иметь длину не более 56 байт. Если он больше, стандартный алгоритм SHA256 добавляет другой 64-байтный блок (проложенный с большим количеством нулей), чтобы держать поле длины. Но существующие СИС сильно зависит от конкретной структуры последнего блока, так что есть правила о последнем блоке, который вы не можете изменить при сохранении совместимости с существующим СИСОМ. Временная метка со смещением 4 (байты 4 - 7 в последнем блоке) либо не может перемещаться, или должен стать дополнительным Nonce поля, так как существующие аппаратные модификации, что положение для того, чтобы расширить диапазон нонса уже, в результате чего временные метки на добывали блоки, которые неточные до 256 секунд. Ничто другое (за исключением другого Нонс поля) не может быть изменено таким образом, не разрушая действительность блока. Поле трудности со смещением 8 (байт 8 - 12 в последнем кадре) не может двигаться, потому что это место, что существующие СИС чтения для того, чтобы выяснить, является ли хэши они придумывают являются достаточно низкими, чтобы выиграть или нет. Нонса поля по смещению 12 (байт 12 - 16 в последнем кадре) не может двигаться, потому что СИС тестирует изображения блоков со всеми возможными значениями там, и будет кашлять значение перезаписать это место с. Важные значения, что хэш должен включать в себя не может быть расположена после смещения 12 в последнем блоке, поскольку существующие СИСЫ только чтение первых 12 байт последнего блока, прежде чем начать работу, чтобы определить, что перезапись байт 12-16 с (остальное предполагается, что дополненные нули, чтобы смещение 56, и следует с постоянным полем длиной). Ваша точка, что поле Nonce по смещению 12 может быть совместимо 8 или 16-байтовое поле вместо поля 4-байтовое является хорошим. Будущие поколения СБИС могли бы использовать, что, как вы говорите, чтобы поддерживать быстрее хеширования без баловаться с поля временной метки. Но ваш ответ на мой первоначальный вопрос в том, что вторые 48 байт второго блока могут быть использованы для хранения данных. Например, если мы хотим поставить (32 байт) Меркл корень текущего UTXO, установленный в заголовке, мы могли бы поставить его там. Кроме того, теперь у меня есть второй вопрос. Так как в настоящее время СИС предполагает, что они работают на втором = последний блок, не будут ли их положить длину тока, а не пересмотренный блок заголовка в 56 со смещением? И, следовательно, не результаты отклоняются от "реальный" SHA256, когда они используются на третьем = последний блок? |
|
|
|
|
27 мая 2014, 3:48:57 PM
|
# 4 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Временная метка со смещением 4 (байты 4 - 7 в последнем блоке) либо не может перемещаться, или должен стать дополнительным Nonce поля, так как существующие аппаратные модификации, что положение для того, чтобы расширить диапазон нонса уже, в результате чего временные метки на добывали блоки, которые неточные до 256 секунд. Ничто другое (за исключением другого Нонс поля) не может быть изменено таким образом, не разрушая действительность блока. Это хороший момент. Я предположил, что поле времени в настоящее время увеличивается за пределами аппаратных средств (то есть в cgminer) на Ntime прокатки, но если она увеличивается время внутри, то да, это было бы нужно быть Nonce поля. Несмотря на то, менее ясно можно было бы расширить одноразовый номер, чтобы быть 64-битный номер, используя эти байты в качестве верхнего 32 бита. Время может храниться должным образом в предыдущем блоке (используя определение ша не Биткойн определение), чтобы избежать "мотыга" использования неправильных меток времени в качестве дополнительного одноразового номера. котировка Поле трудности со смещением 8 (байт 8 - 12 в последнем кадре) не может двигаться, потому что это место, что существующие СИС чтения для того, чтобы выяснить, является ли хэши они придумывают являются достаточно низкими, чтобы выиграть или нет. Это не правильно. Если бы это было так, то аппаратный может быть использован только для сольного добычи и никогда не возвращает никакого результата, кроме одного, который решает блок. Аппаратных подают более низкую долю трудности (не является частью фактической структуры блока) и аппаратные возвращает результаты меньше, чем (который, по определению, также включает в себя все результаты меньшие, чем целевой блок). котировка Нонса поля по смещению 12 (байт 12 - 16 в последнем кадре) не может двигаться, потому что СИС тестирует изображения блоков со всеми возможными значениями там, и будет кашлять значение перезаписать это место с. Верный. котировка Ваша точка, что одноразовое значение поля со смещением 12 может быть совместит 8 или 16-байтовое поле вместо поля 4-байтового является хорошей. Будущие поколения СБИС могли бы использовать, что, как вы говорите, чтобы поддерживать быстрее хеширования без баловаться с поля временной метки. Основываясь на ваших о поле временной метки, если это время увеличивается на единицу внутренне в аппаратных средствах я бы расколоть 64 бит одноразовое значение будет два 32 битных чисел со смещением 4 и 12. Это происходит потому, что у нас есть ограниченное пространство в конечном блоке и что позволило бы сохранить большинство битов. Это дало бы нам 8 байт для повышения безопасности горных работ. Две возможностей использования этих байт будет частичным хеш предшествующего блока, который позволил бы шахтерам проверить их hashpower не используются для вредоносных целей и / или элементов, необходимых для добычи полезных ископаемых (непрозрачной методики, чтобы предотвратить удержание атаки), однако я не смотрели внимательно, чтобы увидеть, если это будет возможно, и до сих пор остается обратной совместимостью.Заключительный блок Смещение 0 - 4 байта ДОСТУПНЫ Смещение 4 - 4 байта верхнего 32 бита nonce64 Смещение 8 - 4 байта ДОСТУПНЫ Смещение 12 - 4 байта младшие 32 бита nonce64 Таким образом, мы получаем больший диапазон и временное значение 8 байт для дополнительных функций безопасности, сохраняя при этом обратную совместимость с существующим оборудованием. котировка Но ваш ответ на мой первоначальный вопрос в том, что вторые 48 байт второго блока могут быть использованы для хранения данных. Например, если мы хотим поставить (32 байт) Меркл корень текущего UTXO, установленный в заголовке, мы могли бы поставить его там. Верный. Заполнение используется только для того, чтобы формат последнего блока остается совместимым, обеспечивая 64 байта наблюдаются границы. Можно было бы добавить весь дополнительный блок, если вам нужно больше места.котировка Кроме того, теперь у меня есть второй вопрос. Так как в настоящее время СИС предполагает, что они работают на втором = последний блок, не будут ли их положить длину тока, а не пересмотренный блок заголовка в 56 со смещением? И, следовательно, не результаты отклоняются от "реальный" SHA256, когда они используются на третьем = последний блок? Это хороший вопрос. Если в настоящее время добавляется внутри, то вы, вероятно, правы. Это сделало бы Bitcoin нестандартный вариант SHA-256. |
|
|
|
|
27 мая 2014, 3:53:42 PM
|
# 5 |
|
Сообщения: 539
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Временная метка со смещением 4 (байты 4 - 7 в последнем блоке) либо не может перемещаться, или должен стать дополнительным Nonce поля, так как существующие аппаратные модификации, что положение для того, чтобы расширить диапазон нонса уже, в результате чего временные метки на добывали блоки, которые неточные до 256 секунд. Ничто другое (за исключением другого Нонс поля) не может быть изменено таким образом, не разрушая действительность блока. Моя идея состояла в том, чтобы оставить только две младшие байты времени там (nonce2 поля), так как я не думаю, что аппаратные средства займут более двух байт поля для Нонса (случайных) целей. Я не думаю, что аппаратное обеспечение использует поле времени, чтобы идти в ногу со временем. Он может использовать его, чтобы добавить больше нонса пространства. Поле трудности со смещением 8 (байт 8 - 12 в последнем кадре) не может двигаться, потому что это место, что существующие СИС чтения для того, чтобы выяснить, является ли хэши они придумывают являются достаточно низкими, чтобы выиграть или нет. Я не знаю много об оборудовании, но я думаю, что трудность следует читать и интерпретировать с помощью программного обеспечения, а затем отправляется на аппаратные средства в более машинно-дружественным способом, таким как число предшествующих нулей. Вы уверены, что это оборудование, которое интерпретирует трудность? |
|
|
|
|
27 мая 2014, 4:06:48 PM
|
# 6 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Временная метка со смещением 4 (байты 4 - 7 в последнем блоке) либо не может перемещаться, или должен стать дополнительным Nonce поля, так как существующие аппаратные модификации, что положение для того, чтобы расширить диапазон нонса уже, в результате чего временные метки на добывали блоки, которые неточные до 256 секунд. Ничто другое (за исключением другого Нонс поля) не может быть изменено таким образом, не разрушая действительность блока. Он может использовать только два байта, но независимо от них находятся в неправильном месте. Если оборудование приращения нижних два байта в поле времени, которое было бы по смещению 6 (полный рабочий день начинается со смещением 4). котировка Я не знаю много об оборудовании, но я думаю, что трудность следует читать и интерпретировать с помощью программного обеспечения, а затем отправляется на аппаратные средства в более машинно-дружественным способом, таким как число предшествующих нулей. Вы уверены, что это оборудование, которое интерпретирует трудность? Трудность (биты) может быть перемещена без проблем. AFAIK нет ASIC оборудования не использует это. Они возвращаются все хэши меньше, чем цель акции, которая больше, чем целевой блок в любом случае. Если только возвращает результаты переговоров блока ТРУДНОСТЬ оборудование не может быть использовано для добычи бассейна, поскольку это не будет возвращать ничего, если только блок не была решена. Я не вижу цели частичного хэша предыдущих элементов. Для того, чтобы убедиться, что потребует зная предыдущие элементы и если шахтер знает, что h0 и h1 могут быть вычислены непосредственно. Вопрос горнодобывающей безопасности возникает потому, что бассейны не обеспечивают полный заголовок блока и вместо того, чтобы только обеспечить h0 (или в вашем предложении h1). С помощью всего лишь h1 парциальное хэш заголовка не может быть проверена. Вместо этого я хотел бы использовать частичный хеш (младшие 8 байт) предшествующего blockhash. Это сделало бы возможным шахтер, чтобы проверить, что они находятся на правильной цепи без полного заголовка. Некоторые другие предлагаемые изменения: * Увеличение значения времени во втором блоке 8 байт для устранения проблемы года 2038 (и 2106). * Добавить поле в явном виде записать высоту блока Наконец на основе любой спецификации используется некоторое количество дополнения могут быть необходимы для обеспечения последний блок ровно 16 байт в длину, чтобы сохранить обратную совместимость. В черновике это 48 байт, но это может варьироваться в зависимости от я бы не санкционировать, что избыточное пространство обнуляется, а указывают на это произвольное значение фиксированной длины. Это позволит использовать его в качестве блокнота для обеспечения мягкой вилки возможности в будущем. Это также может привести к приложениям, которые мы еще не рассматривали. Это хороший проект, но он, вероятно, потребуется ввод из нескольких источников (включая разработчик аппаратного обеспечение), чтобы придумать финализированную спецификацию. |
|
|
|
|
27 мая 2014, 5:48:14 PM
|
# 7 |
|
Сообщения: 840
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Поле трудности со смещением 8 (байт 8 - 12 в последнем кадре) не может двигаться, потому что это место, что существующие СИС чтения для того, чтобы выяснить, является ли хэши они придумывают являются достаточно низкими, чтобы выиграть или нет. Я не знаю много об оборудовании, но я думаю, что трудность следует читать и интерпретировать с помощью программного обеспечения, а затем отправляется на аппаратные средства в более машинно-дружественным способом, таким как число предшествующих нулей. Вы уверены, что это оборудование, которое интерпретирует трудность? Как DeathAndTaxes показывает, и по тем же причинам, и вы, и он упомянул, что это почти наверняка так. Так получается, что поле трудности могут быть перемещены в случае необходимости. Но я по-прежнему обеспокоен (виртуальном) поле «длина» со смещением 56 в последнем блоке. Если мы используем существующий СБИС, я уверен, что они будут продолжать хэш на основе образ последнего блока, который заканчивается с длиной текущего заголовка Bitcoin, а не длиной пересмотренного заголовка. Результат будет то, что Bitcoin хеширования с помощью СБИСА, в то время как все еще возможно, будет в соответствии с вариантом от стандартного SHA256, а также различных программных средств, которые используют стандартные SHA256 в качестве строительного блока потребуются изменения для учета разницы. На самом деле, первый из них будет bitcoind себя, где SHA256 называет, что источники из SSL будет выплюнуть другой хэш, что приводит к сообщению «недопустимый блок». Это необходимо будет реализовать "SHA256D_Variant" чтобы избежать (дополнительная) немедленной жесткую вилки. Очевидно, что мы говорим о жесткой вилкой изменения в любом случае ... |
|
|
|
|
27 мая 2014, 6:13:21 PM
|
# 8 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Но я по-прежнему обеспокоен (виртуальном) поле «длина» со смещением 56 в последнем блоке. Если мы используем существующий СБИС, я уверен, что они будут продолжать хэш на основе образ последнего блока, который заканчивается с длиной текущего заголовка Bitcoin, а не длиной пересмотренного заголовка. Результат будет то, что Bitcoin хеширования с помощью СБИСА, в то время как все еще возможно, будет в соответствии с вариантом от стандартного SHA256, а также различных программных средств, которые используют стандартные SHA256 в качестве строительного блока потребуются изменения для учета разницы. Согласовано. Может быть, кто-то с детальным знанием точных материалов, представленных на ASIC может пролить некоторый свет, но я думаю, что вряд ли какой-либо ASIC принимает в качестве входных данных длину blockheader и вместо этого работает на фиксированное предположении 640 бит. Если длина заголовка = / = 640 бит и протокол ожидает, что хэш будет SHA-2 работает согласно, то было бы разорвать все существующие аппаратные средства. С другой стороны, если протокол использует вывод существующего ASICs, когда заголовок не является = / = 640 бит, то хэш больше не следует спецификации SHA-2. Bitcoin будет использовать хэш-функцию, основанную на SHA-2, но он больше не будет SHA-2. Протокол было бы ожидать, конечный блок заголовка, чтобы быть 16 байт данных с последующим 40 байт нулей, за которыми следует статические 8 байт (всегда 0x0000000000000280). Конечно, другие виды использования функции SHA-2 (сделки, pubkeyhash, дайджест сообщения для подписи и т.д.) будет использовать существующий "по спецификации" версия, которая делает это довольно некрасиво хак на мой взгляд. Спасибо за указание на это Cryddit как я обдумывал это некоторое время, и я забыл о длине, добавленные к проложенному последнему блоку. Расширенный внутренний заголовок Существует альтернативный способ расширить заголовок, который остается совместимым с SHA-2 спецификацией и фиксированной длиной 640 бит, налагаемых существующими аппаратными средствами. Это было бы в виде расширенного заголовка, который содержит большинство элементов заголовка) и хэш, который добавляется к "главный" заголовок. Это немного cludgy, но было бы сделать длину заголовка такой же, как то, что, как ожидается, горнодобывающие СБИС. Заголовок блока по-прежнему 640 бит, так что поле виртуального длина до сих пор правильно, даже если шахтеры используют фиксированный 640 битовую длину. Расширенный заголовок (может быть произвольной длиной не ограничен текущим размером blockheader или форматом) Код: Блок Смещение Размер (байт) поле 0 0 32 hashPrevBlock (SHA-256) 0 32 32 hashMerkleRoot (SHA-256) 1 0 8 Время (8 байт против 4 байта) 1 8 8 Бит (мишени в компактном формате) 1 16 8 Blockheight (стоит учесть, если он улучшает сопротивление DOS) 1 16 4 Экстра Nonce (полезно для майнинг распределять работу без пересчета merkletree) 1 20 34 * Не определено в этой точке (может быть обнулены отступы, используется в качестве блокнота, или байты используются в более позднем проекте) * Расширенный заголовок может быть определен любым размером. SHA-2 спецификации разбивает сообщения на блоки по 64 байт. Блок Продольный имеет пространство для 55 байт только как спецификация требует сообщения, которое будет добавляться с 1, а затем достаточными нулями, добавленных, чтобы сделать длину прилагаемого сообщения 56 байт. Длина фактического сообщения добавляется как 8 байт целого числа без знака. Так окончательный блок <= 55 байт данных + 1 байт маркера (0x01) + 0 или более обнуленных байтов заполнения + 8 байт длины сообщения extended_header_hash = SHA-256 (extended_header) Блок заголовка (должно быть ровно 80 байт и соответствовать корректоры ожидаемых существующими аппаратными средствами) Код: Блок Смещение Байт Поле 0 0 4 Version 0 4 32 Extended_header_hash 0 36 24 НЕИСПОЛЬЗУЕМЫЕ (24 обнуляется байт для заполнения) * 1 0 4 НАЛИЧИИ ** 1 4 4 Верхних 32 бит nonce64 *** 1 8 4 НАЛИЧИИ ** -12 4 младших 32 бит nonce64 *** * Вариант будет использовать это для какой-то конкретной цели. Одним из вариантов может быть необязательно поддержку подписания blockheader. ** Я хотел бы использовать 4 или 8 байтов отмеченные доступны в блоке 1, чтобы провести частичный хеш предшествующего блока. Это позволит шахтер программное обеспечение, чтобы проверить их, по крайней мере на лучшей цепи (пул не может быть обойден, чтобы произвести цепь атаки). Эти 8 байт очень ценны, так что должны быть некоторые дебаты о том, как наилучшим образом использовать их. *** nonce64 должны быть разделены, чтобы сохранить совместимость с существующим оборудованием, которое ожидает модифицируемые элементы, чтобы быть по смещению 4 (время) и смещение 12 (nonce32). Цель использования большего одноразового номера в том, что он исключает необходимость изменить другие элементы заголовка блока в качестве клуджа для поддержки больше вычислительной мощности. Чтобы полностью увеличивает на 64 битное временное значение в 1 секунду потребуется один шахтер, чтобы иметь > 18447 PH / с вычислительной мощностью. 64 бита, вероятно, больше, чем это необходимо. Даже 48 бит дополнительный одноразовый потребует >281 TH / с, чтобы увеличить в 1 секунду. Верхний 32 бит нонса может быть уменьшен до 16 бит, если эти 16 бит, сохраненных были необходимы для другой цели. На редактирования: добавлена версия для основного заголовка, как это необходимо, чтобы существующие клиенты знают блок представляет собой новую несовместимую версию, что они не поддерживают (а не просто несовместимый мусор). Существующие клиенты не смогут подтвердить новый блок версии, но они могли бы по крайней мере, уведомить пользователей ("Несовместимые новая версия блока обнаружения. Обновление клиента может потребоваться"). |
|
|
|
|
27 мая 2014, 6:50:42 PM
|
# 9 |
|
Сообщения: 840
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Расширенный внутренний заголовок Существует альтернативный способ расширить заголовок, который остается совместимым с SHA-2 спецификацией и фиксированной длиной 640 бит, налагаемых существующими аппаратными средствами. Это было бы в виде расширенного заголовка, который содержит большинство элементов заголовка) и хэш, который добавляется к "главный" заголовок. Это немного cludgy, но было бы сделать длину заголовка такой же, как то, что, как ожидается, горнодобывающие СБИС. Заголовок блока по-прежнему 640 бит, так что поле виртуального длина до сих пор правильно, даже если шахтеры используют фиксированный 640 битовую длину. ... Блок заголовка (должно быть ровно 80 байт и соответствовать корректоры ожидаемых существующими аппаратными средствами) Код: Блок Смещение Байт Поле 0 0 4 Version 0 4 32 Extended_header_hash 0 36 24 НЕИСПОЛЬЗУЕМЫЕ (24 обнуляется байт для заполнения) * 1 0 4 НАЛИЧИИ ** 1 4 4 Верхних 32 бит nonce64 *** 1 8 4 НАЛИЧИИ ** -12 4 младших 32 бит nonce64 *** * Вариант будет использовать это для какой-то конкретной цели. Одним из вариантов может быть необязательно поддержку подписания blockheader. ** Я хотел бы использовать 4 или 8 байтов отмеченные доступны в блоке 1, чтобы провести частичный хеш предшествующего блока. Это позволит шахтер программное обеспечение, чтобы проверить их, по крайней мере на лучшей цепи (пул не может быть обойден, чтобы произвести цепь атаки). Эти 8 байт очень ценны, так что должны быть некоторые дебаты о том, как наилучшим образом использовать их. *** nonce64 должны быть разделены, чтобы сохранить совместимость с существующим оборудованием, которое ожидает модифицируемые элементы, чтобы быть по смещению 4 (время) и смещение 12 (nonce32). На редактированиях: добавлена версия для основного заголовка, как это необходимо, чтобы существующие клиенты знают блок представляет собой новую версию они не осознают (а не просто несовместимый мусора). Существующие клиенты не смогут подтвердить новый блок версии, но они могли бы по крайней мере, уведомить пользователей ("Несовместимые новая версия блока обнаружения. Обновление клиента может потребоваться"). Я думаю, что это выигрышное предложение. С существующим СИСОМ мы не можем изменить длину заголовка, не делая их не производить стандартные SHA256, но мы можем изменить его структуру, чтобы включать в себя хэш вещей, которые мы не можем добавить (и то, что мы должны были замещать сделать комната для хэша, вздохнув). Вы правы, что мы должны использовать поле версии по назначению; в противном случае нынешние клиенты будут производить невообразимые путаницы. |
|
|
|
|
27 мая 2014, 7:26:08 PM
|
# 10 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Да, чем больше я думаю об этом, пытаясь создать вариант SHA-2 это просто ляп обходной путь. Единственный путь вперед либо изменить заголовок, не изменяя длину от 640 бит или использовать хэш из расширенного заголовка, чтобы обеспечить дополнительное пространство. Оглядываясь назад, было бы лучше использовать 64 битное случайное слово с самого начала. Bitcoin нужно будет работать вокруг этого идти вперед, но, к сожалению, нет altcoin не сделал этого AFAIK, несмотря на меня, и другие в результате чего его лет назад. Это показывает, как много инноваций произошло в altcoin пространстве. Одна вещь, которую я хотел бы отметить, что текущий протокол Bitcoin не определен после 2106
Еще одна вещь, я подумал о том, что если пул подписал расширенный заголовок, то шахтеры могли бы использовать это, чтобы убедиться, что они не подвержены атаке MITM. Сервер пула может когда-нибудь даже использовать HSM для обработки подписания расширенного заголовка, чтобы обеспечить повышенную безопасность. Это не исключает риск пула быть вредоносным, но это атака, связанная с системой DNS, как перенаправлять шахтер на сервер атаки не позволит злоумышленнику правильно подписать расширенный заголовок. К сожалению, только 24 байт SECP256k1 не может быть использован. Другое потенциальное повышение рассмотреть бы использование забывая акций устранить любую возможность удерживаемого нападения на майнинг. Это было впервые предложено Мени Rosenfeld http://arxiv.org/pdf/1112.4980.pdf Примечание: этот метод был предложен в 2011 году и предполагает бассейн акция всегда трудности 1. Та же концепция может быть применена к переменной доле сложности (и упрощенной). Основная концепция в том, что шахтер может определить, если они имеют действительную часть, но не тогда, когда они имеют действительный блок, потому что элемент вычисления хэша для целей проверки сложностей не предоставляются шахтер. Шахтер не будет знать, когда они решают блок только тогда, когда они решают долю однако шахтер может сравнить любые будущие блоки с расширенной header_hash обеспечить пул не обманывать (если блок публикуется, но шахтеры не дали кредит, и это совпадает с работа завершен шахтером, то шахтер знает бассейн обманул все шахтер в бассейне). Первоначальное предложение: котировка 6.2.3 Предлагаемое решение - Oblivious акций Один из способов для блока удержанных атак являются «поп-викторина» - иногда, бассейн обеспечат шахтер с работой, для которой известно решение, и участники флага, которые делают не представить его. Тем не менее, это оставляет желать лучшего и с точностью и отзывом. Подлинное решение заключается в изменении протокола Bitcoin, чтобы забывая акции - акции, которые, когда найдены шахтерами, не могут быть идентифицированы в качестве действительного блока с представлением в пул для обзора. Возможный способ сделать это будет выглядеть следующим образом: • Каждый блок будет иметь 3 дополнительное поле, связанное с ним - SecretSeed, ExtraHash и SecretHash. • ExtraHash должен быть хэш SecretSeed. • ExtraHash будет частью заголовка блока и будет одним из полей, используемых в вычисление блока хэш. • SecretHash должен быть хэш конкатенации блока хэш и SecretSeed. • Для блока в силе: Вместо того, чтобы требовать, чтобы блок хэш меньше 2 ^ 256 / (2 ^ 32 * D), то необходимо, чтобы блок-хэш меньше, чем 2 ^ 256/2 ^ 32, и что SecretHash меньше, чем 2 ^ 256 / D. 1) Оператор Пул будет выбирать SecretSeed и держать его в секрете. 2) Он рассчитает ExtraHash и предоставить его шахтеры вместе с другими полями, которые входят в блок хэша. 3) Шахтеры можно вычислить хэш блока и посмотреть, если оно меньше, чем 2 ^ 256/2 ^ 32, и в этом случае представить его в виде доли. 4) Они не знают, если это правильный блок, потому что они не знают SecretSeed и не может рассчитывать SecretHash. 5) Оператор знает, SecretSeed, вычисляет SecretHash, и если оно меньше, чем 2 ^ 256 / D, это правильный блок и транслируется в сеть. |
|
|
|
|
27 мая 2014, 7:33:29 PM
|
# 11 |
|
Сообщения: 1988
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Одна вещь, которую я хотел бы отметить, что текущий протокол Bitcoin не определен после 2038 из-за 4 байт без знака UNIX метки времени, так в конечном итоге протокол должен будет обновляться. Это уже обсуждалось / дело. Поле метки времени предназначается, чтобы быть "без знака int32_t" что дает нам дополнительный более пятидесяти лет, чтобы обдумать правильный путь к жесткой вилке.Для сравнения, Unix time_t должен быть подписан для совместимости с существующими программами, которые вычисляют разницу во времени. Изменить: Что бы вы ни придумали, пожалуйста, не оставляйте его "не определено", Некоторые шутники поместят "Эта программа не может быть запущена в режиме DOS" там, чтобы создать панику среди Windows, антивирусы пользователей. Люк-младший, вероятно, поставить некоторые молитвы в них. Пожалуйста, просто требовать, чтобы они были нули. |
|
|
|
|
27 мая 2014, 7:50:35 PM
|
# 12 |
|
Сообщения: 840
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Одна вещь, которую я хотел бы отметить, что текущий протокол Bitcoin не определен после 2038 из-за 4 байт без знака UNIX метки времени, так в конечном итоге протокол должен будет обновляться. Это уже обсуждалось / дело. Поле метки времени предназначается, чтобы быть "без знака int32_t" что дает нам дополнительный более пятидесяти лет, чтобы обдумать правильный путь к жесткой вилке.Для сравнения, Unix time_t должен быть подписан для совместимости с существующими программами, которые вычисляют разницу во времени. Кроме того, для информации, time_t представляет собой 64-битное поле текущих коробков, поэтому заголовок Bitcoin не используя "стандарт" Unix time_t так или иначе, в той степени, что такая вещь существует. Я не думаю, что time_t было 32-битное значение в любом месте важно с 1995 года. Во всяком случае, мы смотрим на 2106 (эпоха Unix превышает беззнаковое 32-битное значение) не 2038 (эпоха Unix превышает знаковое 32-битное значение) до того, как протокол Bitcoin становится неопределенным. |
|
|
|
|
27 мая 2014, 7:51:03 PM
|
# 13 |
|
Сообщения: 1218
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Одна вещь, которую я хотел бы отметить, что текущий протокол Bitcoin не определен после 2038 из-за 4 байт без знака UNIX метки времени, так в конечном итоге протокол должен будет обновляться. Это уже обсуждалось / дело. Поле метки времени предназначается, чтобы быть "без знака int32_t" что дает нам дополнительный более пятидесяти лет, чтобы обдумать правильный путь к жесткой вилке.Спасибо за исправление. Так что 2106 год не 2036. Я согласен с трудом насущного беспокойства, но он будет изменен в конце концов. котировка Изменить: Что бы вы ни придумали, пожалуйста, не оставляйте его "не определено", Некоторые шутники поместят "Эта программа не может быть запущена в режиме DOS" там, чтобы создать панику среди Windows, антивирусы пользователей. Люк-младший, вероятно, поставить некоторые молитвы в них. Пожалуйста, просто требовать, чтобы они были нули. Ну, это не будет принято мной независимо, я просто бросали идеи там. Люди уже могут ставить произвольные данные в coinbase поле и создать то же самое "проблемы", Я не вижу "блокнот" из ~ 32 байт в расширенном заголовке для поддержки будущего использования в качестве необязательных, не разрушающей образом, чтобы быть реальной проблемой. Это на самом деле не является обязательным требованием, но иногда немного гибкости может быть хорошей вещью. Merged добыча и решение продублировать coinbase Txs было возможно из-за гибкости coinbase поля. Оптимизация (отсутствие гибкости) является то, что делает расширение заголовка теперь более сложным. |
|
|
|
|
27 мая 2014, 8:07:28 PM
|
# 14 |
|
Сообщения: 1988
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Я не думаю, что time_t было 32-битное значение в любом месте важно с 1995 года. К сожалению (или к счастью, в зависимости от вашей точки зрения) это не так. Там очень много якобы очень нового программного и аппаратного обеспечения, которое использует короткие (16- и 32-битные) метки времени. С верхней части моей головы: в ATSC & DVB телевизионных стандартов, много физических систем аппаратных / программных безопасности, бесчисленные чувствительные к цене встраиваемых систем (в том числе медицинские).Edit: особенно медицинской области печально известен тем явные и неявные "срок годности"s. Они используют эту концепцию довольно долгое время, например, давая истечение даты, чтобы полностью стабильные химические соединения. |
|
|
|
|
31 мая 2014, 5:12:25 AM
|
# 15 |
|
Сообщения: 1260
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Из WordPress статьи:
котировка Сегодня третий раз я нахожу атаку на путь Bitcoin использует алгоритм SHA-256 для выполнения добычи. Два нападения принадлежат к новому семейству атак, которые включают очень технические подробности о внутренней работе SHA-256. Криптографические хэш-функции мне интересны, узнав о них, так как узнать о Bitcoin. Вы можете сказать об этих нападениях и "ужасно технические детали", Благодарю. |
|
|
|
|
2 июня 2014, 3:44:27 PM
|
# 16 |
|
Сообщения: 525
цитировать ответ |
Re: Редизайн заголовка Bitcoin блока
Моя идея состояла в том, чтобы оставить только две младшие байты времени там (nonce2 поля), так как я не думаю, что аппаратные средства займут более двух байт поля для Нонса (случайных) целей. IIRC, eldentyrell когда-то поле времени, чтобы TimeBomb его FPGA битового потокаЯ не думаю, что аппаратное обеспечение использует поле времени, чтобы идти в ногу со временем. Он может использовать его, чтобы добавить больше нонса пространства. |
|
|
|
Как заработать Биткоины?
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
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.