Quote from: genjix on November 22, 2013, 01:54:31 AM

The script subsystem only requires the tx you are signing.

The point is more succinct - avoid extending the Bitcoin standard.

I would also like a SIGHASH flag where you can specify a specific output to sign (so you can specify change address with pledges for SIGHASH_ANYONECANPAY), but I don't think it's a good idea to change Bitcoin's current design. More dependencies and execution paths = poor design = insecure code. We should be taking things out, not putting in.

When a signing device is presented a tx to sign, unfortunately it requires much more than the tx itself to give the end user an indication of how much is being proposed to send. Only the outputs are known with 100% certainty. The device must also know with 100% confidence the value of the inputs so the fees can be calculated. This in turn creates way more dependencies and code paths for a HW signing device.

Anyway, I'm now genuinely curious on how the Trezor is solving this problem. Etothepi, you mentioned they ran into it, and I presume they have attempted to solve it. Assuming that the software driving the HW wallet is not trusted (which is the cornerstone assumption of a good offline HW wallet design), I don't see how the device can pull this off without having a good deal of the blockchain present including some of it pre-programmed in the device at manufacturing. Maybe I'm missing some technique here, I'm all ears.