[ESHOP launched] Trezor: Bitcoin hardware wallet

[slush]

But maybe we find some algorithm how to do signing in some streaming way so the device won't need to have everything loaded into the memory at a time...

I think that we just found a solution for unlimited number of inputs and very high limit of outputs. I'll update protocol specification soon...

[someone42]

This is definitely interesting topic to think about. I think the device will have some known hard limit of inputs and outputs, depending on used chip and amount of available RAM. This information can be provided over the API (message Features?), so desktop client will have a chance to handle it properly (offer to split transaction to more smaller ones, for example).

But maybe we find some algorithm how to do signing in some streaming way so the device won't need to have everything loaded into the memory at a time...

FWIW, here's approximately the method I use:
1. Supporting transactions (i.e. transactions whose outputs are being spent) precede the spending transaction in the data stream.
2. Supporting transactions are serialised as they would be in the blockchain.
3. The spending transaction is serialised as it would be in OP_CHECKSIG (with all inputs removed except for the signing input, which has its script replaced).
4. Before each supporting transaction, the output number of the output being spent is explicitly specified.

This allows the bunch of supporting and spending transactions to be parsed by a streaming parser. Each output in the spending transaction can be displayed and approved as it is parsed.

The supporting transactions are there to calculate the transaction fee. The parser does this to calculate the transaction fee:
1. For each supporting transaction, the hash of the transaction, tx_hash, is calculated.
2. For each supporting transaction, the nominated output (from (4) above) has its amount added to the transaction fee.
3. The list of tx_hash and output numbers is itself hashed into ref_hash_compare.
4. When the parser sees the spending transaction, it takes the list of input reference transaction hashes and input reference numbers and hashes them into ref_hash. ref_hash should == ref_hash_compare. This step is necessary to confirm that the correct supporting transactions are being included.
5. For each output in the spending transaction, the output amount is subtracted from the transaction fee.

BIP 0010 is relevant to this discussion. What do you think of BIP 0010? It might be a good idea to talk to etotheipi about it, if you haven't already.

[slush]

3. The spending transaction is serialised as it would be in OP_CHECKSIG (with all inputs removed except for the signing input, which has its script replaced).

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 "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:

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.

[someone42]

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:

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.

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.

[slush]

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.

I know, however I prefer to compile transaction inside the device, instead of parsing that one provided by the client. I see potential security issues while doing this and not having full implementation of  script parser...

[Mushroomized]

got any more pictures 

[slush]

got any more pictures  

Nothing changed on the look yet. We're making progress on the software layer and we're waiting for sample chips from the distributor. On thursday we'll have custom PCB for our evaluation board, so maybe some pictures will appear then ;-).

[chrisrico]

Slush, this is so awesome. Any very rough estimate on when the Raspberry Pi shield will be available? Before or after the standalone device?

[slush]

Slush, this is so awesome. Any very rough estimate on when the Raspberry Pi shield will be available? Before or after the standalone device?

I don't want to promise any date yet, but RPi version will be available before "full" device. We're currently using RPi for prototyping and I hope that RPi shield will help us hardening the software prototype and protocol for final device...

[slush]

I just started discussion about hardware wallet wire protocol: https://bitcointalk.org/index.php?topic=125383.0

Feel free to write your ideas and criticism there. I'm still writing some short description for proposed messages.

[slush]

As I promised, there's picture of the prototype for custom device. Small display, two buttons and micro USB is already here. However we're still waiting for samples from our distributor, which we need for building RPi shield and random number generator for this prototype.

[hazek]

As I promised, there's picture of the prototype for custom device. Small display, two buttons and micro USB is already here. However we're still waiting for samples from our distributor, which we need for building RPi shield and random number generator for this prototype.

Man I can't wait to buy one of these. Any ideas about the price yet?

[slush]

Man I can't wait to buy one of these. Any ideas about the price yet?

I don't like false promises and there're still so many open questions. Price is driven mostly by cost of casing and count of devices built in one round/series. Although we can guess the price of casings pretty soon, we still don't have any estimation for size of the market. Price per device for 100 devices can be many times higher than for 10000 devices...

[beekeeper]

God, lol, dont use lm4f120, I have two which died last week from just a bit of over current on their pins..

[stick]

God, lol, dont use lm4f120, I have two which died last week from just a bit of over current on their pins..

Unfortunately there's no better alternative that I know of at the moment. Were you using plain chip or the Launchpad when you fried your ones?

[beekeeper]

God, lol, dont use lm4f120, I have two which died last week from just a bit of over current on their pins..

Unfortunately there's no better alternative that I know of at the moment. Were you using plain chip or the Launchpad when you fried your ones?

They were controlling my fpgas. Power spiked and there was some over-current. PIC32 controllers surived well. Also, those lm4f120 which were buffered survived. Those two werent buffered, I was betatesting some new firmware. Its probably the design of the IO blocks. They are able to sink only 4mA with two pins on each side able to sink 8mA when most other MCUs can sink more. They also get a bit too hot at 80MHz imo.

[Mushroomized]

As I promised, there's picture of the prototype for custom device. Small display, two buttons and micro USB is already here. However we're still waiting for samples from our distributor, which we need for building RPi shield and random number generator for this prototype.

Oh, not sure if anyone asked, but is there a way to do piglet to piglet transactions? connecting the two devices to each other?

[slush]

We don't plan this, as device itself isn't full bitcoin client and it cannot check transaction validity. For now we're focused more on making secure wallet than on mobile payments.

[marcus_of_augustus]

ok, gonna follow this for real ... I'm a sucker for hardware prototype pics.

Slush:

- what will be level of serial comms allowable with the board? (e.g. stty access via minicom?)

[beekeeper]

ok, gonna follow this for real ... I'm a sucker for hardware prototype pics.

Slush:

- what will be level of serial comms allowable with the board? (e.g. stty access via minicom?)

Stellaris will connect to linux via /dev/ttyACMx in case TI code for serial port is used.