Зачем нужен Скрипт?

На мой взгляд, функция скрипта — одна из самых сложных функций во всем протоколе. Он имеет

$ cat src/script.h|grep '^ *OP_'|wc -l
118

инструкции и требует стека для расчета.

Самое главное ограничение, оно усложняет ответ на простой и распространенный вопрос — «сколько биткойнов в моем ключе».

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

В чем рациональность такой системы? Почему любая транзакция не может быть просто «переместить X BTC с ключа K на ключ, который я подписал закрытым ключом K»?

(Если вам действительно нужно что-то сложное — делайте это в другой системе, а не внутри блока биткойнов).

Я думаю, что утверждение «простой» тип транзакций может быть осуществимо, если доказано, что они не содержат ошибок из-за сценариев» правильно. Большинство транзакций в реальных транзакциях в ближайшем будущем будут использовать только тривиальные сценарии ... и я считаю, что если вы решите использовать только такие транзакции (скажем, с «безопасным клиентом» или «безопасным режимом», который отклоняет все другие tx), тогда вы можете быть в безопасности от потенциальных ошибок. Полезность скриптов огромна, но вы можете обойти их для повседневного использования, если вам не нужны эти функции... или я так думаю/надеюсь.
Можете ли вы объяснить, почему полезность скриптов огромна, особенно учитывая, что большинство транзакций являются «обычными»? И поправьте меня, если я ошибаюсь, но безопасный клиент не защитит вас от ошибок, разделяющих сеть.
Скрипты очень полезны, потому что они позволяют все, что написал @theymos, и многое другое. Большинству транзакций не нужно использовать какие-либо функции, но многие люди предпочтут использовать эти скрипты для хранения своего «сверхзащищенного кошелька, использующего мультиподпись», при ведении повседневных дел через более простую транзакцию. Прелесть в том, что как пользователь вы можете полностью изолировать себя от любого риска. Я не думаю, что ошибка разделения сети является реалистичным сценарием — попробуйте задать другой вопрос, например «Могут ли ошибки в выполнении сценария реально вызвать разделение сети», чтобы понять, почему или почему нет.

Ответы (3)

Почему любая транзакция не может быть просто «переместить X BTC с ключа K на ключ, который я подписал закрытым ключом K»?

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

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

Не приведет ли полнота Тьюринга к бесконечным циклам?
@makerofthings7 Должно быть какое-то ограничение на количество инструкций, выполняемых для каждого скрипта.
Я глубоко погружаюсь в сценарии и портирую доказательство концепции на C# из BitcoinJ. Есть ли у вас какие-либо подробности о некоторых полезных теоретических сценариях? Страница контрактов не содержит достаточно подробностей, и нет примеров полного примера Тьюринга.

(Если вам действительно нужно что-то сложное — делайте это в другой системе, а не внутри блока биткойнов).

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

Существует несколько схем обмена ключами по сложным схемам, например Shamir’s Secret Sharing . К сожалению, для этого по-прежнему требуется рекомбинация полного секретного ключа в одной компьютерной системе в какой-то момент времени, что становится единой точкой отказа.

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

В чем рациональность такой системы? Почему любая транзакция не может быть просто «переместить X BTC >> с ключа K на ключ, который я подписал закрытым ключом K»?

Ограничение транзакций такой простой формой ограничило бы Биткойн именно теми возможностями, которые были у традиционных валют (хотя и децентрализованных). Однако Сатоши увидел потенциал, позволяющий сделать больше, и ввел систему сценариев. Его больше не было рядом, чтобы применить это на практике, но Майк Хирн записал некоторые вещи, которые Сатоши имел в виду, на странице « Контракты» биткойн-вики .

Стоит отметить, что существует протокол, разработку которого возглавляет Стефан Томас, который позволяет создать транзакцию 2-of-2 (а может быть, m-of-n) из двух ключей ECDSA, не объединяя их, и выглядит точно так же, как один Подпись ECDSA, которую можно разместить в простой транзакции. Так что, по крайней мере, это приложение не обязательно требует скриптов.
Вы также можете использовать совместное использование секрета Шамира в сочетании с транзакциями M из N. Один или несколько закрытых ключей N можно разделить на несколько общих ресурсов с помощью SSS. Если вы решите использовать SSS, вот довольно простая реализация Python: github.com/halfmoonlabs/secretsharing .

Самое главное ограничение, оно усложняет ответ на простой и распространенный вопрос — «сколько биткойнов в моем ключе».

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