Только продолжение этой дискуссии:

Сценарий один из самых важных элементов в Bitcoin, но это далеко от совершенства. Некоторые коды были отключены из-за ошибки. OP_CHECKSIG не модернизирован. У нас даже есть шанс иметь Script 2.0? Это Script 2.0 в моей голове:

1. Он должен быть обратно совместим, так называемый мягкий вилка. Благодаря Satoshi, этот существующий скрипт позволит сделать это переосмысление одного из OP_NOP как нечто вроде OP_SCRIPT2EVAL

2. Он должен быть полностью модернизированы: он должен сохранить достаточно места для будущей модернизации, в случае, если мы хотим, чтобы скрипт 3,0, 4,0, 5,0. Это просто

3. Поддержка merklized абстрактного синтаксического дерева (МАСТ). Это позволит очень сложные условия погашения и вложения секретных сообщений, экономя при этом много места.

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

5. Поддержка более алгоритмы хэширования. То же, что 4

6. OP_CHECKSIG должна быть разбита на несколько кодов. Это должно позволить подписывающий указать значение входного поэтому легкий кошелек можно рассчитать плату, не зная подробностей предыдущего ТХ. Она должна иметь достаточную гибкость, чтобы позволить людям решить, как подписать. У меня были другие предварительные идеи здесь:

7. Новый OP_CHECKSIG должен принять УЮ податливость в виде. Это должно позволить людям не указывать TXID ввода (подписание любого UTXO одного и того же адреса), или подписать нормализованное TXID. С нормированной TXID поддерживается, однако, это означает, что полные узлы держать индекс нормированной TXID всех UTXO

8. Это может позволить толкая высоту блока и блока хэш на карту. Нажатие высоты блока может позволить что-то не выполнимо с nLockTime (я не очень уверен). Нажатие блок хэша позволит пользователям указать вилку, которые они хотят, чтобы их ТХ добываются (что-то вроде POS. Не уверен, если это действительно полезно)

EDIT: 9. Это должно позволить использовать более короткий хэш и открытый ключ. Это будет очень полезно для микро-платежей и краткосрочного хранения.

Проблема заключается в том, имея Script 2.0, как это может быть опасно. Возможно, нам необходимо создать новый альт-монетку, чтобы проверить его в течение длительного времени, прежде чем он может быть слияние с Bitcoin. Любые комментарии?