Многие пользователи интернета значительно недооценивают значение такого свойства как «гибкость» для биткойна. А именно это свойство усовершенствует обновление Segregated Witness.
Давайте обратимся к докладу, вышедшему в 2016 году под названием Bitcoin Covenants (Соглашение о Биткойне), в котором говорится о функции «хранилища». Я попытаюсь вкратце объяснить, как работает Хранилище, и как его можно применить для биткойна без SegWit (в прошлом) и для биткойна с SegWit (сейчас).
Во-первых, что же такое это Хранилище? Упрощенная версия будет выглядеть примерно так: вы перемещаете свои активы на специальный адрес V («Vault» — хранилище), с которого можете переводить их исключительно на один адрес – W (от англ. withdrawal — «инициализация процесса вывода средств»). От адреса W ведут два пути. Первый: вы можете переводить средства с W куда угодно, только спустя 24 часа после первоначального вывода (то есть, спустя 24 часа после транзакции V->W) используя только один ключ A. Также есть другой способ. Вы можете переводить средства без каких-либо задержек и на любой адрес, но при этом вам понадобятся и активный ключ A и ключ восстановления R (или несколько ключей восстановления).
Представляю вам диаграмму:
первоначальный депозит: $ ——-> V
инициировать вывод: V ——-> W, используя ключ A
разблокировать средства после задержки: W —(a)—> *, через ключ A и задержку в 24 часа
восстановить средства: W —(b)—> *, с ключами A и R, без задержек
За Хранилищем стоит следующая теория: обычные ключи просты в использовании (они всегда под рукой), но они довольно уязвимы, поэтому необходимо вводить «попытку вывода» с периодом задержки. Если транзакция законная, пользователю просто нужно подождать пока платеж пройдет. В противном случае, у пользователя есть время на то, чтобы заметить попытку вывода и устранить её при помощи ключей восстановления: скажем, попросить друзей подписать транзакцию, или найти давно зарытую во дворе копию. Время задержки может быть прямо пропорционально сумме средств конкретного запроса. Если сумма небольшая, хранилище может и вовсе не использоваться, для средней суммы задержка составит 24 часа, а для долгосрочных сбережений — 72-часовую задержку, а также многоуровневое восстановление с участием доверительных лиц (друзей/родственников).
На сегодняшний день биткойн не имеет функции CheckOutputVerify, которая предлагается в докладе Covenants. Чтобы отобразить ее для Хранилища, мы можем использовать временный ключ V для адреса Хранилища и предварительно подписанную транзакцию V->W. Ключ V уничтожается сразу после поступления средств на адрес V. Дальше, вывод можно будет инициировать только через опубликование транзакции V->W. Адрес W может использовать уже доступную функцию CheckSequenceVerify, которая позволяет относительно контролировать время опубликования (например, «24 часа после публикации транзакции»), также на случай «если/вдруг что» есть возможность вернутся в начальную точку без задержек.
Если бы не было пластичности транзакций, можно было бы просто сделать следующее:
Создать временный ключ V.
Создать и подписать транзакцию T1, которая платит V.
Создать и подписать транзакцию T2, которая платит от V к W.
Удалить ключ V.
Опубликовать транзакцию T1.
Сохранить транзакцию T2, зашифровав ее активным ключом A.
Для вывода: опубликовать транзакцию T2, подписав расходы задержек от транзакции T2 на определенный адрес, затем, по истечении необходимого времени, опубликовать транзакцию.
Если мы сталкиваемся с пластичностью транзакций, то невозможно сделать шаги с 1 по 6 одновременно. Нам бы пришлось сохранять временный ключ V намного дольше, размещая его на диске (вместо нескольких секунд хранения в оперативной памяти), до тех пор, пока транзакция T1 не будет подтверждена, а риск реорганизации цепи не будет сведен к минимуму.
Но что еще хуже – мы создаем новую точку уязвимости. Так, для регулярных платежей реорганизация может отменить платеж, который был отправлен повторно. Если вы отправляете деньги себе – это не проблема. Но если вы удалите временный ключ, и подписанная транзакция (T2) — единственный способ восстановить ваши средства, реорганизация может заблокировать ваши средства навсегда. Вам придется немало подождать, чтобы ваши биткойны были надежно защищены транзакцией T1.
А пока вы будете в режиме ожидания, необходимо хранить ключ V, а также необходимо создать его резервную копию. Если вы уже сделали такую копию, необходимо защитить её надежным паролем, но при этом схема должна позволять хранить активный ключ A с посредственным паролем, потому что надежных паролей на самом деле нет. Получается, если ваш ключ V попал кому-то в руки, пока вы находитесь в режиме ожидания, вы автоматически теряете всю защиту: злоумышленникам не надо будет использовать специально разработанную транзакцию T2, а всего лишь воспользоваться ключом V.
Поэтому бдеть над V надо сильнее, чем над A. Этого можно добиться при помощи той же системы мультиподписи, которая будет использовать для ключей восстановления R: можно попросить своих друзей выступить в роли коллективного дополнительного ключа для вашего временного V, чтобы предварительно подписать транзакцию T2 (используя мою схему слепой подписи для поддержки конфиденциальности). Но теперь вы будете просить своих друзей не только о своем механизме восстановления (который вам возможно никогда не придется использовать), но придётся обращаться к ним каждый раз, когда потребуется перевести деньги в хранилище.
Как результат – кошелек должен быть намного сложнее, с большим количеством взаимодействующих частей, высокой интерактивностью с пользователем и дополнительными мерами безопасности, вместо того, чтобы позволять делать очевидные вещи простым нажатием кнопки.
СегВит приводит в порядок пластичность транзакций и позволяет создавать схемы для повышения безопасности. А это гораздо важнее, чем незначительное увеличение пропускной способности транзакций, поскольку биткойн большую часть времени хранится, и лишь изредка меняет владельца.
YouTube YouTube
Источник.
31.10.2017, 21:36
