На мой взгляд, функция скрипта — одна из самых сложных функций во всем протоколе. Он имеет
$ cat src/script.h|grep '^ *OP_'|wc -l
118
инструкции и требует стека для расчета.
Самое главное ограничение, оно усложняет ответ на простой и распространенный вопрос — «сколько биткойнов в моем ключе».
При сложном скрипте более вероятен баг в скриптовом движке, а значит, возможно раскол сети (50% клиентов принимают эту транзакцию, 50% нет, прежде чем вы заметите, у вас две длинные цепочки блоков. Один более длинный, который считают недействительным 50% клиентов, и один более короткий, который считают действительным оба).
В чем рациональность такой системы? Почему любая транзакция не может быть просто «переместить X BTC с ключа K на ключ, который я подписал закрытым ключом K»?
(Если вам действительно нужно что-то сложное — делайте это в другой системе, а не внутри блока биткойнов).
Почему любая транзакция не может быть просто «переместить X BTC с ключа K на ключ, который я подписал закрытым ключом K»?
Тогда вы не могли бы (легко) реализовать вещи P2SH, внедряемые прямо сейчас, не заставив всех обновиться. Вы также не могли использовать условное депонирование, мультиподпись, безопасную торговлю между сетями, безопасную высокочастотную торговлю и т. д. Эти функции очень ценны; Например, условное депонирование на основе скриптов станет первой системой условного депонирования, не требующей доверия к третьим сторонам.
Скрипт, на мой взгляд, является одним из величайших нововведений в Биткойне. На самом деле я бы предпочел гораздо более мощную, полную по Тьюрингу версию Script в биткойнах.
(Если вам действительно нужно что-то сложное — делайте это в другой системе, а не внутри блока биткойнов).
Я сначала попытаюсь ответить на ваш второй комментарий: короче, вы не можете сделать это в другой системе с теми же свойствами безопасности.
Существует несколько схем обмена ключами по сложным схемам, например Shamir’s Secret Sharing . К сожалению, для этого по-прежнему требуется рекомбинация полного секретного ключа в одной компьютерной системе в какой-то момент времени, что становится единой точкой отказа.
Напротив, транзакции Биткойн 2 из 2, например, позволяют создать транзакцию, которая должна быть подписана с использованием двух разных ключей, которые могут находиться в двух разных системах, независимых друг от друга. Мы надеемся, что это позволит приложениям, требующим подтверждения, быть предоставленным в системе мобильного телефона, в то время как закрытый ключ этого телефона никогда не должен покидать устройство.
В чем рациональность такой системы? Почему любая транзакция не может быть просто «переместить X BTC >> с ключа K на ключ, который я подписал закрытым ключом K»?
Ограничение транзакций такой простой формой ограничило бы Биткойн именно теми возможностями, которые были у традиционных валют (хотя и децентрализованных). Однако Сатоши увидел потенциал, позволяющий сделать больше, и ввел систему сценариев. Его больше не было рядом, чтобы применить это на практике, но Майк Хирн записал некоторые вещи, которые Сатоши имел в виду, на странице « Контракты» биткойн-вики .
Самое главное ограничение, оно усложняет ответ на простой и распространенный вопрос — «сколько биткойнов в моем ключе».
Почему это ограничение? На самом деле это критически важная защита от одной из самых реалистичных уязвимостей в криптовалютах, увековеченной в этом мультфильме XKCD . Есть по крайней мере одна очень веская причина, по которой Сатоши решил остаться анонимным.
потрошитель234
Элазар Лейбович
потрошитель234