Похоже, что нестандартные транзакции обычно не ретранслируются, потому что есть опасения, что это может привести к поломке сети или затруднить будущие обновления.
Но любой может использовать эти нестандартные транзакции (и ретранслировать их!) с помощью P2SH. Итак, что хорошего в этом ограничении для скриптов, отличных от P2SH?
Как вы говорите, здесь есть две отдельные проблемы:
На случай нанесения вреда сети нестандартная проверка транзакций была впервые реализована Накамото еще до появления P2SH, поэтому ее нельзя было так просто обойти. Это дало разработчикам время для лучшего анализа языка сценариев и устранения проблем с оставшимися кодами операций (например, посмотрите подобные случаи, когда можно было создавать транзакции, проверка которых занимала бы очень много времени).
Однако, даже если язык сценариев совершенно безопасен, каждый сценарий должен храниться каждым полным узлом до тех пор, пока он не будет израсходован как часть базы данных Unspent Transaction Output (UTXO). Поскольку scriptPubKeys ограничены 10 000 байт, это означает, что злоумышленник может добавить до 10 КБ к набору UTXO для каждого создаваемого им вывода, потенциально быстро добавляя достаточно данных для снижения производительности, достаточного для увеличения скорости добычи устаревших блоков (сиротских блоков). что уменьшит прибыль майнеров и побудит их к дальнейшей централизации, чтобы возместить упущенный доход.
Это было бы плохо. К счастью, есть простое решение: если мы используем P2SH или segwit P2WSH, мы видим полный сценарий только в тот момент, когда выходные данные тратятся — когда мы можем удалить выходные данные из набора UTXO. Это несколько уступает P2SH из-за того, что он ограничивает сценарии до 520 байт, но P2WSH устраняет эту проблему и восстанавливает прежнее ограничение в 10 000 байт. Так что это причина безопасности, почему сегодня мы требуем, чтобы сложные сценарии использовали P2SH.
Что касается случая обновления, есть некоторые коды операций, которые мы не хотим, чтобы люди использовали. В первую очередь это коды операций, которые могут быть переопределены в будущем, например, коды операций OP_NOPx, которые использовались для софт-форков в прошлом (OP_NOP1 стал OP_CHECKLOCKTIMEVERIFY, а OP_NOP2 стал OP_CHECKSEQUENCEVERIFY). В последнее время Bitcoin Core 0.16.1 остановил передачу OP_CODESEPARATOR в не-SegWit в рамках подготовки к еще одному потенциальному софт-форку, который уменьшит некоторые затянувшиеся проблемы с дорогостоящей проверкой.
В этих случаях стандартные транзакции запрещают как версии scriptPubKey, так и версии redeemScript (P2SH) (и, когда это применимо, версию SegWit P2WSH), поэтому в этом случае простой обходной путь невозможен.