Quote from: cellard on February 17, 2018, 03:50:20 PM

Quote from: pebwindkraft on February 16, 2018, 06:07:16 PM

I thought it is possible to assemble a tx completely on live net, with the watch-only address.
Then youd bring the unsigned tx to the cold storage machine, and sign it. Then bring it back to the online machine, and send it... this would remove the burden of manually playing with the in and outs.

Yeah this would be it. I remember reading someone claiming this was possible in the past but I don't know how the steps would look like.

So let's say I have a node online and synced with all my addresses added as watch-only, then the offline wallet in the airgapped computer (both are Bitcoin Core).

How do I make the transaction in the online node's wallet on the GUI as usual then pass it read on the offline machine to sign it with the offline private keys then back to the online node?

If I do the transaction as usual with the watch-only addresses with the ideal fee and all the inputs I want selected in "Coin Control", I can then do "dumprawtransaction" and then make a QR code of this, read it in the offline wallet, then what do I do with this?

I just want to know step by step to not fuck it up in the process.

I had spent some time with Bitcoin Core 0.16 in offline mode, and didn't get to succeed for different reasons. When looking into cold storage and Bitcoin Core, majority seems to talk about keys being offline. So far so good. When it comes to signing a transaction, that seems to be another issue. I stepped over this thread with a remarkable comment from Pieter:

https://bitcoin.stackexchange.com/questions/50924/new-bitcoin-core-0-13-2-as-cold-storage-wallet

I have meanwhile tried to creat a tx on an online system, transfer it to the cold storage system, and get it signed. I started easy, with a simple P2PKH transaction. When I brought this to the cold storage to sign with bitcoin 0.16.1, the bitcoin-cli signrawtransaction command would reply with missing link to previous transaction:

Quote

bitcoin-cli -regtest signrawtransaction 010000000164518c0612559b8...19cef8f75a8700000000
...
"error": "Input not found or already spent"

when I tried to provide it additional info, I had the same result:

Quote

bitcoin-cli -regtest signrawtransaction 010000000164518c0612559b8...19cef8f75a8700000000 '[{"txid": "'$UTXO_TXID'","vout": '$UTXO_VOUT',"scriptPubKey": "'$UTXO_ScriptPK'"}]' '["'$Src_PrivKey'"]'
...

I was wondering, how the system would check the details. As I am no C/C++ dev, I am not too eager to look into the code... But obviously the client verifies contents, to make sure only "valid" transactions go to the network. This is good user protection, and probably very positive.

I also did some tests with (non-multisig) P2SH and redeemscripts. I created a funding transaction on the live system, and wanted to spend the P2SH. So I had to sign on the cold storage system. Results are also unsuccessful. I tried:

Quote

bitcoin-cli -regtest signrawtransaction 0200000001cbfd553ee1a2018a155263f34b1ea3b25348ba9f063c1d5f92861fc1dd95a9aa00000 00000ffffffff0178b69a3b000000001976a914d7cb7ff474d67cc0763b941db49d26dd8ff6b914 88ac00000000 '''[{"txid": "'$UTXO_TXID'","vout": '$UTXO_VOUT',"scriptPubKey": "'$UTXO_ScriptPK'","redeemScript": "'$RedeemScript'"}]''' '''["'$Src_PrivKey'"]'''
...
"error": "Invalid OP_IF construction"

This INVALID OP_IF error happened to several versions of the created raw transactions and redeemscripts. It seems that bitcoind doesn't have enough info to add the signatures. This doesn't necessarily mean, the tx is invalid (one could manually add the sigs from a different program Wink

). As shown here, I can make a P2SH successful going through (just a hash comparison, without signatures):

https://bitcoin.stackexchange.com/questions/74753/htlc-hash-time-lock-contract-using-bitcoin-qt/74953#74953

From my experience, signing transactions offline with Bitcoin Core is not best way to go. And by this I don't mean to blame the core dev - au contraire! The design seems to go into user protection, and not fulfill dev's ("my") requirements.