16: сбой обязательного флага проверки сценария (неканоническая подпись DER) (код -26)

Я пытаюсь отправить транзакцию через sendrawtransactionконсоль bitcoind.

Sigявляется:

30440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D995A0351ECC3

bitcoindответ:

16: сбой обязательного флага проверки сценария (неканоническая подпись DER) (код -26)

Кто знает почему?

TX необработанный:

0100000001 A 000000008A4730440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104 B FFFFFFFF01 C 1976A914 D 88AC0000000001000000

A= 32 байта TXhash транзакции "от"

B= 64 байта моего открытого ключа

C= 8-байтовое значение BTC, которое я пытаюсь отправить

D= 20 байт адреса "to"

Не могли бы вы опубликовать полный шестнадцатеричный код вашей транзакции, чтобы я мог попробовать сам?
Я получаю ошибку -22, когда пытаюсь это сделать - как с ABCD, так и без него.

Ответы (2)

Эта ошибка означает, что ваша подпись не прошла некоторые проверки работоспособности, предназначенные для предотвращения случайных разветвлений сети из-за нестандартных, но все еще действительных кодировок подписи. Эта функция в интерпретаторе сценариев выполняет фактическую проверку.

Однако я взглянул на вашу подпись и не нашел в ней ничего плохого (смотрю вручную, а не запускаю код). Возможно ли, что предыдущий байт неверен, поэтому подпись не полностью помещается в стек?

РЕДАКТИРОВАТЬ :

На самом деле я запустил алгоритм проверки вашей подписи. Код, который я использовал, находится здесь . Подпись проходит проверку DERНа самом деле в самой подписи нет ничего плохого. Как вы его сгенерировали и как выглядит остальная часть транзакции?

Выглядит хорошо. Вы пытались отправить транзакцию, возвращенную в hexатрибуте ответа, или пытались скопировать и вставить resultатрибут в сценарий подписи транзакции? Первый метод работает, а второй дает неверные результаты. Кроме того, был ли completeатрибут установлен в ответе как true? В противном случае транзакция нуждается в большем количестве подписей, чтобы быть действительной (хотя недостаточное количество подписей в мультиподписи приведет к ошибке, отличной от ошибки проверки работоспособности DER).
Я спрашиваю вас, какова остальная часть сделки. Короткий ответ: сама подпись правильно отформатирована и проходит все проверки. Длинный ответ заключается в том, что если транзакция отформатирована неправильно, в OP_CHECKSIG могло быть передано что-то, отличное от приведенной выше подписи, и, конечно, что-то, что не является подписью, не сможет быть проанализировано, даже если где-то еще в пределах транзакции есть действительная подпись. сделка.
большое спасибо за ответ! Но я так и не понял, где прячется ошибка.
Я также получаю: 2019-06-14T01:16:35Z ERROR: ConnectBlock(): CheckInputs on c2de0a7014853898bde9319cb347225d4ee6cef9025dc56773b0b57010060d48 failed with non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element) (code 64)* до этого узел работал * после, постоянные сбои 2019-06-14T01:16:54Z ОШИБКА: AcceptBlockHeader: блок 0000000000000000000104e5800f4ea259c5ab92a18e15320d8879d6c9e09e5b помечен как недействительный

Я трижды подтверждаю, что подпись хорошая, но ваша транзакция плохо закодирована. Мой скрипт дает эту десериализацию

{:ins=>[{:outpoint=>{:hash=>"94f5d2df254de934037a1266923115cb4e7e9300484920024430478a00000000", :index=>"a346f8e8"}, :scriptSig=>"B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104FFFFFFFF011976A91488AC0000000001000000", :sequence=>""}], :outs=> [], :версия=>"00000001", :locktime=>""}

Что не имеет смысла. Даже предыдущий идентификатор транзакции неверен. Он должен быть с маленьким порядком байтов. И версия транзакции должна быть 1, или, когда вы кодируете ее в 8 байтах с прямым порядком байтов, 010000000.

16: сбой обязательного флага проверки сценария (неканоническая подпись DER) (код -26)
СпросиСетьПолитика конфиденциальности1y, 0v