Невозможно правильно подписать «холодную» подпись, а затем отправить биткойны, используя разделение «холодный / онлайн» узел - PullRequest
0 голосов
/ 27 июня 2018

это один из моих первых постов в стеке, так что простите, если я что-то не так делаю. то, что я пытаюсь сделать, это добиться правильной холодной подписи транзакции биткойн через RPC. Я застрял на последнем шаге с «64: необязательный-script-verify-flag (подпись должна быть нулевой для неудачной операции CHECK (MULTI) SIG)» и не может продолжаться дальше.

Архитектура, с которой я работаю:

  • Один полный узел BTC (ядро v0.16.1), который доступен только в локальной сети. Этот узел имеет полные данные кошелька, включая закрытые ключи, но не имеет блокчейна и не выполняет никаких действий P2P. Это мой автономный узел.
  • Один полный узел BTC (core v0.16.1), который имеет общедоступный порт P2P, синхронизируется с сетью биткойнов и имеет доступный только для чтения кошелек. Это мой онлайн-узел.

Что я хочу сделать, так это использовать сетевой узел для создания необработанной транзакции, затем переслать его в автономный узел для подписи, а затем передать в сеть с помощью онлайн-узла. К сожалению, я не могу этого сделать. Все взаимодействия с узлами осуществляются через RPC.

Что я делаю:

Создать новый адрес в автономном узле:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getnewaddress",
    "params": []
}

Импортировать этот вновь созданный адрес как доступный только для наблюдения на онлайн-узел:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "importaddress",
    "params": ["address","",false]
}

Затем я отправляю несколько BTC на этот адрес и жду подтверждения. Я проверяю данные UTXO на онлайн-узле, используя:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "listunspent",
    "params": [3]
}

В результате этого вызова я нахожу вывод из транзакции, которую я ранее отправил. Я копирую txid, vout, scriptPubKey соответствующего UTXO и продолжаю создавать необработанную транзакцию еще на онлайн-узле. Предположим, что мой UTXO имеет txid ABC, vout 0 и сумму 0,002.

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "createrawtransaction",
    "params": [
        [
            {"txid":"ABC","vout": 0}    
        ],
        {
            "someChangeAddress": "0.0005",
            "someOtherAddress": "0.001"   
        }
    ]
}

Это транзакция, которую я создаю, чтобы отправить 0,001 BTC на someOtherAdress, заплатив за нее 0,0005 BTC и отправив оставшиеся 0,0005 BTC на someChangeAddress. Этот вызов возвращает мне действительную транзакцию hex. Я пропускаю fundrawtransaction, так как мне не нужна автоматическая оценка комиссии, а затем я пытаюсь отправить эту необработанную транзакцию на автономный узел для подписания:

 {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "signrawtransaction",
    "params": [
        "transHex",
        [
            {"txid":"ABC","vout":0,"scriptPubKey":"utxoPubKey" }    
        ]
    ]
 }

Это еще раз возвращает мне транзакцию hex, поле complete в возвращенном JSON установлено в true, поэтому оно должно быть готово к трансляции. Я беру возвращенный гекс и пытаюсь отправить его через онлайн-узел:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendrawtransaction",
    "params": [
        "signedTransHex"
    ]
}

Я ожидаю, что в этот момент вернется txid, который я смогу наблюдать, но я получаю:

{
    "result":null,
    "error":{
        "code":-26,
        "message":"64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)"
    },
    "id":1
}

Что я делаю не так? Связана ли проблема с адресом, который UTXO я использую для наблюдения только на узле oneline? Но это не должно иметь значения, так как я в любом случае подписываю это на холодном кошельке. Как я могу заставить это работать?

1 Ответ

0 голосов
/ 27 июня 2018

Мне удалось найти проблему и устранить ее. Ответ на мои проблемы заключается в том, что начиная с версии v0.16 сумма должна быть передана с соответствующими UTXO в команду signrawtransaction. Это было отправлено как ошибка в https://github.com/bitcoin/bitcoin/issues/12429.

...