Предложение: стандартные операции по безопасности / резервное копирование / эскроу

Воскресенье на Bitcoin конференции я вел небольшую сессию мозговой атаки по расширению набора «стандартных» типов транзакций, и я собирание мозгов людей с помощью электронной почты и IRC-чата (и тянуть запрос комментарии), чтобы работать через деталь.

Моя мотивация для желающих сделать это сейчас, потому что это позволит такие функции, как:

+ подтверждение Multi-устройство тратит, поэтому, если ваш компьютер заражен трояном он не может потратить все свои монеты.

+ Мастер-ключ аварийного резервного копирования, так что если вы потеряете свой кошелек (и все его резервные копии) вы можете получить мастер-ключ от Вашего сейфа и восстановить все ваши монеты

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

Разработка общего способа сделать (например) 1-из-2-клавиши-необходимые операции будут делать это намного проще для сайтов, как blockexplorer, чтобы отобразить их с умом, и, как правило, сделать жизнь счастливее для кого писать инструменты, которые смотрят на blockchain ,

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

Текущий проект предложения здесь:
https://gist.github.com/39158239e36f6af69d6f

Простите, коверкая кавычки системы несколько ...

Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM

(А и б) или
--------------
Это полезная форма для безопасных, резервируемых кошельков.
(А) бы частные ключи хранятся на возможно небезопасным устройстве. (Б) будет
ключ счета хранится на каком-то типа «службы защиты кошелька». И (с)
будет аварийный ключ хранится в автономном режиме, который может быть использован в
случае (а) или (б) ключи утеряны.

Код:

ScriptSig: сига pubkeya SIGB pubkeyb 0
  ИЛИ
ScriptSig: sigc pubkeyc 1

ScriptPubKey:
  ЕСЛИ
   DUP HASH160 {hashc} EQUALVERIFY CHECKSIG
  ELSE
   DUP HASH160 {hashb} EQUALVERIFY CHECKSIGVERIFY
   DUP HASH160 {Hasha} EQUALVERIFY CHECKSIG
  ENDIF

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

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

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

ByteCoin

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

С помощью дополнительного устройства:

Код:

2 Keya KEYB 2 OP_CHECKMULTISIG

KEYA является локальным ключом известен Bitcoin. KEYB вероятно запомнила предыдущего использования; если нет, то он может быть передан в QR код без особых проблем (~ 90 base64 символы отлично).

С резервного копирования:

Код:

1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG

KeyBackup статична, запоминаются Bitcoin. KeyNormal является локальным ключом.

Цитата: theymos 23 августа 2011, 11:50:24 PM

Код:

2 Keya KEYB 2 OP_CHECKMULTISIG

Мульти-устройства прецедентов я себе:

Я подписываю с Solutions Acme Bitcoin Security, Inc. Они дают мне открытый ключ WalletProtection (или Bitcoin адрес, не имеет значения) и уникальный-для-меня URL. Я положил адрес / Публичный в мой Bitcoin клиент, "Второй фактор вне устройства Отправить Authentication." Или что-то.
(Abbs также посылает мне секретный ключ по почте и говорит мне, чтобы держать его в безопасности в случае, если они выходят из бизнеса)

Теперь я хочу, чтобы все монеты, отправленные мне требовать подписи от ключей в моем бумажнике И ключ Abbs потратить.

Что Bitcoin адрес я даю людям, так что все монеты, поступающие в мой бумажник имеют это свойство?

Если это сырье CHECKMULTISIG, то мне нужно выдавать адреса, содержащие 2 полных открытых ключей. Какой бы 186 символов в base58 и выглядеть примерно так:
LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3

Использование 20-байтовые хэшей и более сложный 2-на-2 сделки я предлагаю, адрес является более разумным 61 символов:
2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK

Цитата: ByteCoin 23 августа 2011, 10:42:08 PM

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

То же самое можно было бы сделать для ключа Ь «Служба защиты бумажника» - каждый раз, когда вы используете б, обратитесь в службу защиты и попросить Ь»полученных детерминировано из б. Тогда Ь ', Ь «»», и т.д. ...

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

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

Gavin,

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

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

Создание нового формата адрес - особенно больше один - собираются добавить к умственной нагрузке каждому будущего пользователя Bitcoin, и собираются заставить все модернизировать все равно так или иначе. Каждый пользователь пустобреха теперь будет спросить, почему любой другой пользователь дает два Bitcoin адреса, один, чтобы остаться совместимыми и один, чтобы оставаться в безопасности. Он также будет нарушать процедуру вывода каждого сайта, который раздает Bitcoins (или вновь заставить людей поддерживать две разновидности адресов). В какой-то момент, замена клиента будет неизбежно необходимо даже без изменений, так как количество времени, которое требуется для первоначального заполнения и подтверждения blockchain уже растет в геометрической прогрессии, а прошлое неудобно, и к точке стать монументальным и неосуществимым вроде как добыча процессора.

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

котировка

Я думаю, что это произвольное различие. Люди сами должны будут общаться со своими клиентами, чтобы выполнить 1-из-2, 2-из-2, и т.д., сделки. Обеспечение стандарта "код" для них позволит пользователям знать, что они делают. Если я говорю своей жене, чтобы положить деньги в нашем 1-из-2 или 2-из-2 счетов, я даю ей длинный код. Если я продаю вещи в Интернете, я использую свое предложение (дать покупателю рег адрес, переместить его сам). Ключ для создания языка. Люди будут использовать его как они считают целесообразным.

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

Нажмите здесь для полноразмерного изображения: http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogs.png

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

Просто для сравнения: вот что пользовательский опыт будет, если модифицированное предложение OP_CHECKSIG были приняты.

Jimbob, который просто средний парень с помощью службы защиты кошелька, будет выдавать нормальный вид хорошо сформированный Bitcoin адреса для Салли и будет принимать платежи только как нормальные.

Jimbob использует версию клиента Bitcoin, который знает, что его средства обременены пары ключей А, В (не говоря уже о С в настоящее время), и что он только обладает персональным ключом для А. Она знает, что закрытый ключ B управляется третья сторона через веб-сервис.

Когда он идет тратить свои средства, его клиент подписывает сделку с ключом, и корабли незавершенной транзакции прочь к веб-сервис для проверки. Веб-сервис делает его должной осмотрительности, например, эта конкретная услуга посылает SMS на мобильный телефон JimBob, в "Вы отправляете 57.00 BTC в 1xyzabcdABCD123 ... Ответить 1, если OK",

JimBob ответы 1, и WebService знаки с B и направляет его на операцию к сети.

Безопасный для JimBob? Вы делаете ставку.

Легко для JimBob понять? Вы делаете ставку.

Будет ли он передать вопросы прессы и успокоить их о том, как Bitcoin полнится взлома и мошенничества? Вы делаете ставку!

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

Цитата: casascius от 24 августа 2011 года, 4:35:32 AM

Просто для сравнения: вот что пользовательский опыт будет, если модифицированное предложение OP_CHECKSIG были приняты.

Со ссылкой на первый пост Гэвины по этой теме

Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM

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

Я думаю, что в последнее время после casascius' оффтоп для этой нити и должны быть перемещены casascius' "Изменить OP_CHECKSIG" нить

Я буду удалять это сообщение после переезда.

ByteCoin

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

Цитата: casascius от 24 августа 2011 года, 3:41:51 PM

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

Для того, чтобы снова цитирую Гэвина

Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM

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

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

Цитата: casascius от 24 августа 2011 года, 3:41:51 PM

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

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

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

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

Ваши предложения в отношении к новому формату адрес будут приветствовать, но, вероятно, более уместно в другом потоке.

ByteCoin

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

Я вижу пункт о внесении изменений в OP_CHECKSIG улучшающего первоначальный запрос, но я не думаю, что это не позволяет нам от необходимости иметь, чтобы придумать стандартные форматы, которые не используют casascius' Casascius улучшения. Предложение Casascius' упрощает много вещей, но требует, чтобы все стороны вручную уведомлены, что они являются частью данной транзакции. Это не всегда может быть предпочтительным, и я думаю, что мы должны вмещать более-явные типы транзакций, которые уже возможно, в любом случае (и будет использоваться раньше, чем мы можем реализовать предложение Casascius').

Другими словами, я сайдинг с обоими, здесь: Я хотел бы видеть изменения casascius' проверки и осуществления, если он кажется безопасным (хотя вложенные скрипты могут открыть некоторые очень творческие проблемы безопасности, я не знаю точно). Но я думаю, что первоначальное предложение Gavin представил еще необходимо решить. В связи с этим, я не обеспокоен длинными строками. Если кто-то не имеет специфический, общий потребительной случай, что я не знаком, адреса почти всегда сообщаться с помощью копирования и вставки в сканирований кода по электронной почте / IM, или через QR. В этом случае, я не вижу, как это на самом деле отношение, как долго это, вероятно, пока она не превышает половины длины а QR-код может обрабатывать (что составляет около 3 КБ).

Уф. Хорошо, я чувствую себя лучше; консенсус, кажется, что включение некоторых или всех операций предлагаемого «нового стандарт» является хорошей идеей.

Все остальное (новый формат адреса? Отправить к старым адресам и немедленно отправить? И т.д. и т.п. и т.д.) можно утверждать, до смерти позже.

Цитата: Гэвин Андресен 24 августа 2011 года, 5:34:49 PM

Уф. Хорошо, я чувствую себя лучше; консенсус, кажется, что включение некоторых или всех операций предлагаемого «нового стандарт» является хорошей идеей.

Да, это отличная идея.

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

В дополнение к (А и В) или С (сценарий защиты бумажник), я также мог видеть (А и В) или (С и г) быть полезным.

Цитата: Гэвин Андресен 24 августа 2011 года, 5:34:49 PM

Пожалуйста, включите версии без адреса. Подобно:
2 Keya KEYB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
2 Keya KEYB 2 OP_CHECKMULTISIG OP_DUP OP_NOTIF KeyBackup OP_CHECKSIG OP_ENDIF

Поэтому часть дискуссии о длине приемлемых ключей, которые помогли бы управлять форматом для этих нескольких сиг адресов. Casascius ... Вы упоминали в другом потоке, что вы на самом деле печатаете несколько адресов в вручную. Что является причиной этого? До сих пор я никогда не нужно делать это сам, и было интересно, если у вас есть особые требования, или если мы ожидаем, что общий сценарий, что люди будут копирование вручную (т.е. типирование). Если это так, то, возможно, он не идеален, чтобы подтолкнуть multisig подход с длинными адресами. Это хорошо, если это будет сделано время от времени, но если есть общий сценарий, что большинство пользователей будут работать в полу-часто, мы, вероятно, должны быть направлены на поддержание их коротки.

Цитата: etotheipi 24 августа 2011, 11:44:41 PM

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

У меня есть серьезные суммы, вложенные в Bitcoins, знаю, что опытные противники после них, и не хотят рисковать. Весь мой Bitcoins находится в автономном режиме почти все время.

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

Цитата: theymos от 24 августа 2011 года, 6:06:40 PM

Пожалуйста, включите версии без адреса. Подобно:
2 Keya KEYB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG

это "Предложение 1" - включить все «набившие оскомину» сделки OP_CHECKMULTISIG.

groffer сообщает найти ошибку в CHECKMULTISIG (появляется слишком много элементов из стека), который заставляет меня задаться вопросом, если было бы лучше, чтобы избежать этого. Для малого п, используя CHECKSIG несколько раз просто и не делают операции намного больше.

(А и б) или сделка с открытыми ключами вместо адресов не в предложении, но ради консистенции, я согласен, что это должно быть.

Следует отметить, что многие из случаев использования депозитного также должны nLockTime быть полезным (не заменяемые числа TX / последовательности, только TX, который никогда не будет даже принят в пул памяти до заданного времени / блока). Я настоятельно призываю вас включить nLockTime. Вот два варианта использования:

http://bitcointalk.org/index.php?topic=25786.0
http://bitcointalk.org/index.php?topic=22581.0

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

Multi-TX и подписано Locktime все, что нужно для мгновенных защищенных транзакций в автономном режиме с будущими расчетами оплаты.

"ненадежный обмен" Прецедент просто нужно еще одну вещь: многократное использование OP_HASHEQUALVERIFY. Я знаю, что вы сказали, не выпрашивать произвольные дополнения в этой теме, но я полагаю, что это стоит выстрел, так как OP_HASHEQUALVERIFY уже используется / разрешен, но только один раз в соответствии с IsStandard. Ненадежный обмен может быть сделано, если вы позволяете больше 2 HASHEQUALVERIFY в ТХ ... Я надеюсь, вы согласитесь, что позволяет сценарий на пару более HASHEQUALVERIFYs не опасно.

Gavin, что статус новых стандартных операций? Кто-нибудь на самом деле authoritatvely решение о том, как новые сделки будут выглядеть в blockchain (в частности, OP_CODE структура сделок)? Любое решение, от того, как они будут упорядочены (с целью раздавать адреса)?

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

23 августа 2011, 9:17:36 PM	# 1
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Воскресенье на Bitcoin конференции я вел небольшую сессию мозговой атаки по расширению набора «стандартных» типов транзакций, и я собирание мозгов людей с помощью электронной почты и IRC-чата (и тянуть запрос комментарии), чтобы работать через деталь. Моя мотивация для желающих сделать это сейчас, потому что это позволит такие функции, как: + подтверждение Multi-устройство тратит, поэтому, если ваш компьютер заражен трояном он не может потратить все свои монеты. + Мастер-ключ аварийного резервного копирования, так что если вы потеряете свой кошелек (и все его резервные копии) вы можете получить мастер-ключ от Вашего сейфа и восстановить все ваши монеты Это также позволит третьей стороне эской и некоторые другие полезные функции, которые не так важны для меня. Первый шаг делает все эти вещи, чтобы разработать формат транзакций низшего уровня и разрешить эти операции, чтобы быть переданы и включены в блоки. То есть все я предлагаю прямо сейчас (на самом деле реализации что-то вроде нескольких устройств подтверждения Потратьте потребуется немного протокола для устройств для связи, новый вид Bitcoin адрес, что люди будут посылать в, и т.д. и т.д. и т.п.). Разработка общего способа сделать (например) 1-из-2-клавиши-необходимые операции будут делать это намного проще для сайтов, как blockexplorer, чтобы отобразить их с умом, и, как правило, сделать жизнь счастливее для кого писать инструменты, которые смотрят на blockchain , Я предпочел бы не иметь такой поворот в "позволяет избавиться от () проверки IsStandard" или "позволяет повторно включить кучу опкодами отключенного в настоящее время", Так что если вы хотите, чтобы говорить о том, что начать новую тему. Текущий проект предложения здесь: https://gist.github.com/39158239e36f6af69d6f

23 августа 2011, 10:42:08 PM	# 2
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Получил 1806 Биткоинов Реальная история. Простите, коверкая кавычки системы несколько ... Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM (А и б) или -------------- Это полезная форма для безопасных, резервируемых кошельков. (А) бы частные ключи хранятся на возможно небезопасным устройстве. (Б) будет ключ счета хранится на каком-то типа «службы защиты кошелька». И (с) будет аварийный ключ хранится в автономном режиме, который может быть использован в случае (а) или (б) ключи утеряны. Код: ScriptSig: сига pubkeya SIGB pubkeyb 0 ИЛИ ScriptSig: sigc pubkeyc 1 ScriptPubKey: ЕСЛИ DUP HASH160 {hashc} EQUALVERIFY CHECKSIG ELSE DUP HASH160 {hashb} EQUALVERIFY CHECKSIGVERIFY DUP HASH160 {Hasha} EQUALVERIFY CHECKSIG ENDIF Неудачная вещь о этой конструкции состоит в том, что аварийный ключ с, хранится в автономном режиме и, надеюсь, никогда не используется, вероятно, будет постоянным в течение очень длительного периода времени. Это приводит к значительной потере сделки анонимности. Было бы неплохо иметь ScriptPubKey для с, из которого она является вычислительно неосуществимо определить, имеет ли другой подобной транзакции один и тот же ключ с. Возможно, финансирующий знает открытый ключ с, шифрует случайное временное значение с помощью ключа и сохраняет его в ScriptPubKey с OP_DROP. Остальная часть ScriptPubKey для с требует, чтобы Искупитель обеспечить подпись и открытый ключ для конкатенации случайного и временного значения искупительной сделки. Может что-то подобное будет реализовано на языке сценариев? ByteCoin

23 августа 2011, 11:50:24 PM	# 3
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Я не понимаю, почему это необходимо для поддержки адресов для резервного копирования и безопасного-устройства транзакций. Bitcoin может вспомнить публичные ключи, прежде чем они экспортируются в резервной копии или устройства. С помощью дополнительного устройства: Код: 2 Keya KEYB 2 OP_CHECKMULTISIG KEYA является локальным ключом известен Bitcoin. KEYB вероятно запомнила предыдущего использования; если нет, то он может быть передан в QR код без особых проблем (~ 90 base64 символы отлично). С резервного копирования: Код: 1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG KeyBackup статична, запоминаются Bitcoin. KeyNormal является локальным ключом.

24 августа 2011, 12:08:39 AM	# 4
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: theymos 23 августа 2011, 11:50:24 PM Я не понимаю, почему это необходимо для поддержки адресов для резервного копирования и безопасного-устройства транзакций. Bitcoin может вспомнить публичные ключи, прежде чем они экспортируются в резервной копии или устройства. С помощью дополнительного устройства: Код: 2 Keya KEYB 2 OP_CHECKMULTISIG KEYA является локальным ключом известен Bitcoin. KEYB вероятно запомнила предыдущего использования; если нет, то он может быть передан в QR код без особых проблем (~ 90 base64 символы отлично). Мульти-устройства прецедентов я себе: Я подписываю с Solutions Acme Bitcoin Security, Inc. Они дают мне открытый ключ WalletProtection (или Bitcoin адрес, не имеет значения) и уникальный-для-меня URL. Я положил адрес / Публичный в мой Bitcoin клиент, "Второй фактор вне устройства Отправить Authentication." Или что-то. (Abbs также посылает мне секретный ключ по почте и говорит мне, чтобы держать его в безопасности в случае, если они выходят из бизнеса) Теперь я хочу, чтобы все монеты, отправленные мне требовать подписи от ключей в моем бумажнике И ключ Abbs потратить. Что Bitcoin адрес я даю людям, так что все монеты, поступающие в мой бумажник имеют это свойство? Если это сырье CHECKMULTISIG, то мне нужно выдавать адреса, содержащие 2 полных открытых ключей. Какой бы 186 символов в base58 и выглядеть примерно так: LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3 Использование 20-байтовые хэшей и более сложный 2-на-2 сделки я предлагаю, адрес является более разумным 61 символов: 2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK

24 августа 2011, 12:15:34 AM	# 5
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: ByteCoin 23 августа 2011, 10:42:08 PM Неудачная вещь о этой конструкции состоит в том, что аварийный ключ с, хранится в автономном режиме и, надеюсь, никогда не используется, вероятно, будет постоянным в течение очень длительного периода времени. Это приводит к значительной потере сделки анонимности. Клиенты могли бы сделать с базой для детерминированного ключа; получить ряд ключей от с, и использовать их в последующих операциях. (Учитывая полный открытый ключ с, вы можете получить серию открытых ключей, не имея секретного ключа) То же самое можно было бы сделать для ключа Ь «Служба защиты бумажника» - каждый раз, когда вы используете б, обратитесь в службу защиты и попросить Ь»полученных детерминировано из б. Тогда Ь ', Ь «»», и т.д. ...

24 августа 2011, 12:29:03 AM	# 6
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Я не думаю, что это разумно поставить нагрузку на отправителе (в общем случае, по крайней мере). Большие адреса будут раздражать работать, и плата будет выше из-за большие объемы данных. Там может быть даже программы сделаны для преобразования "дорогая" адреса в "дешево" адреса путем изменения версии и удаления всех, кроме одного адреса. Получатель должен получить на нормальный адрес, а затем отправить к себе с нечетными сделками. Затем получатель оплачивает дополнительные сборы, и никто не будет иметь дело с огромными адресами. Там будет короткий период времени, когда средства не защищены, но я не думаю, что это, как правило, будет проблемой, и это стоит выгоды.

24 августа 2011, 2:42:24 AM	# 7
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Gavin, Мое предложение изменить OP_CHECKSIG было перенесено и включено в данное описание в качестве ссылки, вместе с ответом предлагая идею несовместим с желаемым графиком выпуска и ожидание blockchain вилки (предположительно, по доле сольных шахтеров, которые просто не будет когда-либо модернизации) является неприемлемым следствием. Я чувствую, что этот ответ более актуален, однако, к продолжающейся дискуссии. Но не стесняйтесь, чтобы переместить этот ответ, а если вы чувствуете, что это неуместно. Если идея (или любая подобная идея с аналогичными последствиями) заслуживает внимания и решает проблему, то почему бы не просто положить его в настоящее время, но только не дают никакого UI для кого использовать его в течение шести месяцев? Сейчас, безопасность является ахиллесовой пятой Bitcoin - ожидание пользователя, клиент эволюционировать, чтобы включить полезную практическую безопасность является значительно больше, чем ожидание, что один должен быть в состоянии сольной шахты с клиентом 4 версии назад. Создание нового формата адрес - особенно больше один - собираются добавить к умственной нагрузке каждому будущего пользователя Bitcoin, и собираются заставить все модернизировать все равно так или иначе. Каждый пользователь пустобреха теперь будет спросить, почему любой другой пользователь дает два Bitcoin адреса, один, чтобы остаться совместимыми и один, чтобы оставаться в безопасности. Он также будет нарушать процедуру вывода каждого сайта, который раздает Bitcoins (или вновь заставить людей поддерживать две разновидности адресов). В какой-то момент, замена клиента будет неизбежно необходимо даже без изменений, так как количество времени, которое требуется для первоначального заполнения и подтверждения blockchain уже растет в геометрической прогрессии, а прошлое неудобно, и к точке стать монументальным и неосуществимым вроде как добыча процессора. Изменение OP_CHECKSIG не может быть конкретный ответ на проблему, но я хотел бы представить вам, что в то время как это программное обеспечение помечается как в бета-версии, вероятность того, что все, возможно, придется обновить их клиент не должен быть dealbreaker, и оград с точки зрения "социальные издержки" по сравнению с введением нового формата адреса. Мое понимание текущего клиента позволяет вызвать сообщение, информирующее пользователей необходима модернизация? Там никогда не будет лучшего времени, и мы умолять обновить.

24 августа 2011, 4:11:01 AM	# 8
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу котировка Я не думаю, что это разумно поставить нагрузку на отправителе (в общем случае, по крайней мере). Большие адреса будут раздражать работать, и плата будет выше из-за большие объемы данных. Там может быть даже программы сделаны для преобразования "дорогая" адреса в "дешево" адреса путем изменения версии и удаления всех, кроме одного адреса. Получатель должен получить на нормальный адрес, а затем отправить к себе с нечетными сделками. Затем получатель оплачивает дополнительные сборы, и никто не будет иметь дело с огромными адресами. Там будет короткий период времени, когда средства не защищены, но я не думаю, что это, как правило, будет проблемой, и это стоит выгоды. Я думаю, что это произвольное различие. Люди сами должны будут общаться со своими клиентами, чтобы выполнить 1-из-2, 2-из-2, и т.д., сделки. Обеспечение стандарта "код" для них позволит пользователям знать, что они делают. Если я говорю своей жене, чтобы положить деньги в нашем 1-из-2 или 2-из-2 счетов, я даю ей длинный код. Если я продаю вещи в Интернете, я использую свое предложение (дать покупателю рег адрес, переместить его сам). Ключ для создания языка. Люди будут использовать его как они считают целесообразным. Для этих более сложных операций, мы должны придумать терминологии и методологии для их выполнения. Мы должны не только создавать транзакции, но и сделать интуитивно понятный интерфейс, чтобы их тратить. Я предлагаю сделать "предложение" сбщ, что пользователи могут импортировать и выбрать знак. Каждый человек может подписать и передать результат в следующей партии. После того, как последняя партия подписывает его, клиент скажет им "Это верное предложение!" и будет представлен с кнопкой для "Вещание сейчас" или что-то типа того Нажмите здесь для полноразмерного изображения: http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogs.png Я оставил выключение "сохранить в файл" кнопка поэтому он может быть присоединен к электронной почте вместо встроенного. Конечно, Base58 было бы точная сериализация предлагаемого Tx, с одним входом и предполагаемыми результатами. Не дергайте слишком глубоко в детали приложенных изображений: они просто отвлеченный.

24 августа 2011, 4:35:32 AM	# 9
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Просто для сравнения: вот что пользовательский опыт будет, если модифицированное предложение OP_CHECKSIG были приняты. Jimbob, который просто средний парень с помощью службы защиты кошелька, будет выдавать нормальный вид хорошо сформированный Bitcoin адреса для Салли и будет принимать платежи только как нормальные. Jimbob использует версию клиента Bitcoin, который знает, что его средства обременены пары ключей А, В (не говоря уже о С в настоящее время), и что он только обладает персональным ключом для А. Она знает, что закрытый ключ B управляется третья сторона через веб-сервис. Когда он идет тратить свои средства, его клиент подписывает сделку с ключом, и корабли незавершенной транзакции прочь к веб-сервис для проверки. Веб-сервис делает его должной осмотрительности, например, эта конкретная услуга посылает SMS на мобильный телефон JimBob, в "Вы отправляете 57.00 BTC в 1xyzabcdABCD123 ... Ответить 1, если OK", JimBob ответы 1, и WebService знаки с B и направляет его на операцию к сети. Безопасный для JimBob? Вы делаете ставку. Легко для JimBob понять? Вы делаете ставку. Будет ли он передать вопросы прессы и успокоить их о том, как Bitcoin полнится взлома и мошенничества? Вы делаете ставку! Теперь, ключ C является то, что напечатано Jimbob и застрял в его сейфе, когда его бумажник был сгенерирован. Это его безотказное против своего компьютера сбоя или веб-сервиса, выходя из бизнеса.

24 августа 2011, 12:17:35 PM	# 10
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: casascius от 24 августа 2011 года, 4:35:32 AM Просто для сравнения: вот что пользовательский опыт будет, если модифицированное предложение OP_CHECKSIG были приняты. Со ссылкой на первый пост Гэвины по этой теме Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM Я предпочел бы не иметь такой поворот в "позволяет повторно включить кучу опкодами отключенного в настоящее время", Так что если вы хотите, чтобы говорить о том, что начать новую тему. Я думаю, что в последнее время после casascius' оффтоп для этой нити и должны быть перемещены casascius' "Изменить OP_CHECKSIG" нить Я буду удалять это сообщение после переезда. ByteCoin

24 августа 2011, 4:38:54 PM	# 11
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу В интересах моего существа критически в непредвзято, я должен отметить, что я думаю etotheipi и самые последние сообщения theymos' по этой теме также оффтоп. Цитата: casascius от 24 августа 2011 года, 3:41:51 PM Это звучит для меня как Gavin было два предложения от своих первоначальных и вторых сообщений: один о расширении параметров, что () будет принимать IsStandard, а вторые о построении новой формы Bitcoin адреса. Для того, чтобы снова цитирую Гэвина Цитата: Гэвин Андресен 23 августа 2011 года, 9:17:36 PM ... разработать формат транзакций низшего уровня и разрешить эти операции, чтобы быть переданы и включены в блоки. Это все я предлагаю прямо сейчас В частности, он отмечает, что реализация может потребовать новый формат адреса, который выходит за рамки данной дискуссии. Цитата: casascius от 24 августа 2011 года, 3:41:51 PM Для меня эта нить о втором предложении, поскольку первый из них является слэм-данк непротиворечивым предложение, которое не имеет каких-либо негативных последствий В этом случае, вы не имеете ничего, кроме вашего утверждения, чтобы внести свой вклад в эту тему. Нить, о чем вы срок "первое предложение", Как то, что вы называете "второе предложение" никогда не было предложено. Если вы посмотрите на комментарии по этому документу Gavin связаны, вы можете увидеть, что там было много, чтобы говорить о том, и правильно о своем предложении, которое вы сочтете непротиворечивым. Этот поток предназначен для привлечения более критического внимания к предложению, с тем, что любые проблемы будут исправлены. Ваши предложения в отношении к новому формату адрес будут приветствовать, но, вероятно, более уместно в другом потоке. ByteCoin

24 августа 2011, 5:23:34 PM	# 12
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Я думаю, что это действительно помогает, в целом, рассмотреть вопрос о том, как пользователи могут / будут использовать эти операции, а затем форматы сообщений могут быть предназначены для размещения. Но, на перечитывание оригинальной нити, я вижу, что я немного неправильно понял первоначальное намерение предложения Гэвины. Он ищет более того, как эти операции будут закодированы в blockchain, не то, как люди будут использовать их. Так что да, мой пост был немного не по теме. Вы можете игнорировать это тогда. Я перерабатываю эти макеты для более-соответствующего потока. Я вижу пункт о внесении изменений в OP_CHECKSIG улучшающего первоначальный запрос, но я не думаю, что это не позволяет нам от необходимости иметь, чтобы придумать стандартные форматы, которые не используют casascius' Casascius улучшения. Предложение Casascius' упрощает много вещей, но требует, чтобы все стороны вручную уведомлены, что они являются частью данной транзакции. Это не всегда может быть предпочтительным, и я думаю, что мы должны вмещать более-явные типы транзакций, которые уже возможно, в любом случае (и будет использоваться раньше, чем мы можем реализовать предложение Casascius'). Другими словами, я сайдинг с обоими, здесь: Я хотел бы видеть изменения casascius' проверки и осуществления, если он кажется безопасным (хотя вложенные скрипты могут открыть некоторые очень творческие проблемы безопасности, я не знаю точно). Но я думаю, что первоначальное предложение Gavin представил еще необходимо решить. В связи с этим, я не обеспокоен длинными строками. Если кто-то не имеет специфический, общий потребительной случай, что я не знаком, адреса почти всегда сообщаться с помощью копирования и вставки в сканирований кода по электронной почте / IM, или через QR. В этом случае, я не вижу, как это на самом деле отношение, как долго это, вероятно, пока она не превышает половины длины а QR-код может обрабатывать (что составляет около 3 КБ).

24 августа 2011, 5:34:49 PM	# 13
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Уф. Хорошо, я чувствую себя лучше; консенсус, кажется, что включение некоторых или всех операций предлагаемого «нового стандарт» является хорошей идеей. Все остальное (новый формат адреса? Отправить к старым адресам и немедленно отправить? И т.д. и т.п. и т.д.) можно утверждать, до смерти позже.

24 августа 2011, 6:04:37 PM	# 14
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: Гэвин Андресен 24 августа 2011 года, 5:34:49 PM Уф. Хорошо, я чувствую себя лучше; консенсус, кажется, что включение некоторых или всех операций предлагаемого «нового стандарт» является хорошей идеей. Да, это отличная идея. Я мог видеть случай для ограничения его на очень специфические Синтаксисах - такие, как (А и В) или С, а также несколькими другихов с выявленным конкретным использованием - так, что блок-схема алгоритма для решения "это оплата шахты" не становится бесконечно сложным. Например, клиент, который получает эту сделку и имеет только ключ А нужен способ, чтобы четко отобразить пользователь этих средств являются "ваш" но обременены. В дополнение к (А и В) или С (сценарий защиты бумажник), я также мог видеть (А и В) или (С и г) быть полезным.

24 августа 2011, 6:06:40 PM	# 15
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: Гэвин Андресен 24 августа 2011 года, 5:34:49 PM Уф. Хорошо, я чувствую себя лучше; консенсус, кажется, что включение некоторых или всех операций предлагаемого «нового стандарт» является хорошей идеей. Все остальное (новый формат адреса? Отправить к старым адресам и немедленно отправить? И т.д. и т.п. и т.д.) можно утверждать, до смерти позже. Пожалуйста, включите версии без адреса. Подобно: 2 Keya KEYB 2 OP_CHECKMULTISIG 1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG 2 Keya KEYB 2 OP_CHECKMULTISIG OP_DUP OP_NOTIF KeyBackup OP_CHECKSIG OP_ENDIF

24 августа 2011, 11:44:41 PM	# 16
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Поэтому часть дискуссии о длине приемлемых ключей, которые помогли бы управлять форматом для этих нескольких сиг адресов. Casascius ... Вы упоминали в другом потоке, что вы на самом деле печатаете несколько адресов в вручную. Что является причиной этого? До сих пор я никогда не нужно делать это сам, и было интересно, если у вас есть особые требования, или если мы ожидаем, что общий сценарий, что люди будут копирование вручную (т.е. типирование). Если это так, то, возможно, он не идеален, чтобы подтолкнуть multisig подход с длинными адресами. Это хорошо, если это будет сделано время от времени, но если есть общий сценарий, что большинство пользователей будут работать в полу-часто, мы, вероятно, должны быть направлены на поддержание их коротки.

25 августа 2011, 12:53:52 AM	# 17
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: etotheipi 24 августа 2011, 11:44:41 PM Поэтому часть дискуссии о длине приемлемых ключей, которые помогли бы управлять форматом для этих нескольких сиг адресов. Casascius ... Вы упоминали в другом потоке, что вы на самом деле печатаете несколько адресов в вручную. Что является причиной этого? До сих пор я никогда не нужно делать это сам, и было интересно, если у вас есть особые требования, или если мы ожидаем, что общий сценарий, что люди будут копирование вручную (т.е. типирование). Если это так, то, возможно, он не идеален, чтобы подтолкнуть multisig подход с длинными адресами. Это хорошо, если это будет сделано время от времени, но если есть общий сценарий, что большинство пользователей будут работать в полу-часто, мы, вероятно, должны быть направлены на поддержание их коротки. Я использую бумагу Bitcoin кошельков и несколько компьютеров, в том числе один выделенный для сделок в BTC, и другую для взаимодействия с финансовыми веб-сайтов (в том числе Bitcoin обменов), который не просматривает никакие другие веб-сайты, так что я свести к минимуму риск того, мои Bitcoins потеряны или украдены и мои счета скомпрометированы. Несмотря на то, что кажется несколько еретическими, тем больше людей их Bitcoins украден, не видя его прихода, тем больше она имеет смысл. У меня есть серьезные суммы, вложенные в Bitcoins, знаю, что опытные противники после них, и не хотят рисковать. Весь мой Bitcoins находится в автономном режиме почти все время. Когда я беру биткоен в автономном режиме, я разбиваю их на номиналы, так что если мне просто нужно что-то маленькое купить, я могу импортировать "20" или любой другой, и оставить оставшуюся часть моего тайника безопасного.

25 августа 2011, 2:06:01 AM	# 18
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Цитата: theymos от 24 августа 2011 года, 6:06:40 PM Пожалуйста, включите версии без адреса. Подобно: 2 Keya KEYB 2 OP_CHECKMULTISIG 1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG это "Предложение 1" - включить все «набившие оскомину» сделки OP_CHECKMULTISIG. groffer сообщает найти ошибку в CHECKMULTISIG (появляется слишком много элементов из стека), который заставляет меня задаться вопросом, если было бы лучше, чтобы избежать этого. Для малого п, используя CHECKSIG несколько раз просто и не делают операции намного больше. (А и б) или сделка с открытыми ключами вместо адресов не в предложении, но ради консистенции, я согласен, что это должно быть.

25 августа 2011, 4:28:06 AM	# 19
hashcoin Сообщения: 141 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Следует отметить, что многие из случаев использования депозитного также должны nLockTime быть полезным (не заменяемые числа TX / последовательности, только TX, который никогда не будет даже принят в пул памяти до заданного времени / блока). Я настоятельно призываю вас включить nLockTime. Вот два варианта использования: http://bitcointalk.org/index.php?topic=25786.0 http://bitcointalk.org/index.php?topic=22581.0 В одном из них я упоминал об использовании сменного TX, не знаю почему, но они не нужны. Multi-TX и подписано Locktime все, что нужно для мгновенных защищенных транзакций в автономном режиме с будущими расчетами оплаты. "ненадежный обмен" Прецедент просто нужно еще одну вещь: многократное использование OP_HASHEQUALVERIFY. Я знаю, что вы сказали, не выпрашивать произвольные дополнения в этой теме, но я полагаю, что это стоит выстрел, так как OP_HASHEQUALVERIFY уже используется / разрешен, но только один раз в соответствии с IsStandard. Ненадежный обмен может быть сделано, если вы позволяете больше 2 HASHEQUALVERIFY в ТХ ... Я надеюсь, вы согласитесь, что позволяет сценарий на пару более HASHEQUALVERIFYs не опасно.

18 сентября 2011, 7:02:26 PM	# 20
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Предложение: стандартные операции для безопасности / резервного копирования / эскроу Gavin, что статус новых стандартных операций? Кто-нибудь на самом деле authoritatvely решение о том, как новые сделки будут выглядеть в blockchain (в частности, OP_CODE структура сделок)? Любое решение, от того, как они будут упорядочены (с целью раздавать адреса)? Я понимаю, что вы, вероятно, работать на обновленном клиенте, но я хотел бы знать, если вы достигли каких-либо выводов, так как эта нить, кажется, был оставлен неработающим месяц назад ...

Заголовок