Sipa перечисляет источники гибкости tx здесь: https://gist.github.com/sipa/8907691 .
Мне ясно, как изменение самой подписи или форматирования подписи приводит к другому хэшу tx (1. и 2.). Но почему разрешено изменять остальные (может быть "") скрипты ?
Насколько я понимаю, можно изменить только сценарий txin, потому что сценарии txout включены в хэш(и) подписи. Очевидно, что сама подпись не может быть включена в подписанный хеш.
Для каждой подписи соответствующий сценарий txin заменяется соответствующим предыдущим сценарием вывода (?), а все остальные сценарии txin в tx удаляются.
Почему скрипт txin (без подписи, так что это пустая строка для стандартного tx ) не включен в хешированные и подписанные данные?
(Пожалуйста, поправьте меня, если я что-то не так понял.)
редактировать: пытаясь выразить себя более четко:
Конечно, диапазон и формат подписи должны быть стандартизированы. Но есть и другие случаи пластичности, как указывает Сипа, например, добавление бессмысленных OP в сценарий tx_in или использование альтернативных OP, которые имеют такой же или аналогичный эффект. Я говорю только об этих других случаях.
Я хочу сказать: сама подпись не может быть подписана, но почему OP-коды, которые могут присутствовать или отсутствовать в сценарии txin, не подписаны?
Пример:
сегодня:
обычный txinscript: "sig" --> формат подписи: "" --> допустимый
malled txinscript: "OP_NULL sig" --> формат подписи: "" --> действительный
Почему бы и нет:
обычный txinscript: "sig" --> формат подписи: "" --> действительный
txinscript: "OP_NULL sig" --> формат подписи: "OP_NULL" --> FAIL
Формат подписи сегодня заменяет весь txinscript на "". Мне кажется, что было бы безопаснее удалить только саму подпись, но сохранить коды операций, если они есть, чтобы невозможно было изменить существующие коды операций или добавить бессмысленные коды операций.
Это потому, что неизвестно, какая часть скрипта является подписью? Я думаю, что это может быть помечено как таковое, если это будет проблемой.
Вы абсолютно правы.
Единственная причина, по которой это делается, заключается в том, что в настоящее время правила консенсуса работают иначе. Для его изменения потребуется хард-форк, обновление каждого узла и, в конечном итоге, каждого кошелька.
«Сценарий» tx_in — это подпись (а также открытый ключ и некоторое форматирование). Это несколько запутанное имя, которое как бы подразумевает, что есть скрипт tx_in, а затем где-то еще эта подпись, но это не так.
Подпись не может быть включена во входные данные, формирующие подпись.
Эта схема может помочь. https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png
Диаграмма слева представляет собой «стандартный» tx_in.
Структура tx_input состоит из
Previous txout-hash (tx_id)
Previous Txout-index
Txin-script length
Txin-script
sequence_no
Однако на самом деле это просто абстракция, Txin_script — это просто подпись и открытый ключ, который состоит из:
L(sig)
0x30
L(rs)
0x02
L(r)
Sig r
0x02
L(s)
Sig s
0x01
L(key)
0x04
Key X
Key y (only for uncompressed keys)
Таким образом, вы говорите, что сценарий txin является изменчивым, это просто еще один способ сказать подпись (и форматирование). Не существует единого метода изменчивости. Сама ECDSA имеет изменяемые подписи, заполнение и форматирование подписи можно изменить, и она останется действительной.
Чтобы сделать tx_id неизменяемым, требуется либо вычислить tx_id (хэш) с использованием альтернативного метода, где полезная нагрузка хэша состоит из неизменяемых элементов, либо ограничить подпись ECDSA определенным подмножеством параметров, форматированием и дополнением, чтобы для данной полезной нагрузки существовало — это только одна возможная «правильная» подпись Биткойн. Все остальное, даже если это действительная подпись ECDSA, будет считаться недействительной в сети Биткойн.
Это нетривиальная задача. Не невозможно, но это не будет решено «быстро и легко» и, насколько я понимаю, потребуется хард-форк сети. Это означает дополнительное время на тестирование, добавление прямой совместимости и достижение консенсуса, чтобы избежать непредвиденных последствий, таких как оставление значительной части сети на старом форке.
My point is: The signature itself can not be signed but why are OP codes that may or may not be present in the txin script not signed?
Обновленный вопрос дает более конкретный контекст, поэтому я отвечу на него как на новый ответ.
Нет никаких причин, по которым Биткойн нельзя было бы разветвить, чтобы выполнить то, что вы указываете. Если вам интересно, почему такая сложная схема подписи? Как говорит Питер, «спросите Сатоши».
Еще до того, как мы столкнулись с этими проблемами, я всегда считал часть транзакции, связанную с подписью, слишком сложной и нелогичной. Если бы биткойн-транзакция была подписана, как в любой другой криптографической системе, подпись не была бы частью ввода.
Это может выглядеть примерно так
tx header
input(s)
output(s)
signature(s)
Заголовок tx, входные данные и выходные данные будут содержать «тело tx». Хэш тела tx — это tx_id.
Чтобы построить транзакцию, клиент должен создать тело tx, вычислить хэш tx. Хэш tx + закрытый ключ для каждого входа будет использоваться для создания подписи. Подписи будут добавлены к телу tx, и все это будет транслироваться как tx-сообщение.
Для проверки удалите подписи из tx, и у вас останется тело tx. Хэшируйте оставшееся «тело» tx, проверьте подпись. Проверьте входы, проверьте выходы. Проверьте правильность каждой из подписей.
Конечно, такое радикальное изменение Биткойна все еще «возможно», но маловероятно, что он когда-либо будет разветвлен для этого. Сатоши многое понял правильно, но он не был идеальным, и это один из примеров.
Кермит