Обмен электронных валют по самому выгодному курсу!
 


Kurbetsoft
Доступно в Google PlayКак SegWit улучшает безопасность

Как SegWit улучшает безопасность

Многие пользователи интернета значительно недооценивают значение такого свойства как «гибкость» для биткойна. А именно это свойство усовершенствует обновление 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 часа после публикации транзакции»), также на случай «если/вдруг что» есть возможность вернутся в начальную точку без задержек.

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

  1. Создать временный ключ V.
  2. Создать и подписать транзакцию T1, которая платит V.
  3. Создать и подписать транзакцию T2, которая платит от V к W.
  4. Удалить ключ V.
  5. Опубликовать транзакцию T1.
  6. Сохранить транзакцию T2, зашифровав ее активным ключом A.
  7. Для вывода: опубликовать транзакцию T2, подписав расходы задержек от транзакции T2 на определенный адрес, затем, по истечении необходимого времени, опубликовать транзакцию.

Если мы сталкиваемся с пластичностью транзакций, то невозможно сделать шаги с 1 по 6 одновременно. Нам бы пришлось сохранять временный ключ V намного дольше, размещая его на диске (вместо нескольких секунд хранения в оперативной памяти), до тех пор, пока транзакция T1 не будет подтверждена, а риск реорганизации цепи не будет сведен к минимуму.

Но что еще хуже – мы создаем новую точку уязвимости. Так, для регулярных платежей реорганизация может отменить платеж, который был отправлен повторно. Если вы отправляете деньги себе – это не проблема. Но если вы удалите временный ключ, и подписанная транзакция (T2) — единственный способ восстановить ваши средства, реорганизация может заблокировать ваши средства навсегда. Вам придется немало подождать, чтобы ваши биткойны были надежно защищены транзакцией T1.

А пока вы будете в режиме ожидания, необходимо хранить ключ V, а также необходимо создать его резервную копию. Если вы уже сделали такую копию, необходимо защитить её надежным паролем, но при этом схема должна позволять хранить активный ключ A с посредственным паролем, потому что надежных паролей на самом деле нет. Получается, если ваш ключ V попал кому-то в руки, пока вы находитесь в режиме ожидания, вы автоматически теряете всю защиту: злоумышленникам не надо будет использовать специально разработанную транзакцию T2, а всего лишь воспользоваться ключом V.

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

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

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

Источник

 




[vkontakte] [facebook] [twitter] [odnoklassniki] [mail.ru] [livejournal]

Каталог сайтов