Управление существенных изменений в Bitcoin - сеть QA.

Будет ли Bitcoin удастся навсегда без существенных изменений?

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

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

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

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

Что Bitcoin необходимо реалистичный тест сети. В настоящее время тестовой сети является отличным началом, но активность на нем слишком капризна и непредставительной основную сеть. Тока тестовой сети больше из R&D сеть, как показывает тот факт, что нестандартные сделки в настоящее время разрешены.

Я полагаю, что новая сеть QA инициироваться, которые пользователи Bitcoin могут выбрать для поддержки. QA поддерживающие пользователи будут установлены два Bitcoin клиентов; один работает текущий клиент и один запуск текущего кандидата QA. Новые операции, которые пользователь подстрекает на главной сети будет отображаться в соответствующем новые транзакции в сети QA. Шахтеры будут предложено посвятить крошечную, но глобально неподвижную часть их текущей реальную добычу мощности, так что сеть QA имеет такое же распределение добычи мощности в качестве основной сети. Сеть QA может работать в течение нескольких месяцев с кандидатом один релиза и уверенностью в хорошем кандидат будет расти, как это можно было бы показать, чтобы справиться с текущей нагрузкой основной сделки. Bitcoin инженеры программного обеспечения могут выбрать, чтобы ввести дополнительные другие транзакции в сеть QA, чтобы проверить, как он справляется ни с нападениями или более высоким уровнем законных сделок. Там должен быть механизм, чтобы исключить гриферов из QA сети, которые могут помешать тестированию либо введением нежелательных операций или добычи полезных ископаемых с слишком высокой долей их реальной добычи энергии.

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

ByteCoin

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

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

Хорошая вещь о наборе тестов является то, что он может быть запущен после того, как каждое изменение производится. Таким образом, вы можете найти проблемы, как только они введены вместо того, чтобы сделать потенциально очень сложный распределенный бинарный поиск.

Я собирался начать новую тему об этом, но это, кажется, как хороший матч сейчас.

В основном я думал о аргумент против Bitcoin говоря "Криптографические алгоритмы всегда в конечном счете терпят неудачу." Вы и я знаем, что если SHA256 должны были быть разбиты завтра мы могли бы, вероятно, еще спасти блок цепь и переключиться на какой-то сплошной крипто. Проблема заключается в том, что слово "вероятно", Мы на самом деле не знаю, как бы мы добиться такого изменения еще.

Представьте себе ситуацию, когда, завтра кто-то ломает SHA таким образом, что они могут переписать блок цепи произвольно, или перезаписать сделки, или что-то в этом роде. Я согласен, что это крайне маловероятно, но по мере увеличения продолжительности времени мы говорим, вероятность приближается к 1. Мы даже не перестает генерировать монеты до 2040 Можете ли вы сказать с полной уверенностью, что ВСЕ криптографические элементы наша текущая реализация будет оставаться полностью ненарушенной в течение следующих 30 лет?

Если вы говорите, да на этот вопрос вы с умом, а также явно не работаете в тесте. Дело в том, что я говорил людям, что это не беспокоит, потому что мы можем просто поменять на крипто ... Но никто фактически не думал о том, как мы бы идти об этом, что, не говоря уже о проверке этих планов. Это немного страшно. Время, чтобы сделать это не тогда, когда мы должны.

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

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

Что следует учесть:
Используя новый блок цепь может быть элементом этих планов, или мы могли бы придумать способ, чтобы продолжить текущую цепочку в качестве основы.
Можем ли мы принять старой цепи сделок в нашу новую цепь на лету, преобразования их форматов на то, что мы хотим, чтобы в нашей новой? В не катастрофический сценарий, если мы не будем делать это, как мы можем предотвратить людей, которые не получают памятку от мошенничества (старая Bitcoin сеть все еще существует после смены, человек тратит старые через БТД сделок, которые не будут портированы к новой цепи)
Как мы выздороветь, если злоумышленник был известен, чтобы иметь возможность переписывать блок цепи произвольно? Как мы можем восстановить максимальное количество легитимных данных?

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

В Internet Time один день это вечность. Час достаточно долго для кого-то, чтобы нанести значительный ущерб. Мы не можем быть с этой дискуссией на день 0 или он действительно уничтожит нас. Мы должны быть в состоянии иметь сеть работает на неразрывной крипто в течение часа, зная, что он разорен, и мы должны быть уверены, что сделать это будет идти гладко.

Цитата: Anisoptera от 16 мая 2011 года, 7:02:29 PM

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

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

Цитата: theymos от 16 мая 2011 года, 8:02:39 PM

Цитата: Anisoptera от 16 мая 2011 года, 7:02:29 PM

Я предположил, что это. Это не отвечает на все мои вопросы, хотя. Каждый из этих шагов является лишь handwave. Черт, вы в основном просто процитировал текущую Bitcoin спецификацию на меня.

Как мы планируем прийти к этому соглашению? Что произойдет, если атака не публикуется на некоторое время, и поэтому любое количество блоков имеет некорректные данные в них? Как мы выбираем из плохих, потеряв минимум хороших ОГО?

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

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

Это то, что я имею в виду. Мы "знать" как мы бы это сделать, но никто не удосужился на самом деле придумать фактического плана, не говоря уже протестировали сценарий. Разработка этого плана займет очень много времени - там будет отверстие в первом проекте, некоторые люди не согласятся на вещах, на первом, и так далее. Время, чтобы пройти через этот процесс не "Вот дерьмо, SHA2 было сломано с первой-прообразом атакой на неделю теперь через нераскрытый использовать и у нас есть люди, переписывание blockchain и doublespending, как сумасшедшие, что мы делаем сейчас?", его "Хорошо, этот сценарий неизбежно дается достаточно времени, так что давайте начнем разработку и тестирование решения, с тем, что, когда это произойдет, усилия могут сосредоточиться на реальных проблемах, а не основной подготовки."

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

Цитата: Anisoptera от 16 мая 2011 года, 8:12:39 PM

Как мы планируем прийти к этому соглашению?

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

котировка

Что произойдет, если атака не публикуется на некоторое время, и поэтому любое количество блоков имеет некорректные данные в них? Как мы выбираем из плохих, потеряв минимум хороших ОГО?

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

котировка

Как мы хэширования Согласованного содержания?

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

котировка

Как мы вновь обеспечить деньги, содержащиеся в blockchain без закрытых ключей для этих адресов?

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

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

котировка

Что происходит на стороне клиента, когда мы делаем это? Есть люди должны скачать новый клиент?

Да.

котировка

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

Предупреждение будет выдано.

котировка

Если они не скачать новый клиент, они по-прежнему совершать сделки, которые не будут перенесены на новую цепочку?

Скорее всего.

котировка

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

Создание полного плана и тестирование было бы хорошо.

Цитата: theymos от 17 мая 2011 года, 1:06:37 AM

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

котировка

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

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

котировка

Это один из способов, я думаю, что мы могли бы справиться с этим. Таким образом, мы имеем блок прикреплен к концу v1 blockchain, "версия генезис обновления блока", Что по существу вновь подтверждает предыдущие blockchain в нашем новом безопасного хэша-алгоритме и определяют параметры хэша новой цепи? Запись всей цепи, которые пришли раньше, говоря "Блок 1 в SHA-3 хэш-X, блок 2 ...",

котировка

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

котировка

Что происходит на стороне клиента, когда мы делаем это? Есть люди должны скачать новый клиент?

Да.

котировка

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

Предупреждение будет выдано.

котировка

Скорее всего.

котировка

Создание полного плана и тестирование было бы хорошо.

Поэтому я спросил, что последовательность вопросов, теоретически это возможно для нас, чтобы разработать планы восстановления в настоящее время, а также осуществлять поддержку таких в клиенте, так что, если клиент сталкивается с блоком обновления, он может просто перенастроить себя и идти дальше. Если бы мы сделали это, мы могли бы перейти Bitcoin на новый крипто профилактически - если SHA2 продолжает деградировать и SHA-3 в конце концов доказывает себя достойно, мы можем модернизировать до катастрофы.

Если мы делаем это достаточно рано, код может сделать это в 51% + из клиентов сети, а когда сеть решает переключиться, большинство клиентов могут прийти с ним без обновления - или, по крайней мере, отключить себя. Но предзагрузку бы предпочтительнее.

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

Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM

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

котировка

Таким образом, мы откатить всю сеть для, возможно, через неделю?

Я не могу думать ни о каком справедливом пути.

котировка

Запись всей цепи, которые пришли раньше, говоря "Блок 1 в SHA-3 хэш-X, блок 2 ...",

Я думал только один хэш для всей вещи. Может быть, "предыдущий блок" поле в генезисе блоке версии будет хэш всех хэшей, или корень дерева Merkle.

котировка

Если бы мы сделали это, мы могли бы перейти Bitcoin на новый крипто профилактически - если SHA2 продолжает деградировать и SHA-3 в конце концов доказывает себя достойно, мы можем модернизировать до катастрофы.

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

котировка

Если мы делаем это достаточно рано, код может сделать это в 51% + из клиентов сети, а когда сеть решает переключиться, большинство клиентов могут прийти с ним без обновления - или, по крайней мере, отключить себя. Но предзагрузку бы предпочтительнее.

Bitcoin уже детектировать случай, когда новые версии блока / ТХ имеют большую часть сети. Он скажет:

котировка

ПРЕДУПРЕЖДЕНИЕ: Отображаемые сделки не могут быть правильными! Вы, возможно, потребуется обновить или другие узлы, возможно, потребуется обновить.

RPC также отключается, поэтому все сайты Bitcoin перестанут работать.

Цитата: theymos от 17 мая 2011 года, 2:01:45 AM

Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM

Таким образом, мы откатить всю сеть для, возможно, через неделю?

Я не могу думать ни о каком справедливом пути.

Я не могу видеть, как это будет необходимо.

Даже если вы взломали хэш, и можете выиграть / переписывать каждый блок, ваши блоки по-прежнему должны быть подтверждаемыми, чтобы идти несколько блоков глубоко, и вам необходимо полностью переписать остальную часть цепи, с тестирующими операциями, что означает, используя свой BTC раздуть блок для создания хэша матча, который, кажется, как она станет столь же интенсивно, как в вычислительном отношении добычи полезных ископаемых, так как вы не можете создать паб ключа Sigs по чертежу.

Это только кажется, как беспокойство, как уязвимость обработки на 51%, что не все так страшно.

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

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

Если ошибка хэш-функция является беспокойство все, что мы должны сделать, это позволить некоторое подмножество, крипто-несвязанный альтернативных хэшей, и, возможно, даже требуют один, чтобы использовать каждый mod64 блоков, в качестве строительных лесов в том случае, если текущий хэш получает брошенной. Это должно быть развернуто по крайней мере 6Mo до его использования - вероятно, связанно с номером блоком опрокидывания, и нужно будет сделать в ближайшее время, прежде чем люди начинают строить встраиваемые устройства, использующие Bitcoin. Трюк набирает хэшей, а также создание кода GPU грызть их.

Теперь, если Pub ключа часть разбиваются на фундаментальном уровне, то мы SOL, которые есть даже какая-либо не-большая простой паб-ключ система на основе?

Цитата: WNS от 17 мая 2011 года, 1:17:18 PM

Цитата: theymos от 17 мая 2011 года, 2:01:45 AM

Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM

Таким образом, мы откатить всю сеть для, возможно, через неделю?

Я не могу думать ни о каком справедливом пути.

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

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

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

Мы также можем проверить профилактические меры безопасности там, как и "строительные леса" хэш-вы описали, или, возможно, осведомленные шахтер всегда можно добавить другой тип хэша для блока? Если у нас есть разнородный набор хэш, используемых в блоках, в дополнении к каноническим УВХ2 мы уменьшаем наше воздействие атаки; это будет легко для клиентов, чтобы проверить, хэши они понимают и игнорируют те, которые они не делают, но мы должны убедиться, что они на самом деле повышения безопасности, а не просто быть теплым Fuzzies. Например, если все хэши не являются обязательными, но SHA2, что держит кого-то из перезаписи блока цепь и просто не прикладывая дополнительных услуг в или перефразируя их содержание атаки?

Цитата: Anisoptera от 17 мая 2011 года, 6:28:47 PM

Я хотел бы видеть аргумент за нарушение ОГО, не нарушая паб-ключ. В то время как вы могли бы, конечно, создать другие возможные исходные данные для ОГО хэша, если вы сломали хэш алго вам все равно нужно выполнить четыре вещи:

1) найти такой блок данных, который был в формате TX
2) порождает пару Публичной, соответствующую действующие ТЕ, который соответствует вашей хэш
3) убедитесь, что scriptSig был действителен в настоящее время не пустой бумажник
4) убедитесь, что ваш генерируется случайным образом ТХ согласуется с содержанием встроенного scriptSig

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

Цитата: WNS 18 мая 2011, 12:03:50 AM

Цитата: Anisoptera от 17 мая 2011 года, 6:28:47 PM

Что делать, если разрыв таким образом, что я могу просто взять существующий ТХ, изменить его, чтобы пойти в мой адрес вместо этого, затем пэд его с тщательно отобранными мусора в местах, которые Bitcoin не заботится о (в scriptSig, может быть) и написать, что АЯ в блок? Если я могу сделать произвольный хэш данных для заданного значения, не должен генерировать новые ТМ - можно перенаправить старые.

Цитата: Anisoptera от 18 мая 2011 года, 7:06:51 AM

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

ломая паб-ключ ломается ВСЁ о Bitcoin, нет никакого плана на случай непредвиденных. Если кто-то не приходит в голову паб-ключ системы, которая работает на другой математической основе, чтобы не быть разбитой в то же время, игра окончена. Не будучи кандидатом на Филдса, я не в состоянии внести свой вклад в этот план на случай чрезвычайных ситуаций.

Цитата: WNS 18 мая 2011, 12:47:06 PM

Цитата: Anisoptera от 18 мая 2011 года, 7:06:51 AM

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

В этом случае, однако, я думаю, что мы были бы в состоянии сказать различие между законным и ложной операцией. Законен ТЙ является тот, который не имеет обивку мусора в нем. Но это не обязательно является единственным способом это могло произойти.

Цитата: Anisoptera от 18 мая 2011 года, 7:56:58 PM

хорошо, теперь вы делаете ставку на площади два астрономический вряд ли хэш столкновений. Во-первых, что существует даже допустимый хэш столкновения для подписанного хэша, а затем, что это точно такая же хэш столкновения применяется к ТХ, как некоторое время. Даже если вы можете произвести обратные хэш в 0 раз, вы не можете вытащить хеш-коллизий из воздуха.

Цитата: WNS 18 мая 2011, 10:42:36 PM

Цитата: Anisoptera от 18 мая 2011 года, 7:56:58 PM

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

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

Цитата: Anisoptera от 19 мая 2011 года, 5:47:32 AM

если у вас есть 256 бит вы можете сделать все, что вы хотите с. Если вы можете определить даже 3-4 байта в ОМ блоке, который можно покрутить, не делая его недействительным или бесполезно, тогда я буду впечатлен, от моего чтения спецификации, что не должно быть возможно.

Оказывается, что вы сравниваете число возможных состояний, скажем 1k данных, к числу состояний в хэш. Для неограниченных данных, то, очевидно, много хэша столкновения в 1k блока, но мы говорим не о всех возможных блоках 1k данных, только о тех, которые относятся также ТЕ.

Большинство данных в ОМ не twittleable, потому что эфир статичного, или производный от остальной части данных, ни один из хэш или заголовков не twiddleable, но twiddleing всего остального требует также вертели хэш. Только данные, которые вы могли бы вертеть это только данные, которые вы не можете получить что-нибудь из рандомизации, адрес получателя.

Было бы еще неплохо иметь спецификацию реализации на месте для алгоритма хеширования переключения. В идеале вы хотите, чтобы запустить систему хэш, который не имеет никаких известных уязвимостей, а также возможность легко и быстро переключаться с одного хэш-системы в другую. Это не займет много работы, чтобы полностью убить доверие людей в валюте, особенно тот, который полагается крипто вуду работать. Как и катастрофы на Фукусиме, все, что вам нужно сделать, это кричать достаточно громко, что X использует Y, и Y представляет собой (что угодно), поэтому Х (независимо) для того, чтобы большинство людей в это поверить. Способность идти "Вот дерьмо"Уведомить всех, и коллективно голосовать переключатель будет очень мощным средством для смягчения этого эффекта.

Код протокола таким образом, чтобы:
Если 26 из последних 40 блоков имеют «использовать новый хэш» переключен на да, то все к некондиционному шахтеру и официальному клиент будет игнорировать все блоки не используя новый хэш от блока 26 и далее. Клиенты могут читать оба типа блоков, и совершать операции в обоих типов блоков, так как это была отодвинута потенциально лет, прежде чем это было необходимо. И сразу же возникает обнаружено уязвимость, шахтеры могут решить для себя, как группа, должны ли они переход к новой, более жесткой системе хэша.

Цитата: WNS от 20 мая 2011 года, 1:33:42 AM

Цитата: Anisoptera от 19 мая 2011 года, 5:47:32 AM

Да, это то, что я изначально думал тоже. Но, может быть, вы должны прочитать больше о scriptSig. Кажется, вроде как все, что мне нужно сделать, это ремесло scriptPubKey, что в конечном итоге проверяющий к одному из моих адресов. Это не так ограничены, как только изменение адреса - я могу делать почти все, что я хочу до тех пор, как он хэши то же самое. Он не должен идти на действительный адрес Bitcoin, это просто необходимо, чтобы в конечном счете вернуться верно для некоторых входных сигналов, который получает предварённое к нему в новом ТХ. Это намного свободнее из ограничений. ScriptPubKey может быть произвольной длиной - более чем достаточно для 256 бит, которые могут быть добавлены к ОМУ.

Если у меня есть контроль достаточно того, что я могу сделать что-то есть то, что хэш-я хочу, я могу изменить выходы туда, куда я хочу, потому что даже если я не могу ничего более интересного, чем сделать scriptSig всегда возвращают истинное (следующий человек, чтобы написать делать ТЙ с этим, как вход получает его), то я тоже могу написать совершенно новые ТЙ позже в blockchain, потребляющий, что выход и фактически отправляет на адрес, который у меня есть. Так как мы уже переписывания blockchain, я выиграю - теперь я могу переписать произвольный ПРД туда, куда я хочу, и переписать blockchain так, что те, ТЕ похоронены глубоко.

Как я уже сказал, что это будет своего рода очевидно, какие ТМ были недопустимые в данном случае, так как они явно не будут использовать стандартные scriptSigs, но это не обязательно будет являться показателем железным навсегда.

Цитата: Latregetic 20 мая 2011, 12:10:05 PM

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

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

Откат транзакции имеет приблизительно 99,9% шанс убить Bitcoin. Это время вниз в течение продолжительного периода времени, менее вероятно, чтобы убить его, но все же весьма вероятно, в зависимости от продолжительности ППР и эффектов. Мы бежим финансовую сеть здесь. Если что-нибудь, как это происходит, и люди теряют деньги из-за этого, мы сделанный. И люди не будучи в состоянии принять сделки в течение длительного времени будет считаться "потерять деньги",

29 апреля 2011, 1:54:56 AM	# 1
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Будет ли Bitcoin удастся навсегда без существенных изменений? Если ответ будет "да" то все в порядке, а остальная часть этого поста не имеет значения. Bitcoin все еще находится на относительно ранней стадии развития. Некоторые желательные и разработаны функции по-прежнему должны быть реализованы, и она не была проверена либо определенными атаками или "мейнстрим-принятие" уровень операций в секунду. Это правдоподобно представить, таким образом, что программное обеспечение и / или протокол должен быть изменено в ответ на ситуацию, которые будут происходить. Реализация этих изменений является большой проблемой для инженеров однако. Всякий раз, когда программное обеспечение меняется, есть небольшой, но важный шанс, что новая версия будет хуже, чем старая. Очевидно, что намерение состоит в том, что новая версия превосходит старую версию, но это хорошо известная реальность в мире программной инженерии, что обновление программного обеспечения может привести к катастрофе. В качестве приложений созревают, отношение приращения стоимости обновления к значению текущего программного обеспечения стремится к нулю, а экономический ущерб от стихийного бедствия, имеет тенденцию к увеличению. Даже при тщательном тестировании вероятности транспортировочного новой версии, которая будет нарушена не может быть сведена к нулю и уравнение подразумеваемого этих факты, как правило, означают, что обновления становятся все более редкими, существенными и нервным. С недавним падением стоимости доллара и других национальных валют по отношению к Bitcoin, свои запасы Bitcoin стать нетривиальным часть своих ликвидных активов и всего, что ставит под угрозу эти запасы является серьезной проблемой. Это должно весить тяжело на умы разработчиков. В настоящее время клиент Bitcoin является особенно проблематичным в том, что это часть программного обеспечения, которое только может быть надлежащим образом проверено, когда в сети с другими клиентами с гетерогенными версиями. К счастью, на данный момент, сеть имеет только один вид клиента. Что Bitcoin необходимо реалистичный тест сети. В настоящее время тестовой сети является отличным началом, но активность на нем слишком капризна и непредставительной основную сеть. Тока тестовой сети больше из R&D сеть, как показывает тот факт, что нестандартные сделки в настоящее время разрешены. Я полагаю, что новая сеть QA инициироваться, которые пользователи Bitcoin могут выбрать для поддержки. QA поддерживающие пользователи будут установлены два Bitcoin клиентов; один работает текущий клиент и один запуск текущего кандидата QA. Новые операции, которые пользователь подстрекает на главной сети будет отображаться в соответствующем новые транзакции в сети QA. Шахтеры будут предложено посвятить крошечную, но глобально неподвижную часть их текущей реальную добычу мощности, так что сеть QA имеет такое же распределение добычи мощности в качестве основной сети. Сеть QA может работать в течение нескольких месяцев с кандидатом один релиза и уверенностью в хорошем кандидат будет расти, как это можно было бы показать, чтобы справиться с текущей нагрузкой основной сделки. Bitcoin инженеры программного обеспечения могут выбрать, чтобы ввести дополнительные другие транзакции в сеть QA, чтобы проверить, как он справляется ни с нападениями или более высоким уровнем законных сделок. Там должен быть механизм, чтобы исключить гриферов из QA сети, которые могут помешать тестированию либо введением нежелательных операций или добычи полезных ископаемых с слишком высокой долей их реальной добычи энергии. Обычно я предлагаю идеи с техническими деталями лучше конкретизировать, но в данном случае, это довольно большая задача. Поэтому я представить идею для рассмотрения на его общих принципах. ByteCoin

29 апреля 2011, 9:35:14 AM	# 2
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Получил 1806 Биткоинов Реальная история. Это разумная идея, но много работы, которая требует координации с большим количеством шахтеров. Я думаю, что лучший подход просто разработать реальный набор тестов. Это не очень большой для финансового программного обеспечения, не имеют тестов на всех и все, что сводится к тому, люди тщательно вручную каждый выпуск (будь то в сети QA или нет) не будет очень обнадеживающим. Хорошая вещь о наборе тестов является то, что он может быть запущен после того, как каждое изменение производится. Таким образом, вы можете найти проблемы, как только они введены вместо того, чтобы сделать потенциально очень сложный распределенный бинарный поиск.

16 мая 2011, 7:02:29 PM	# 3
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Я собирался начать новую тему об этом, но это, кажется, как хороший матч сейчас. В основном я думал о аргумент против Bitcoin говоря "Криптографические алгоритмы всегда в конечном счете терпят неудачу." Вы и я знаем, что если SHA256 должны были быть разбиты завтра мы могли бы, вероятно, еще спасти блок цепь и переключиться на какой-то сплошной крипто. Проблема заключается в том, что слово "вероятно", Мы на самом деле не знаю, как бы мы добиться такого изменения еще. Представьте себе ситуацию, когда, завтра кто-то ломает SHA таким образом, что они могут переписать блок цепи произвольно, или перезаписать сделки, или что-то в этом роде. Я согласен, что это крайне маловероятно, но по мере увеличения продолжительности времени мы говорим, вероятность приближается к 1. Мы даже не перестает генерировать монеты до 2040 Можете ли вы сказать с полной уверенностью, что ВСЕ криптографические элементы наша текущая реализация будет оставаться полностью ненарушенной в течение следующих 30 лет? Если вы говорите, да на этот вопрос вы с умом, а также явно не работаете в тесте. Дело в том, что я говорил людям, что это не беспокоит, потому что мы можем просто поменять на крипто ... Но никто фактически не думал о том, как мы бы идти об этом, что, не говоря уже о проверке этих планов. Это немного страшно. Время, чтобы сделать это не тогда, когда мы должны. Таким образом, мы должны предположить, что это произойдет, и есть планы на месте для того, как это будет сделано. Как мы могли оправиться от катастрофы такого рода? Что можно сказать о менее тяжелых случаях, когда она сломана несколько (например md5), но Bitcoin сразу не нарушена? Мы все еще должны четко перейти на замену скомпрометированных крипта, но сценарий отличается - как мы обрабатываем переход? Можно ли перейти таким образом, чтобы ни один не теряет сделок в переходе? Я думаю, что мы должны разработать такой план на случай непредвиденных обстоятельств для обоих сценариев (и любые другие, мы думаем), а затем проверить такие планы на тестовых сетях. Что следует учесть: Используя новый блок цепь может быть элементом этих планов, или мы могли бы придумать способ, чтобы продолжить текущую цепочку в качестве основы. Можем ли мы принять старой цепи сделок в нашу новую цепь на лету, преобразования их форматов на то, что мы хотим, чтобы в нашей новой? В не катастрофический сценарий, если мы не будем делать это, как мы можем предотвратить людей, которые не получают памятку от мошенничества (старая Bitcoin сеть все еще существует после смены, человек тратит старые через БТД сделок, которые не будут портированы к новой цепи) Как мы выздороветь, если злоумышленник был известен, чтобы иметь возможность переписывать блок цепи произвольно? Как мы можем восстановить максимальное количество легитимных данных? У меня нет никакого кода еще, только идеи крутятся в моей голове. Я хочу, чтобы твердый ответ на вопрос "что произойдет, если крипто сломано" что лучше, чем встречный вопрос "что произойдет, если правительство рухнет", Потому что одна из тех вещей, на самом деле немного больше шансов, чем другие. Я не хочу отвечать "Ну, мы можем просто изменить криптографию, но никто не действительно работает, как мы делаем это." Я хочу быть в состоянии сказать, "мы тестировали полный переход в этом точный худшем случае, и большая часть сети уже понимают, как реализовать этот план." В Internet Time один день это вечность. Час достаточно долго для кого-то, чтобы нанести значительный ущерб. Мы не можем быть с этой дискуссией на день 0 или он действительно уничтожит нас. Мы должны быть в состоянии иметь сеть работает на неразрывной крипто в течение часа, зная, что он разорен, и мы должны быть уверены, что сделать это будет идти гладко.

16 мая 2011, 8:02:39 PM	# 4
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 16 мая 2011 года, 7:02:29 PM Таким образом, мы должны предположить, что это произойдет, и есть планы на месте для того, как это будет сделано. Как мы могли оправиться от катастрофы такого рода? Что можно сказать о менее тяжелых случаях, когда она сломана несколько (например md5), но Bitcoin сразу не нарушена? Мы все еще должны четко перейти на замену скомпрометированных крипта, но сценарий отличается - как мы обрабатываем переход? Можно ли перейти таким образом, чтобы ни один не теряет сделок в переходе? Мы пришли к согласию относительно содержания блоков, хэш их все с безопасного хэша, и жесткий код, который в Bitcoin.

16 мая 2011, 8:12:39 PM	# 5
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: theymos от 16 мая 2011 года, 8:02:39 PM Цитата: Anisoptera от 16 мая 2011 года, 7:02:29 PM Таким образом, мы должны предположить, что это произойдет, и есть планы на месте для того, как это будет сделано. Как мы могли оправиться от катастрофы такого рода? Что можно сказать о менее тяжелых случаях, когда она сломана несколько (например md5), но Bitcoin сразу не нарушена? Мы все еще должны четко перейти на замену скомпрометированных крипта, но сценарий отличается - как мы обрабатываем переход? Можно ли перейти таким образом, чтобы ни один не теряет сделок в переходе? Мы пришли к согласию относительно содержания блоков, хэш их все с безопасного хэша, и жесткий код, который в Bitcoin. Я предположил, что это. Это не отвечает на все мои вопросы, хотя. Каждый из этих шагов является лишь handwave. Черт, вы в основном просто процитировал текущую Bitcoin спецификацию на меня. Как мы планируем прийти к этому соглашению? Что произойдет, если атака не публикуется на некоторое время, и поэтому любое количество блоков имеет некорректные данные в них? Как мы выбираем из плохих, потеряв минимум хороших ОГО? Как мы хэширования Согласованного содержания? Какой формат это займет? Будет ли это совершенно новый генезис блок, или новый тип блока, который добавляется к текущей блочной цепи? Как мы вновь обеспечить деньги, содержащиеся в blockchain без закрытых ключей для этих адресов? Что происходит на стороне клиента, когда мы делаем это? Есть люди должны скачать новый клиент? Если да, то когда они используют старый клиент, есть ли признаки того, что им нужно скачать новый клиент? Если они не скачать новый клиент, они по-прежнему совершать сделки, которые не будут перенесены на новую цепочку? Могут обращающие людям продолжать использовать старую, сломанную blockchain в течение длительного периода времени? Это то, что я имею в виду. Мы "знать" как мы бы это сделать, но никто не удосужился на самом деле придумать фактического плана, не говоря уже протестировали сценарий. Разработка этого плана займет очень много времени - там будет отверстие в первом проекте, некоторые люди не согласятся на вещах, на первом, и так далее. Время, чтобы пройти через этот процесс не "Вот дерьмо, SHA2 было сломано с первой-прообразом атакой на неделю теперь через нераскрытый использовать и у нас есть люди, переписывание blockchain и doublespending, как сумасшедшие, что мы делаем сейчас?", его "Хорошо, этот сценарий неизбежно дается достаточно времени, так что давайте начнем разработку и тестирование решения, с тем, что, когда это произойдет, усилия могут сосредоточиться на реальных проблемах, а не основной подготовки." Чтобы было ясно, нам нужны планы для различных сценариев. 0day жесткий перерыв в нашем крипто это не единственный случай, когда мы хотим сделать что-то вроде этого. Нам нужно иметь план упреждающих изменений тоже.

17 мая 2011, 1:06:37 AM	# 6
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 16 мая 2011 года, 8:12:39 PM Как мы планируем прийти к этому соглашению? Мы будем иметь обсуждение здесь и на IRC. Тот, кто контролирует bitcoin.org принимает окончательное решение о том, что есть в списке, и если другие люди не согласны, они будут выступать различные версии на своих сайтах. котировка Что произойдет, если атака не публикуется на некоторое время, и поэтому любое количество блоков имеет некорректные данные в них? Как мы выбираем из плохих, потеряв минимум хороших ОГО? Мы пришли к соглашению об этом в то время. Я бы выступать удаление всех блоков, где, вероятно, что большинство сделок являются незаконными. Большинство законных сделки могут быть отменены, не делая слишком много повреждений, так как честные отправители новых сделок. котировка Как мы хэширования Согласованного содержания? По крайней мере, все содержимое блока должно быть хэшируются. Может быть, позже хэш "баланс" только неизрасходованные сделки могут быть созданы в интересах эффективности. Они будут версии 1 блоки, а позже блоки будут версией 2 (аналогично для сделок). Возможно, первая версия 2 блок будет ссылаться на этот хэш вместо предыдущего блока хэш. котировка Как мы вновь обеспечить деньги, содержащиеся в blockchain без закрытых ключей для этих адресов? Если SHA-256 или RIPEMD-160 нарушается, ключ не является необходимым. Шахтеры запомнить содержимое неизрасходованных сделок, индексированные по новой безопасной хэш. Люди, которые хотят провести сделку, обратитесь к новому защищенному хэшу вместо незащищенной хэш. Если подписание становится неработоспособным, Bitcoin, вероятно, придется перезапустить. Если атака не позволяет восстановления закрытых ключей, возможно, одни и те же пары ключи могут быть использованы с более безопасным алгоритмом. котировка Что происходит на стороне клиента, когда мы делаем это? Есть люди должны скачать новый клиент? Да. котировка Если да, то когда они используют старый клиент, есть ли признаки того, что им нужно скачать новый клиент? Предупреждение будет выдано. котировка Если они не скачать новый клиент, они по-прежнему совершать сделки, которые не будут перенесены на новую цепочку? Скорее всего. котировка Это то, что я имею в виду. Мы "знать" как мы бы это сделать, но никто не удосужился на самом деле придумать фактического плана, не говоря уже протестировали сценарий. Создание полного плана и тестирование было бы хорошо.

17 мая 2011, 1:26:46 AM	# 7
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: theymos от 17 мая 2011 года, 1:06:37 AM Мы будем иметь обсуждение здесь и на IRC. Тот, кто контролирует bitcoin.org принимает окончательное решение о том, что есть в списке, и если другие люди не согласны, они будут выступать различные версии на своих сайтах. Итак, как долго вы ожидаете это обсуждение взять? Кто разрешено участвовать? Как мы получаем слово, что даже это обсуждение происходит? Нам нужно, чтобы это произошло в течение нескольких часов перерыва. котировка Мы пришли к соглашению об этом в то время. Я бы выступать удаление всех блоков, где, вероятно, что большинство сделок являются незаконными. Большинство законных сделки могут быть отменены, не делая слишком много повреждений, так как честные отправители новых сделок. Таким образом, мы откатить всю сеть для, возможно, через неделю? Реверсивный законные сделки звучит ужасно. Я бы предположил, что количество честных людей, которые будут повторно отправить платеж за то, что они получили неделю назад, в лучшем случае половина. Если кто-то купил с Bitcoins, а потом их деньги вернулись в свой счет, мне трудно поверить, что они будут исследовать, почему это произошло, и исправить ошибку. Я не знаю, как мы бы эвристики для отделения плохо от хороших сделок, хотя. Но это может вытрясти из более подробного обсуждения того, что существуют угрозы. котировка По крайней мере, все содержимое блока должно быть хэшируются. Может быть, позже хэш "баланс" только неизрасходованные сделки могут быть созданы в интересах эффективности. Они будут версии 1 блоки, а позже блоки будут версией 2 (аналогично для сделок). Возможно, первая версия 2 блок будет ссылаться на этот хэш вместо предыдущего блока хэш. Это один из способов, я думаю, что мы могли бы справиться с этим. Таким образом, мы имеем блок прикреплен к концу v1 blockchain, "версия генезис обновления блока", Что по существу вновь подтверждает предыдущие blockchain в нашем новом безопасного хэша-алгоритме и определяют параметры хэша новой цепи? Запись всей цепи, которые пришли раньше, говоря "Блок 1 в SHA-3 хэш-X, блок 2 ...", котировка Если SHA-256 или RIPEMD-160 нарушается, ключ не является необходимым. Шахтеры запомнить содержимое неизрасходованных сделок, индексированные по новой безопасной хэш. Люди, которые хотят провести сделку, обратитесь к новому защищенному хэшу вместо незащищенной хэш. Если подписание становится неработоспособным, Bitcoin, вероятно, придется перезапустить. Если атака не позволяет восстановления закрытых ключей, возможно, одни и те же пары ключи могут быть использованы с более безопасным алгоритмом. Это зависит от того, правильно? В некоторых случаях мы могли бы только знать, что он сломан, но не как сделать это сами. В других это общественный подвиг. Он может по-прежнему требует много энергии, чтобы сломать, только часть того, что это было, или это может быть тривиальным, или это может быть просто крошечные трещины в плотине. Вероятно, мы должны отработать все возможные сценарии отказов и их классификации, а также определить, как защититься от каждого. котировка котировка Что происходит на стороне клиента, когда мы делаем это? Есть люди должны скачать новый клиент? Да. котировка Если да, то когда они используют старый клиент, есть ли признаки того, что им нужно скачать новый клиент? Предупреждение будет выдано. котировка Если они не скачать новый клиент, они по-прежнему совершать сделки, которые не будут перенесены на новую цепочку? Скорее всего. котировка Это то, что я имею в виду. Мы "знать" как мы бы это сделать, но никто не удосужился на самом деле придумать фактического плана, не говоря уже протестировали сценарий. Создание полного плана и тестирование было бы хорошо. Поэтому я спросил, что последовательность вопросов, теоретически это возможно для нас, чтобы разработать планы восстановления в настоящее время, а также осуществлять поддержку таких в клиенте, так что, если клиент сталкивается с блоком обновления, он может просто перенастроить себя и идти дальше. Если бы мы сделали это, мы могли бы перейти Bitcoin на новый крипто профилактически - если SHA2 продолжает деградировать и SHA-3 в конце концов доказывает себя достойно, мы можем модернизировать до катастрофы. Если мы делаем это достаточно рано, код может сделать это в 51% + из клиентов сети, а когда сеть решает переключиться, большинство клиентов могут прийти с ним без обновления - или, по крайней мере, отключить себя. Но предзагрузку бы предпочтительнее. У меня нет плана в моей голове прямо сейчас. Я даже не знаю, все сценарии. Но я хочу, чтобы начать говорить об этом сейчас; Bitcoin растет в геометрической прогрессии прямо сейчас, и чем дольше мы ждем, тем больше риск.

17 мая 2011, 2:01:45 AM	# 8
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM Итак, как долго вы ожидаете это обсуждение взять? Кто разрешено участвовать? Как мы получаем слово, что даже это обсуждение происходит? Нам нужно, чтобы это произошло в течение нескольких часов перерыва. Лишь немногие из доверенных людей, должны прийти к соглашению о содержании блока цепи, если нет каких-либо существенных разногласий по этому поводу. Если есть разногласия, это может занять несколько дней, чтобы достичь консенсуса. Скорость не кажется, что важно для меня, так как он будет еще некоторое время для всех, чтобы обновить как только будет достигнуто соглашение. котировка Таким образом, мы откатить всю сеть для, возможно, через неделю? Я не могу думать ни о каком справедливом пути. котировка Запись всей цепи, которые пришли раньше, говоря "Блок 1 в SHA-3 хэш-X, блок 2 ...", Я думал только один хэш для всей вещи. Может быть, "предыдущий блок" поле в генезисе блоке версии будет хэш всех хэшей, или корень дерева Merkle. котировка Если бы мы сделали это, мы могли бы перейти Bitcoin на новый крипто профилактически - если SHA2 продолжает деградировать и SHA-3 в конце концов доказывает себя достойно, мы можем модернизировать до катастрофы. Я хотел бы, чтобы поддержать операции с указанием типа используемого хэша. Это позволит людям выбирать свою собственную безопасность. Более медленные алгоритмы могут требовать более высокой платы. котировка Если мы делаем это достаточно рано, код может сделать это в 51% + из клиентов сети, а когда сеть решает переключиться, большинство клиентов могут прийти с ним без обновления - или, по крайней мере, отключить себя. Но предзагрузку бы предпочтительнее. Bitcoin уже детектировать случай, когда новые версии блока / ТХ имеют большую часть сети. Он скажет: котировка ПРЕДУПРЕЖДЕНИЕ: Отображаемые сделки не могут быть правильными! Вы, возможно, потребуется обновить или другие узлы, возможно, потребуется обновить. RPC также отключается, поэтому все сайты Bitcoin перестанут работать.

17 мая 2011, 1:17:18 PM	# 9
WNS Сообщений: 39 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: theymos от 17 мая 2011 года, 2:01:45 AM Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM Таким образом, мы откатить всю сеть для, возможно, через неделю? Я не могу думать ни о каком справедливом пути. Я не могу видеть, как это будет необходимо. Даже если вы взломали хэш, и можете выиграть / переписывать каждый блок, ваши блоки по-прежнему должны быть подтверждаемыми, чтобы идти несколько блоков глубоко, и вам необходимо полностью переписать остальную часть цепи, с тестирующими операциями, что означает, используя свой BTC раздуть блок для создания хэша матча, который, кажется, как она станет столь же интенсивно, как в вычислительном отношении добычи полезных ископаемых, так как вы не можете создать паб ключа Sigs по чертежу. Это только кажется, как беспокойство, как уязвимость обработки на 51%, что не все так страшно. Как насчет того, чтобы создать некоторую память / сторожевое в к клиенту, чтобы он будет голосовать в пользу непрерывности над сильно расходящимся блоком цепью? Безопасность blockchain будет снижена, если хэш треснул, но blockchain не станет недействительной, или тривиальным редактируемым, из-за данные Публичную быть хэшируется. Если ошибка хэш-функция является беспокойство все, что мы должны сделать, это позволить некоторое подмножество, крипто-несвязанный альтернативных хэшей, и, возможно, даже требуют один, чтобы использовать каждый mod64 блоков, в качестве строительных лесов в том случае, если текущий хэш получает брошенной. Это должно быть развернуто по крайней мере 6Mo до его использования - вероятно, связанно с номером блоком опрокидывания, и нужно будет сделать в ближайшее время, прежде чем люди начинают строить встраиваемые устройства, использующие Bitcoin. Трюк набирает хэшей, а также создание кода GPU грызть их. Теперь, если Pub ключа часть разбиваются на фундаментальном уровне, то мы SOL, которые есть даже какая-либо не-большая простой паб-ключ система на основе?

17 мая 2011, 6:28:47 PM	# 10
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: WNS от 17 мая 2011 года, 1:17:18 PM Цитата: theymos от 17 мая 2011 года, 2:01:45 AM Цитата: Anisoptera от 17 мая 2011 года, 1:26:46 AM Таким образом, мы откатить всю сеть для, возможно, через неделю? Я не могу думать ни о каком справедливом пути. Я не могу видеть, как это будет необходимо. Даже если вы взломали хэш, и можете выиграть / переписывать каждый блок, ваши блоки по-прежнему должны быть подтверждаемыми, чтобы идти несколько блоков глубоко, и вам необходимо полностью переписать остальную часть цепи, с тестирующими операциями, что означает, используя свой BTC раздуть блок для создания хэша матча, который, кажется, как она станет столь же интенсивно, как в вычислительном отношении добычи полезных ископаемых, так как вы не можете создать паб ключа Sigs по чертежу. Это только кажется, как беспокойство, как уязвимость обработки на 51%, что не все так страшно. Как насчет того, чтобы создать некоторую память / сторожевое в к клиенту, чтобы он будет голосовать в пользу непрерывности над сильно расходящимся блоком цепью? Безопасность blockchain будет снижена, если хэш треснул, но blockchain не станет недействительной, или тривиальным редактируемым, из-за данные Публичную быть хэшируется. Если ошибка хэш-функция является беспокойство все, что мы должны сделать, это позволить некоторое подмножество, крипто-несвязанный альтернативных хэшей, и, возможно, даже требуют один, чтобы использовать каждый mod64 блоков, в качестве строительных лесов в том случае, если текущий хэш получает брошенной. Это должно быть развернуто по крайней мере 6Mo до его использования - вероятно, связанно с номером блоком опрокидывания, и нужно будет сделать в ближайшее время, прежде чем люди начинают строить встраиваемые устройства, использующие Bitcoin. Трюк набирает хэшей, а также создание кода GPU грызть их. Теперь, если Pub ключа часть разбиваются на фундаментальном уровне, то мы SOL, которые есть даже какая-либо не-большая простой паб-ключ система на основе? Вы делаете довольно много предположений о том, что это и не представляется возможным. Сценарий вы описываете один сценарий - один, где скомпрометированы блокируют только хэш и не ТЕ хэш. Если мы не можем убедительно доказать, что определенный сценарий бедствия невозможно, мы должны предположить, что это, и написать план для него. Даже если этот план состоит из "бросить наши руки и смотреть, как миллиарды долларов валюты идет вверх в дыме, потому что мы не можем восстановить, из-за й у г." например, как вы сказали, прорыв в факторинговых простых чисел будет трудно перерыв, но только потому, что мы не имеем другой алгоритм, который не зависит от этого. Но, возможно, что мы делаем, и если да, то мы должны найти и договориться о следующем алгоритме сейчас, так что мы готовы в этом случае. Одним из преимуществ этого планирования была бы возможность просто код поддержки для всех алгоритмов на случай непредвиденных обстоятельств Into Bitcoin превентивно; это позволит нам проверить, что такое переключение будет идти гладко. Я любя ответы до сих пор. Нужен ли нам отдельный поток для этого? Моя цель состоит в том, чтобы разработать планы действий в чрезвычайных ситуациях через обратную связь от сообщества (я не претендую, чтобы понять крипто отлично, к примеру, так что я не знаю, если некоторые атаки действительно невозможно), а затем мы можем проверить каждый план в другой среде , После того, как мы сделали, мы должны иметь документ, который четко описывает действия, которые мы будем принимать в каждом конкретном случае, так что нет никаких сюрпризов о таких вещах, как, кто принимают решения или то, что процедура будет. Мы также можем проверить профилактические меры безопасности там, как и "строительные леса" хэш-вы описали, или, возможно, осведомленные шахтер всегда можно добавить другой тип хэша для блока? Если у нас есть разнородный набор хэш, используемых в блоках, в дополнении к каноническим УВХ2 мы уменьшаем наше воздействие атаки; это будет легко для клиентов, чтобы проверить, хэши они понимают и игнорируют те, которые они не делают, но мы должны убедиться, что они на самом деле повышения безопасности, а не просто быть теплым Fuzzies. Например, если все хэши не являются обязательными, но SHA2, что держит кого-то из перезаписи блока цепь и просто не прикладывая дополнительных услуг в или перефразируя их содержание атаки?

18 мая 2011, 12:03:50 AM	# 11
WNS Сообщений: 39 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 17 мая 2011 года, 6:28:47 PM Вы делаете довольно много предположений о том, что это и не представляется возможным. Сценарий вы описываете один сценарий - один, где скомпрометированы блокируют только хэш и не ТЕ хэш. Если мы не можем убедительно доказать, что определенный сценарий катастрофы невозможно Я хотел бы видеть аргумент за нарушение ОГО, не нарушая паб-ключ. В то время как вы могли бы, конечно, создать другие возможные исходные данные для ОГО хэша, если вы сломали хэш алго вам все равно нужно выполнить четыре вещи: 1) найти такой блок данных, который был в формате TX 2) порождает пару Публичной, соответствующую действующие ТЕ, который соответствует вашей хэш 3) убедитесь, что scriptSig был действителен в настоящее время не пустой бумажник 4) убедитесь, что ваш генерируется случайным образом ТХ согласуется с содержанием встроенного scriptSig Я вижу, что один может быть в состоянии, в теории, чтобы украсть произвольное количество Bitcoins из некоторых произвольного бумажника для некоторого астрономический небольшого количества хэш. Я готов держать пари, что, даже с полностью обратимой хэш-функцией пространства поиска для такого хэша больше, чем весь поиск места для всего блока цепи для следующего столетия.

18 мая 2011, 7:06:51 AM	# 12
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: WNS 18 мая 2011, 12:03:50 AM Цитата: Anisoptera от 17 мая 2011 года, 6:28:47 PM Вы делаете довольно много предположений о том, что это и не представляется возможным. Сценарий вы описываете один сценарий - один, где скомпрометированы блокируют только хэш и не ТЕ хэш. Если мы не можем убедительно доказать, что определенный сценарий катастрофы невозможно Я хотел бы видеть аргумент за нарушение ОГО, не нарушая паб-ключ. В то время как вы могли бы, конечно, создать другие возможные исходные данные для ОГО хэша, если вы сломали хэш алго вам все равно нужно выполнить четыре вещи: 1) найти такой блок данных, который был в формате TX 2) порождает пару Публичной, соответствующую действующие ТЕ, который соответствует вашей хэш 3) убедитесь, что scriptSig был действителен в настоящее время не пустой бумажник 4) убедитесь, что ваш генерируется случайным образом ТХ согласуется с содержанием встроенного scriptSig Я вижу, что один может быть в состоянии, в теории, чтобы украсть произвольное количество Bitcoins из некоторых произвольного бумажника для некоторого астрономический небольшого количества хэш. Я готов держать пари, что, даже с полностью обратимой хэш-функцией пространства поиска для такого хэша больше, чем весь поиск места для всего блока цепи для следующего столетия. Что делать, если разрыв таким образом, что я могу просто взять существующий ТХ, изменить его, чтобы пойти в мой адрес вместо этого, затем пэд его с тщательно отобранными мусора в местах, которые Bitcoin не заботится о (в scriptSig, может быть) и написать, что АЯ в блок? Если я могу сделать произвольный хэш данных для заданного значения, не должен генерировать новые ТМ - можно перенаправить старые.

18 мая 2011, 12:47:06 PM	# 13
WNS Сообщений: 39 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 18 мая 2011 года, 7:06:51 AM Что делать, если разрыв таким образом, что я могу просто взять существующий ТХ, изменить его, чтобы пойти в мой адрес вместо этого, затем пэд его с тщательно отобранными мусора в местах, которые Bitcoin не заботится о (в scriptSig, может быть) и написать, что АЯ в блок? Если я могу сделать произвольный хэш данных для заданного значения, не должен генерировать новые ТМ - можно перенаправить старые. ScriptSig содержит паб ключа подписи сделки, для того, чтобы генерировать правильный ТХ, вы должны быть в состоянии генерировать правильный паб ключа подписи для хэш сделки, что означает, что вы должны разорвать паб-ключ, чтобы сделать что для кошелька вы не контролируете. ломая паб-ключ ломается ВСЁ о Bitcoin, нет никакого плана на случай непредвиденных. Если кто-то не приходит в голову паб-ключ системы, которая работает на другой математической основе, чтобы не быть разбитой в то же время, игра окончена. Не будучи кандидатом на Филдса, я не в состоянии внести свой вклад в этот план на случай чрезвычайных ситуаций.

18 мая 2011, 7:56:58 PM	# 14
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: WNS 18 мая 2011, 12:47:06 PM Цитата: Anisoptera от 18 мая 2011 года, 7:06:51 AM Что делать, если разрыв таким образом, что я могу просто взять существующий ТХ, изменить его, чтобы пойти в мой адрес вместо этого, затем пэд его с тщательно отобранными мусора в местах, которые Bitcoin не заботится о (в scriptSig, может быть) и написать, что АЯ в блок? Если я могу сделать произвольный хэш данных для заданного значения, не должен генерировать новые ТМ - можно перенаправить старые. ScriptSig содержит паб ключа подписи сделки, для того, чтобы генерировать правильный ТХ, вы должны быть в состоянии генерировать правильный паб ключа подписи для хэш сделки, что означает, что вы должны разорвать паб-ключ, чтобы сделать что для кошелька вы не контролируете. ломая паб-ключ ломается ВСЁ о Bitcoin, нет никакого плана на случай непредвиденных. Если кто-то не приходит в голову паб-ключ системы, которая работает на другой математической основе, чтобы не быть разбитой в то же время, игра окончена. Не будучи кандидатом на Филдса, я не в состоянии внести свой вклад в этот план на случай чрезвычайных ситуаций. Мне не нужно, чтобы создать новую подпись. Моя модифицированная транзакция хэшей в том же значении, что и тот, который вы подписали. Я не нужен ключ. Уязвимость заключается в хэш-алгоритма, используемого для создания подписи; если я могу придумать с транзакцией, которая до сих пор "подписанный" вами, но посылает БТК где-то еще, я выиграю. В этом случае, однако, я думаю, что мы были бы в состоянии сказать различие между законным и ложной операцией. Законен ТЙ является тот, который не имеет обивку мусора в нем. Но это не обязательно является единственным способом это могло произойти.

18 мая 2011, 10:42:36 PM	# 15
WNS Сообщений: 39 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 18 мая 2011 года, 7:56:58 PM Мне не нужно, чтобы создать новую подпись. Моя модифицированная транзакция хэшей в том же значении, что и тот, который вы подписали. Я не нужен ключ. Уязвимость заключается в хэш-алгоритма, используемого для создания подписи; если я могу придумать с транзакцией, которая до сих пор "подписанный" вами, но посылает БТК где-то еще, я выиграю. В этом случае, однако, я думаю, что мы были бы в состоянии сказать различие между законным и ложной операцией. Законен ТЙ является тот, который не имеет обивку мусора в нем. Но это не обязательно является единственным способом это могло произойти. хорошо, теперь вы делаете ставку на площади два астрономический вряд ли хэш столкновений. Во-первых, что существует даже допустимый хэш столкновения для подписанного хэша, а затем, что это точно такая же хэш столкновения применяется к ТХ, как некоторое время. Даже если вы можете произвести обратные хэш в 0 раз, вы не можете вытащить хеш-коллизий из воздуха.

19 мая 2011, 5:47:32 AM	# 16
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: WNS 18 мая 2011, 10:42:36 PM Цитата: Anisoptera от 18 мая 2011 года, 7:56:58 PM Мне не нужно, чтобы создать новую подпись. Моя модифицированная транзакция хэшей в том же значении, что и тот, который вы подписали. Я не нужен ключ. Уязвимость заключается в хэш-алгоритма, используемого для создания подписи; если я могу придумать с транзакцией, которая до сих пор "подписанный" вами, но посылает БТК где-то еще, я выиграю. В этом случае, однако, я думаю, что мы были бы в состоянии сказать различие между законным и ложной операцией. Законен ТЙ является тот, который не имеет обивку мусора в нем. Но это не обязательно является единственным способом это могло произойти. хорошо, теперь вы делаете ставку на площади два астрономический вряд ли хэш столкновений. Во-первых, что существует даже допустимый хэш столкновения для подписанного хэша, а затем, что это точно такая же хэш столкновения применяется к ТХ, как некоторое время. Даже если вы можете произвести обратные хэш в 0 раз, вы не можете вытащить хеш-коллизий из воздуха. Ты уверен? Я имею в виду, хэши просто на самом деле, на самом деле сложные контрольные суммы, не так ли? Если есть 256 битых хэш кажется, что вы должны быть в состоянии изменить 256 бит в любом сообщении и получить какой-либо хэш вы хотите, если вы знали, что правильные места вертеть биты, или можете добавить дополнительные биты где-нибудь. Это, по крайней мере теоретически возможно сделать это, так как md5 было нечто подобное ...

20 мая 2011, 1:33:42 AM	# 17
WNS Сообщений: 39 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Anisoptera от 19 мая 2011 года, 5:47:32 AM Ты уверен? Я имею в виду, хэши просто на самом деле, на самом деле сложные контрольные суммы, не так ли? Если есть 256 битых хэш кажется, что вы должны быть в состоянии изменить 256 бит в любом сообщении и получить какой-либо хэш вы хотите, если вы знали, что правильные места вертеть биты, или можете добавить дополнительные биты где-нибудь. Это, по крайней мере теоретически возможно сделать это, так как md5 было нечто подобное ... если у вас есть 256 бит вы можете сделать все, что вы хотите с. Если вы можете определить даже 3-4 байта в ОМ блоке, который можно покрутить, не делая его недействительным или бесполезно, тогда я буду впечатлен, от моего чтения спецификации, что не должно быть возможно. Оказывается, что вы сравниваете число возможных состояний, скажем 1k данных, к числу состояний в хэш. Для неограниченных данных, то, очевидно, много хэша столкновения в 1k блока, но мы говорим не о всех возможных блоках 1k данных, только о тех, которые относятся также ТЕ. Большинство данных в ОМ не twittleable, потому что эфир статичного, или производный от остальной части данных, ни один из хэш или заголовков не twiddleable, но twiddleing всего остального требует также вертели хэш. Только данные, которые вы могли бы вертеть это только данные, которые вы не можете получить что-нибудь из рандомизации, адрес получателя.

20 мая 2011, 12:10:05 PM	# 18
Latregetic Сообщения: 9 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Было бы еще неплохо иметь спецификацию реализации на месте для алгоритма хеширования переключения. В идеале вы хотите, чтобы запустить систему хэш, который не имеет никаких известных уязвимостей, а также возможность легко и быстро переключаться с одного хэш-системы в другую. Это не займет много работы, чтобы полностью убить доверие людей в валюте, особенно тот, который полагается крипто вуду работать. Как и катастрофы на Фукусиме, все, что вам нужно сделать, это кричать достаточно громко, что X использует Y, и Y представляет собой (что угодно), поэтому Х (независимо) для того, чтобы большинство людей в это поверить. Способность идти "Вот дерьмо"Уведомить всех, и коллективно голосовать переключатель будет очень мощным средством для смягчения этого эффекта. Код протокола таким образом, чтобы: Если 26 из последних 40 блоков имеют «использовать новый хэш» переключен на да, то все к некондиционному шахтеру и официальному клиент будет игнорировать все блоки не используя новый хэш от блока 26 и далее. Клиенты могут читать оба типа блоков, и совершать операции в обоих типов блоков, так как это была отодвинута потенциально лет, прежде чем это было необходимо. И сразу же возникает обнаружено уязвимость, шахтеры могут решить для себя, как группа, должны ли они переход к новой, более жесткой системе хэша.

20 мая 2011, 5:23:51 PM	# 19
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: WNS от 20 мая 2011 года, 1:33:42 AM Цитата: Anisoptera от 19 мая 2011 года, 5:47:32 AM Ты уверен? Я имею в виду, хэши просто на самом деле, на самом деле сложные контрольные суммы, не так ли? Если есть 256 битых хэш кажется, что вы должны быть в состоянии изменить 256 бит в любом сообщении и получить какой-либо хэш вы хотите, если вы знали, что правильные места вертеть биты, или можете добавить дополнительные биты где-нибудь. Это, по крайней мере теоретически возможно сделать это, так как md5 было нечто подобное ... если у вас есть 256 бит вы можете сделать все, что вы хотите с. Если вы можете определить даже 3-4 байта в ОМ блоке, который можно покрутить, не делая его недействительным или бесполезно, тогда я буду впечатлен, от моего чтения спецификации, что не должно быть возможно. Оказывается, что вы сравниваете число возможных состояний, скажем 1k данных, к числу состояний в хэш. Для неограниченных данных, то, очевидно, много хэша столкновения в 1k блока, но мы говорим не о всех возможных блоках 1k данных, только о тех, которые относятся также ТЕ. Большинство данных в ОМ не twittleable, потому что эфир статичного, или производный от остальной части данных, ни один из хэш или заголовков не twiddleable, но twiddleing всего остального требует также вертели хэш. Только данные, которые вы могли бы вертеть это только данные, которые вы не можете получить что-нибудь из рандомизации, адрес получателя. Да, это то, что я изначально думал тоже. Но, может быть, вы должны прочитать больше о scriptSig. Кажется, вроде как все, что мне нужно сделать, это ремесло scriptPubKey, что в конечном итоге проверяющий к одному из моих адресов. Это не так ограничены, как только изменение адреса - я могу делать почти все, что я хочу до тех пор, как он хэши то же самое. Он не должен идти на действительный адрес Bitcoin, это просто необходимо, чтобы в конечном счете вернуться верно для некоторых входных сигналов, который получает предварённое к нему в новом ТХ. Это намного свободнее из ограничений. ScriptPubKey может быть произвольной длиной - более чем достаточно для 256 бит, которые могут быть добавлены к ОМУ. Если у меня есть контроль достаточно того, что я могу сделать что-то есть то, что хэш-я хочу, я могу изменить выходы туда, куда я хочу, потому что даже если я не могу ничего более интересного, чем сделать scriptSig всегда возвращают истинное (следующий человек, чтобы написать делать ТЙ с этим, как вход получает его), то я тоже могу написать совершенно новые ТЙ позже в blockchain, потребляющий, что выход и фактически отправляет на адрес, который у меня есть. Так как мы уже переписывания blockchain, я выиграю - теперь я могу переписать произвольный ПРД туда, куда я хочу, и переписать blockchain так, что те, ТЕ похоронены глубоко. Как я уже сказал, что это будет своего рода очевидно, какие ТМ были недопустимые в данном случае, так как они явно не будут использовать стандартные scriptSigs, но это не обязательно будет являться показателем железным навсегда.

20 мая 2011, 5:49:20 PM	# 20
Anisoptera Сообщений: 98 Цитировать по имени цитировать ответ	Re: Управление существенных изменений в Bitcoin - сеть QA. Цитата: Latregetic 20 мая 2011, 12:10:05 PM Было бы еще неплохо иметь спецификацию реализации на месте для алгоритма хеширования переключения. В идеале вы хотите, чтобы запустить систему хэш, который не имеет никаких известных уязвимостей, а также возможность легко и быстро переключаться с одного хэш-системы в другую. Это не займет много работы, чтобы полностью убить доверие людей в валюте, особенно тот, который полагается крипто вуду работать. Как и катастрофы на Фукусиме, все, что вам нужно сделать, это кричать достаточно громко, что X использует Y, и Y представляет собой (что угодно), поэтому Х (независимо) для того, чтобы большинство людей в это поверить. Способность идти "Вот дерьмо"Уведомить всех, и коллективно голосовать переключатель будет очень мощным средством для смягчения этого эффекта. Код протокола таким образом, чтобы: Если 26 из последних 40 блоков имеют «использовать новый хэш» переключен на да, то все к некондиционному шахтеру и официальному клиент будет игнорировать все блоки не используя новый хэш от блока 26 и далее. Клиенты могут читать оба типа блоков, и совершать операции в обоих типов блоков, так как это была отодвинута потенциально лет, прежде чем это было необходимо. И сразу же возникает обнаружено уязвимость, шахтеры могут решить для себя, как группа, должны ли они переход к новой, более жесткой системе хэша. Да, это то, что я хочу. Путь для всей сети, чтобы коллективно вызвать такое переключение без спроса, что все обновления своего клиента, и, безусловно, не в сети, или невозможности того, чтобы откатить законные сделки. И тогда обширное тестирование этого процесса на испытательной цепи во всех сценариях, которые мы ожидаем, чтобы использовать данный метод переключения. Мы должны стремиться к этому, чтобы быть конечной целью любого плана мы делаем. В некоторых случаях это просто не представляется возможным для достижения этой цели, но мы должны взывать эти сценарии и определить, что лучшее, что мы можем сделать, это. Откат транзакции имеет приблизительно 99,9% шанс убить Bitcoin. Это время вниз в течение продолжительного периода времени, менее вероятно, чтобы убить его, но все же весьма вероятно, в зависимости от продолжительности ППР и эффектов. Мы бежим финансовую сеть здесь. Если что-нибудь, как это происходит, и люди теряют деньги из-за этого, мы сделанный. И люди не будучи в состоянии принять сделки в течение длительного времени будет считаться "потерять деньги",

Заголовок