And this is the main problem. You need whole raw transaction in the memory to calculate sha256 for tx_hash. And size of raw tx is growing lineary with number of inputs.
I wasn't very clear on the description of my method, but every hash can be calculated without having any transaction entirely in RAM.I "found" following algorithm:
1. Client sends SignTx message with the list of outputs to the device.
2. Device displays outputs and amounts on the display, waiting for confirmation by the user.
3. Client start sending TxInput messages. For N inputs, client send N^2+N messages, like in this pseudocode:
Thanks to this and thanks to streaming capabilities of SHA256, it is possible to check inputs and build tx_hash without a need to store raw transaction in device memory at all. There's some minor overhead in the API and the API don't looks so nice because it resends TxInputs over and over, but memory footprint is extremely low.
You can go even further than this. If you send the entire serialised spending transaction once for each TxInput, you don't even need to store outputs. You can then have essentially unlimited inputs and outputs. 1. Client sends SignTx message with the list of outputs to the device.
2. Device displays outputs and amounts on the display, waiting for confirmation by the user.
3. Client start sending TxInput messages. For N inputs, client send N^2+N messages, like in this pseudocode:
Code:
inputs = [] # list of TxInput
for i in inputs:
for x in inputs:
send(x) # Sends TxInput to the device
signature = send(SignInput(i)) # Ask for input signature after X inputs
Thanks to this and thanks to streaming capabilities of SHA256, it is possible to check inputs and build tx_hash without a need to store raw transaction in device memory at all. There's some minor overhead in the API and the API don't looks so nice because it resends TxInputs over and over, but memory footprint is extremely low.
