Вывод BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч

К сожалению, с приходом Deepbit добавления BIP 16 поддержка, возможность BIP 17 реализуется в значительной степени ушла. Поэтому я с сожалением объявить официальный Withdrawl из BIP 17. Если кто-то хочет взять на себя, как его "чемпион", не стесняйтесь, чтобы повторно открыть его, но я убежден, что это безнадежное дело в этой точке. Короткое чего-то крупное случаться в течение следующего дня или два, я буду переключение Элигий (мой бассейн) к BIP 16, и слияние портированного BIP 16 поддержка в будущее 0.4.5 и 0.5.4 стабильных релизов.

Однако, BIP 16 не совсем непоправимое: Я предлагаю BIP 18 в качестве следующего шага вперед. Это предложение 100% протокол совместим с BIP 16 и не требует никаких изменений в программное обеспечение на всех. Это просто формальное переписывание спецификации в более последовательным образом, и подразумевает разработчики сделают полную приверженность P2SH, используя его для всех новых типов адресов / транзакций (без нарушения совместимости с "наследие" адреса).

В заключение, Гэвина BIP 16 портировать не сливается чисто в 0.4.x / 0.5.x, и, кажется, отстали на несколько исправлений, сделанных в "мастер" филиал. Я попытался решить эту проблему, но был бы признателен, как много отзывов о нем, как это возможно, до слияния в стабильный. В отличии от BIP 17, код для реализации БИП 16 является очень сложным и трудно следовать, так что есть много места для ошибок.

Edit: Гэвин отметил портировать не нужно на самом деле мое P2SH в блоки, так здесь является более простым патчем, который проверяет только их. Пожалуйста, аудит вместо этого один.

Я только что несколько минут, чтобы пропустить BIP 18, но мне это нравится до сих пор. Есть ли какие-либо причины, мы не хотят обесценить систему scriptPubKey / scriptSig? Другими словами, есть ли случай использования зная фактический сценарий раньше времени?

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

Цитата: theymos 14 марта 2012, 12:14:28 AM

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

Согласен.

Цитата: theymos 14 марта 2012, 12:14:28 AM

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

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

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

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

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

Устаревшие не устаревание; и, кажется, идеальное слово для этого мне.

Код:

Из WordNet (г) 3,0 (2006) [Wn]:

  протестовать
      v 1: выражать сильное неодобрение; оплакивать
      2: умаляет; "Учитель не должен осуждать его студента
         усилия" [Син: {принизить}, {амортизировать}, {} пренебрежительно отзываться]

1 является очевидным определением здесь.

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

Я согласен с Theymos и Гэвин. Хотя я согласен с доводами за BIP 18, так как старая система сценариев не может быть устаревшим, это не делает решение чище. например почему hashScriptCheck будет содержать операционные коды, если это не сценарий.

Кроме того, я не вижу преимущество в принятии всех платежей в scriptHash, необходимо сохранить скрипт добавляет дополнительную сложность.

Цитата: theymos 14 марта 2012, 12:14:28 AM

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

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

Цитата: Магид от 14 марта 2012 года, 5:02:45 PM

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

Это даже не требует жесткой вилки, на самом деле.

Цитата: Магид от 14 марта 2012 года, 5:02:45 PM

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

Унаследованные выходы могут быть безопасно преобразованы в P2SH в таком hardfork.

Цитата: piuk от 14 марта 2012 года, 3:34:19 PM

Кроме того, я не вижу преимущество в принятии всех платежей в scriptHash, необходимо сохранить скрипт добавляет дополнительную сложность.

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

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

Это то что эта нить было около. Гэвин был рассмотрен вопрос для мульти-сига и эскроу.

Цитата: etotheipi от 14 марта 2012 года, 5:41:18 PM

Цитата: piuk от 14 марта 2012 года, 3:34:19 PM

Я не понимаю, почему это тяжелее делать с P2SH ...

Есть некоторые возможные сценарии, свойства которых зависеть на время общественности. Дэвид Шварц описывает одну Вот что обеспечивает анонимные пожертвования / переводы, хотя это требует новых опкодов для системы сценариев.

Такая система не была бы возможна при P2SH.

Цитата: Luke-Jr 14 марта 2012 года, 5:05:38 PM

Цитата: Магид от 14 марта 2012 года, 5:02:45 PM

Это даже не требует жесткой вилки, на самом деле.

Баа, вы правы. Это может быть обратной совместимостью изменения протокола.

Цитата: Luke-Jr 14 марта 2012 года, 5:05:38 PM

Цитата: Магид от 14 марта 2012 года, 5:02:45 PM

Унаследованные выходы могут быть безопасно преобразованы в P2SH в таком hardfork.

Протокол-накрест, это правда. Если мы полностью заменить scriptPubKey с scriptHash в протоколе (который, как я предлагаю это делать), мы можем преобразовать все унаследованные скрипты P2SH.

Практически, кто бы сохранить старые данные сценария вокруг, но я полагаю, обдумывая, клиент Satoshi уже спасает, что в кошельке, в любом случае. Так что да, прямая конверсия бы Работа.

etotheipi то, что резервный случай не рассматривается?

Цитата: maaku от 14 марта 2012 года, 7:16:19 PM

Сценарий может быть публичной и не является частью сделки.

Дать сценарий где-то общественность и у вас есть общедоступная копия сценария.
Более Elegent решение было бы облако на основе хранилища скриптов.
Раствор p2p бы DHT, что пользователи могут отправлять сценарии и сценарии для запросов на основе их хэш.

Цитата: Магид от 14 марта 2012 года, 7:23:06 PM

К сожалению, я не понял утверждение, что "все операции должны быть P2SH скриптов." Вот что я получаю за бросаясь через описание ...

Меня беспокоит то, что переход от ванильного OP_CHECKMULTISIG к P2SH означает, что она больше не возможно, чтобы просто сделать одну резервную копию [детерминированного] бумажник. Вы должны постоянно резервного копирования скриптов и сценариев-хэши после каждой транзакции мульти-сиг. Но есть хорошая причина для использования P2SH, я чувствую, что это лучшее из двух зол. Но я по-прежнему жалуются на дополнительной резервной сложности, связанные с ним - скрипты для резервного копирования не чувствительны к регистру, но важно, и многие пользователи могут не захотеть установки autobackups всего своего бумажника, зашифрованную или нет. Таким образом, это потребует сохранения скриптов в отдельных файлах и поддержание отдельной системы резервного копирования для него, и должно быть выполнено после каждой транзакции. И мне нужно, чтобы построить в системе для восстановления всего бумажника из секретного ключа только для файла плюс скрипт резервного копирования-файл. И выяснить, как восстановить как можно больше информации, насколько это возможно в случае, если скрипт резервного копирования-файл не может быть восстановлен. Опять же, это то, что что другой поток для.

Когда я слышал "все ТХ использовать P2SH" Я сразу начал думать, что все операции собирались постигнут резервное копирование сложности. Но предложение действительно больше об изменении формата стандартных скриптов, так что вы будем по-прежнему иметь возможность сканировать blockchain для регулярных сделок - они просто будут иметь различную форму. Я больше думал, как предложения, где даже регулярная ОЕ "затемненный", Требуя, чтобы сохранить некоторую важную информацию в дополнении к приватным ключам для того, чтобы идентифицировать и выкупить его.

Просто для информации:

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

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

Для данного открытого ключа всегда будет хэш сценария (или эквивалент):

Код:

OP_PUSH <подпись>
OP_CODESEPARATOR
OP_PUSH <открытый ключ>
OP_CHECKSIGVERIFY

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

Люк, мне нравится ваше предложение, по первому прочитанный. Это выглядит как элегантный и эффективное решение драмы BIP16 / 17 ранее мы имели.

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

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

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

Требуется ли существующий язык сценариев строгой сортировки адресов заранее, чтобы предотвратить нападение выше? Имеет ли существующий язык Disallow вставки NO-OP опкоды увеличить число скриптов вы можете попытаться столкнуться с? Возможно, я просто не хватает что-то и язык сценариев гораздо менее выразительным, чем кажется, но это выглядело как в нем содержится стек, а также не-оп, а также возможность включения "пользователем данные" (А Bitcoin адрес). Что-то, что позволяет вставить другой сценарий хэшей в скрипт делает экспоненциально более опасным. Я надеюсь, что я полностью покинуть базу здесь, но я не видел это имя в любом месте.

Цитата: Tril от 16 марта 2012 года, 3:34:35 PM

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

13 марта 2012, 11:31:39 PM	# 1
Luke-Jr Сообщения: 2282 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru К сожалению, с приходом Deepbit добавления BIP 16 поддержка, возможность BIP 17 реализуется в значительной степени ушла. Поэтому я с сожалением объявить официальный Withdrawl из BIP 17. Если кто-то хочет взять на себя, как его "чемпион", не стесняйтесь, чтобы повторно открыть его, но я убежден, что это безнадежное дело в этой точке. Короткое чего-то крупное случаться в течение следующего дня или два, я буду переключение Элигий (мой бассейн) к BIP 16, и слияние портированного BIP 16 поддержка в будущее 0.4.5 и 0.5.4 стабильных релизов. Однако, BIP 16 не совсем непоправимое: Я предлагаю BIP 18 в качестве следующего шага вперед. Это предложение 100% протокол совместим с BIP 16 и не требует никаких изменений в программное обеспечение на всех. Это просто формальное переписывание спецификации в более последовательным образом, и подразумевает разработчики сделают полную приверженность P2SH, используя его для всех новых типов адресов / транзакций (без нарушения совместимости с "наследие" адреса). В заключение, Гэвина BIP 16 портировать не сливается чисто в 0.4.x / 0.5.x, и, кажется, отстали на несколько исправлений, сделанных в "мастер" филиал. Я попытался решить эту проблему, но был бы признателен, как много отзывов о нем, как это возможно, до слияния в стабильный. В отличии от BIP 17, код для реализации БИП 16 является очень сложным и трудно следовать, так что есть много места для ошибок. Edit: Гэвин отметил портировать не нужно на самом деле мое P2SH в блоки, так здесь является более простым патчем, который проверяет только их. Пожалуйста, аудит вместо этого один.

14 марта 2012, 12:08:09 AM	# 2
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Получил 1806 Биткоинов Реальная история. Я только что несколько минут, чтобы пропустить BIP 18, но мне это нравится до сих пор. Есть ли какие-либо причины, мы не хотят обесценить систему scriptPubKey / scriptSig? Другими словами, есть ли случай использования зная фактический сценарий раньше времени?

14 марта 2012, 12:14:28 AM	# 3
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Я не вижу смысла в "официально" обесценивается то, что должно поддерживаться вечно в любом случае.

14 марта 2012, 2:55:14 AM	# 4
finway Сообщения: 714 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Хорошо!

14 марта 2012, 12:19:38 PM	# 5
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: theymos 14 марта 2012, 12:14:28 AM Я не вижу смысла в "официально" обесценивается то, что должно поддерживаться вечно в любом случае. Согласен.

14 марта 2012, 1:36:37 PM	# 6
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: theymos 14 марта 2012, 12:14:28 AM Я не вижу смысла в "официально" обесценивается то, что должно поддерживаться вечно в любом случае. Причина официального устаревания так что разработчики знают, что будущее усовершенствования вряд ли будет разработано для устаревшей части системы. Это держит активно развитую часть программного обеспечения как можно меньше. Это уменьшает риск ошибок и дыр в безопасности, которые введены в будущем, и делает кодирование и тестирование проще. Если старый способ делать вещи полностью включен в категории нового и лучшим способом, старый способ, безусловно, должен быть устаревшим.

14 марта 2012, 3:05:55 PM	# 7
realnowhereman Сообщения: 504 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Я полагаю, что мы на самом деле говорим о "неодобрение" не "амортизация" ("амортизация" будучи довольно бессмысленно в данном контексте) ... Устаревшие не устаревание; и, кажется, идеальное слово для этого мне. Код: Из WordNet (г) 3,0 (2006) [Wn]: протестовать v 1: выражать сильное неодобрение; оплакивать 2: умаляет; "Учитель не должен осуждать его студента усилия" [Син: {принизить}, {амортизировать}, {} пренебрежительно отзываться] 1 является очевидным определением здесь. "протестовать" используется повсеместно в программном обеспечении. Это означает, что функция, которые используют не рекомендуется. Отлично.

14 марта 2012, 3:34:19 PM	# 8
piuk Сообщения: 910 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Я согласен с Theymos и Гэвин. Хотя я согласен с доводами за BIP 18, так как старая система сценариев не может быть устаревшим, это не делает решение чище. например почему hashScriptCheck будет содержать операционные коды, если это не сценарий. Кроме того, я не вижу преимущество в принятии всех платежей в scriptHash, необходимо сохранить скрипт добавляет дополнительную сложность.

14 марта 2012, 5:02:45 PM	# 9
Магид Сообщения: 1260 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: theymos 14 марта 2012, 12:14:28 AM Я не вижу смысла в "официально" обесценивается то, что должно поддерживаться вечно в любом случае. Я делаю. Официально протестующий его, это может означать, что мы удалим возможность сделать новые унаследованные сделки в будущем жестком вилке. В конце концов, другая жесткая вилка может удалить его полностью, уничтожая любые еще неизрасходованные унаследованные выходы.

14 марта 2012, 5:05:38 PM	# 10
Luke-Jr Сообщения: 2282 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: Магид от 14 марта 2012 года, 5:02:45 PM Официально протестующий его, это может означать, что мы удалим возможность сделать новые унаследованные сделки в будущем жестком вилке. Это даже не требует жесткой вилки, на самом деле. Цитата: Магид от 14 марта 2012 года, 5:02:45 PM В конце концов, другая жесткая вилка может удалить его полностью, уничтожая любые еще неизрасходованные унаследованные выходы. Унаследованные выходы могут быть безопасно преобразованы в P2SH в таком hardfork.

14 марта 2012, 5:41:18 PM	# 11
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: piuk от 14 марта 2012 года, 3:34:19 PM Кроме того, я не вижу преимущество в принятии всех платежей в scriptHash, необходимо сохранить скрипт добавляет дополнительную сложность. ^ Это. Хотя я вижу значение в P2SH или любую подобную систему, я глубоко обеспокоен вопросами резервного копирования. Я положил в много работы, чтобы сделать бумажные копии в Оружейную, чтобы сделать его как можно более простым для пользователей, чтобы сделать одну резервную копию когда-либо, и не должны волноваться об этом. "Обычные пользователи" кто должен полагаться на последовательное решение для резервного копирования не удастся. Это не происходит. Независимо от того, что вы делаете, они не забудьте установить его, не реализовать свой резервный диск был отключен, а не установить его снова после восстановления системы или переустановки операционной системы и т.д. Но предложения, которые требуют все, чтобы все были скрыты за сценарием хэш: ваш кошелек должен быть резервным копированием (или, по крайней мере, информация скрипта) после каждой транзакции. Ваша система умирает сразу после сделки, прежде чем вы имели возможность сохранить сценарий, и вы никогда не будете восстановить его снова. Это то, что я боролся с несколькими сиг сценариев, но утешался тем, что по крайней мере, обычные пользователи, которые хотят, чтобы избежать всего этого не приходится иметь дело с ним, и можно использовать обычные адреса, которые могут быть отсканированы для в blockchain. Это то что эта нить было около. Гэвин был рассмотрен вопрос для мульти-сига и эскроу.

14 марта 2012, 5:46:45 PM	# 12
Luke-Jr Сообщения: 2282 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: etotheipi от 14 марта 2012 года, 5:41:18 PM Цитата: piuk от 14 марта 2012 года, 3:34:19 PM Кроме того, я не вижу преимущество в принятии всех платежей в scriptHash, необходимо сохранить скрипт добавляет дополнительную сложность. ^ Это. Хотя я вижу значение в P2SH или любую подобную систему, я глубоко обеспокоен вопросами резервного копирования. Я положил в много работы, чтобы сделать бумажные копии в Оружейную, чтобы сделать его как можно более простым для пользователей, чтобы сделать одну резервную копию когда-либо, и не должны волноваться об этом. "Обычные пользователи" кто должен полагаться на последовательное решение для резервного копирования не удастся. Это не происходит. Независимо от того, что вы делаете, они не забудьте установить его, не реализовать свой резервный диск был отключен, а не установить его снова после восстановления системы или переустановки операционной системы и т.д. Но предложения, которые требуют все, чтобы все были скрыты за сценарием хэш: ваш кошелек должен быть резервным копированием (или, по крайней мере, информация скрипта) после каждой транзакции. Ваша система умирает сразу после сделки, прежде чем вы имели возможность сохранить сценарий, и вы никогда не будете восстановить его снова. Это то, что я боролся с несколькими сиг сценариев, но утешался тем, что по крайней мере, обычные пользователи, которые хотят, чтобы избежать всего этого не приходится иметь дело с ним, и можно использовать обычные адреса, которые могут быть отсканированы для в blockchain. Это то что эта нить было около. Гэвин был рассмотрен вопрос для мульти-сига и эскроу. Я не понимаю, почему это тяжелее делать с P2SH ...

14 марта 2012, 7:16:19 PM	# 13
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Есть некоторые возможные сценарии, свойства которых зависеть на время общественности. Дэвид Шварц описывает одну Вот что обеспечивает анонимные пожертвования / переводы, хотя это требует новых опкодов для системы сценариев. Такая система не была бы возможна при P2SH.

14 марта 2012, 7:23:06 PM	# 14
Магид Сообщения: 1260 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: Luke-Jr 14 марта 2012 года, 5:05:38 PM Цитата: Магид от 14 марта 2012 года, 5:02:45 PM Официально протестующий его, это может означать, что мы удалим возможность сделать новые унаследованные сделки в будущем жестком вилке. Это даже не требует жесткой вилки, на самом деле. Баа, вы правы. Это может быть обратной совместимостью изменения протокола. Цитата: Luke-Jr 14 марта 2012 года, 5:05:38 PM Цитата: Магид от 14 марта 2012 года, 5:02:45 PM В конце концов, другая жесткая вилка может удалить его полностью, уничтожая любые еще неизрасходованные унаследованные выходы. Унаследованные выходы могут быть безопасно преобразованы в P2SH в таком hardfork. Протокол-накрест, это правда. Если мы полностью заменить scriptPubKey с scriptHash в протоколе (который, как я предлагаю это делать), мы можем преобразовать все унаследованные скрипты P2SH. Практически, кто бы сохранить старые данные сценария вокруг, но я полагаю, обдумывая, клиент Satoshi уже спасает, что в кошельке, в любом случае. Так что да, прямая конверсия бы Работа. etotheipi то, что резервный случай не рассматривается?

14 марта 2012, 7:31:36 PM	# 15
DeathAndTaxes Сообщения: 1218 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: maaku от 14 марта 2012 года, 7:16:19 PM Есть некоторые возможные сценарии, свойства которых зависеть на время общественности. Дэвид Шварц описывает одну Вот что обеспечивает анонимные пожертвования / переводы, хотя это требует новых опкодов для системы сценариев. Такая система не была бы возможна при P2SH. Сценарий может быть публичной и не является частью сделки. Дать сценарий где-то общественность и у вас есть общедоступная копия сценария. Более Elegent решение было бы облако на основе хранилища скриптов. Раствор p2p бы DHT, что пользователи могут отправлять сценарии и сценарии для запросов на основе их хэш.

14 марта 2012, 8:57:13 PM	# 16
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: Магид от 14 марта 2012 года, 7:23:06 PM Протокол-накрест, это правда. Если мы полностью заменить scriptPubKey с scriptHash в протоколе (который, как я предлагаю это делать), мы можем преобразовать все унаследованные скрипты P2SH. Практически, кто бы сохранить старые данные сценария вокруг, но я полагаю, обдумывая, клиент Satoshi уже спасает, что в кошельке, в любом случае. Так что да, прямая конверсия бы Работа. etotheipi то, что резервный случай не рассматривается? К сожалению, я не понял утверждение, что "все операции должны быть P2SH скриптов." Вот что я получаю за бросаясь через описание ... Меня беспокоит то, что переход от ванильного OP_CHECKMULTISIG к P2SH означает, что она больше не возможно, чтобы просто сделать одну резервную копию [детерминированного] бумажник. Вы должны постоянно резервного копирования скриптов и сценариев-хэши после каждой транзакции мульти-сиг. Но есть хорошая причина для использования P2SH, я чувствую, что это лучшее из двух зол. Но я по-прежнему жалуются на дополнительной резервной сложности, связанные с ним - скрипты для резервного копирования не чувствительны к регистру, но важно, и многие пользователи могут не захотеть установки autobackups всего своего бумажника, зашифрованную или нет. Таким образом, это потребует сохранения скриптов в отдельных файлах и поддержание отдельной системы резервного копирования для него, и должно быть выполнено после каждой транзакции. И мне нужно, чтобы построить в системе для восстановления всего бумажника из секретного ключа только для файла плюс скрипт резервного копирования-файл. И выяснить, как восстановить как можно больше информации, насколько это возможно в случае, если скрипт резервного копирования-файл не может быть восстановлен. Опять же, это то, что что другой поток для. Когда я слышал "все ТХ использовать P2SH" Я сразу начал думать, что все операции собирались постигнут резервное копирование сложности. Но предложение действительно больше об изменении формата стандартных скриптов, так что вы будем по-прежнему иметь возможность сканировать blockchain для регулярных сделок - они просто будут иметь различную форму. Я больше думал, как предложения, где даже регулярная ОЕ "затемненный", Требуя, чтобы сохранить некоторую важную информацию в дополнении к приватным ключам для того, чтобы идентифицировать и выкупить его.

15 марта 2012, 10:06:28 AM	# 17
realnowhereman Сообщения: 504 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Просто для информации: Существует отображение из текущего Bitcoin открытого ключа, чтобы p2sh получать адрес; так же, как есть отображение из открытого ключа, не p2sh адреса. Там нет необходимости держать скрипты вокруг на диске, ни на самом деле беспокоиться о всех ваших адресов меняется. Обе эти вещи могут быть обработаны с немного умным программным обеспечением и доступ к открытому ключу (который доступен в текущей scriptPubKey стандартных скриптов). Может быть, я неправильно понимает проблемы Магид, но нет необходимости беспокоиться, что один детерминированный резервного копирования недостаточно. Государственные и частные ключи остаются неизменными. Какие изменения это путь открытый ключ преобразуется в адрес. Для данного открытого ключа всегда будет хэш сценария (или эквивалент): Код: OP_PUSH <подпись> OP_CODESEPARATOR OP_PUSH <открытый ключ> OP_CHECKSIGVERIFY Обратите внимание, что поскольку <подпись> байты не будут (не может) быть включены в хэше этого сценария, нет его части, которая меняется с различными сделками; так что это всегда тот же хэш и поэтому всегда тот же принимающий адрес.

16 марта 2012, 2:55:01 AM	# 18
da2ce7 Сообщения: 1222 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Люк, мне нравится ваше предложение, по первому прочитанный. Это выглядит как элегантный и эффективное решение драмы BIP16 / 17 ранее мы имели.

16 марта 2012, 3:34:35 PM	# 19
Tril Сообщения: 213 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Привет, пожалуйста, медведь со мной, я не успел изучить протокол кода и Bitcoin и понять, как работают скрипты в глубину, но как пользователь Bitcoin и шахтером, я задавался вопросом, так как BIP16 и 17 были введены: Почему BIP16 НЕ значительно увеличивает возможности для предварительного вычисления хэш столкновения? Если мы не высылаем скрипты больше, но хэши скриптов, то более выразительным скриптовый язык, тем больше существует способов, чтобы попытаться сделать скрипт, который хэшей нечто известное: сканировать blockchain для неизрасходованных операций и попытаться прийти с согласующим хэш, который платит нападающему. Даже с чем-то же просто, как платить многократный скрипт Bitcoin адреса, вы можете заранее создать миллиард Bitcoin адресов, а затем найти комбинацию и систематизацию сценария платить те адреса, чьи хэш сталкивается с другим сценарием. Чем больше опкодов и тем дольше вы позволяете сценарий, тем более опасным это становится. Если новые опкоды когда-либо добавлены, мы можем гарантировать эти ограничения, предотвращающие новые опкоды от работы над сценариями, полученных до того были добавлены опкоды, чтобы не допустить ретро-активные добавки к языку сценариев для предотвращения брут столкновений для старых адресов? Требуется ли существующий язык сценариев строгой сортировки адресов заранее, чтобы предотвратить нападение выше? Имеет ли существующий язык Disallow вставки NO-OP опкоды увеличить число скриптов вы можете попытаться столкнуться с? Возможно, я просто не хватает что-то и язык сценариев гораздо менее выразительным, чем кажется, но это выглядело как в нем содержится стек, а также не-оп, а также возможность включения "пользователем данные" (А Bitcoin адрес). Что-то, что позволяет вставить другой сценарий хэшей в скрипт делает экспоненциально более опасным. Я надеюсь, что я полностью покинуть базу здесь, но я не видел это имя в любом месте.

16 марта 2012, 3:45:28 PM	# 20
jojkaart Сообщений: 97 Цитировать по имени цитировать ответ	Re: Снятие BIP 17, и предложение BIP 18; пожалуйста, просмотрите патч Цитата: Tril от 16 марта 2012 года, 3:34:35 PM Привет, пожалуйста, медведь со мной, я не успел изучить протокол кода и Bitcoin и понять, как работают скрипты в глубину, но как пользователь Bitcoin и шахтером, я задавался вопросом, так как BIP16 и 17 были введены: Почему BIP16 НЕ значительно увеличивает возможности для предварительного вычисления хэш столкновения? Если мы не высылаем скрипты больше, но хэши скриптов, то более выразительным скриптовый язык, тем больше существует способов, чтобы попытаться сделать скрипт, который хэшей нечто известное: сканировать blockchain для неизрасходованных операций и попытаться прийти с согласующим хэш, который платит нападающему. Даже с чем-то же просто, как платить многократный скрипт Bitcoin адреса, вы можете заранее создать миллиард Bitcoin адресов, а затем найти комбинацию и систематизацию сценария платить те адреса, чьи хэш сталкивается с другим сценарием. Чем больше опкодов и тем дольше вы позволяете сценарий, тем более опасным это становится. Если новые опкоды когда-либо добавлены, мы можем гарантировать эти ограничения, предотвращающие новые опкоды от работы над сценариями, полученных до того были добавлены опкоды, чтобы не допустить ретро-активные добавки к языку сценариев для предотвращения брут столкновений для старых адресов? Требуется ли существующий язык сценариев строгой сортировки адресов заранее, чтобы предотвратить нападение выше? Имеет ли существующий язык Disallow вставки NO-OP опкоды увеличить число скриптов вы можете попытаться столкнуться с? Возможно, я просто не хватает что-то и язык сценариев гораздо менее выразительным, чем кажется, но это выглядело как в нем содержится стек, а также не-оп, а также возможность включения "пользователем данные" (А Bitcoin адрес). Что-то, что позволяет вставить другой сценарий хэшей в скрипт делает экспоненциально более опасным. Я надеюсь, что я полностью покинуть базу здесь, но я не видел это имя в любом месте. Во-первых, я должен отметить, что я не эксперт по этому вопросу. Тем не менее, я думаю, вы правы в том, что количество вариантов, чтобы попробовать, если вы хотите, чтобы попытаться создать хэш-коллизии увеличиваются. Это, однако, не делает большой разницы, если таковые имеются, от ожидаемого времени, чтобы найти столкновение. Это происходит потому, что количество вариантов, еще до BIP 16, является значительно больше, чем среднее число попыток, необходимых для поиска столкновения. Таким образом, простое увеличение параметра пространство не делает большой разницы.

Заголовок