Quote from: natb on November 22, 2013, 05:13:42 PM

Quote from: retep on November 22, 2013, 08:08:04 AM

Yes you are missing something.

The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.

Ahh, of course - I was overcomplicating things in my mind. Thanks for setting me straight. My test harness was making up these previous hashes for the purpose of tx signature testing, so I mentally wrote them off as arbitrary.

If my device is presented with the previous transactions for addresses A, B, and C (which include their total value) I can simply SHA256 these, make sure the hashes in the outpoint structures for the tx I'm going to sign match, and then I know the total alleged value for A, B, C and can present outputs and fees to the user. As you said before, the worst thing the SW feeding me stuff to sign can do is make me create a bogus transaction that will be rejected by the network. A bit of a hassle, but at least its just doing a streaming calculation of a SHA256 (not ECDSA thank goodness!) and no blockchain data is necessary. I feel alot better now, back to making progress

However, life as a HW wallet designer would still be much better with the proposed addition.

For reference, BIP 10 is what I use in Armory to do the same thing. It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB. It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon. I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol...

Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values. Can the payment protocol handle it?