14th of April: Getting started

I sent an email to SatoshiLabs yesterday to see if they would be interested in merging the work I'll be doing for Monero support back into their official firmware. Have not yet heard back from them on this front.

I'm also looking for ways to get a Trezor for development. I asked SatoshiLabs if they could send me a used one with a discount. Christoph from Twitter has offered to send me one of his old ones. If none of it pans out I'll just be buying one for full price.

Since it'll be a week or two before I get my hands on a Trezor I'll be starting with the Monero side of things. I will be evaluating the changes I need to make in the wallet code to add support for Trezor powered wallets.

If SatoshiLabs or the guy from twitter aren't able to help you get a trezor in the next week, I will send you mine. It has just been sitting on my desk for a couple months and I'd much rather it be used in a project for Monero than collect dust. Just send me a PM next week here or on BTCT.

"I sent an email to SatoshiLabs yesterday to see if they would be interested in merging the work I'll be doing for Monero support back into their official firmware."

I suppose that if this doesn't happen, the firmware with monero support will be 'unofficial'? If that's the case, will it be able to still store bitcoin private keys (I guess it's the case) although for security reasons it's better to not use unofficial firmware. Therefore people will probably need to buy a separate trezor for XMR storage. I hope trezor just integrates your software, if not, i'll just buy a second one ;)

If the Monero implementation for Trezor will be so radically different that there is no chance of those changes being merged back to official tree, it will probably make more sense to create a Monero only Trezor firmware. I will know if this is the case after I've got my hands on a Trezor and played around with it a bit.

Not to muddy the waters any, but here is another hardware device that could possibly be used. bitbox The hardware device doesn't necessarily have to be a Trezor. Also, according to digitalbox's site, they are altcoin friendly. Not exactly sure what that means, but that may be a positive.

This could be cool too. I don't know enough about proper to security to be able to tell how it compares versus the Trezor, but it would be nice for people to have options assuming they are both safe tools.

Edit- I would even buy one for a dev like roosmaa to look at if needed, or we could start a seperate fund to get the bitbox running

Roosmaa, do you plan to prototype in python first? It might be required to have a chance being integrated by SatoshiLabs.

Background: SatoshiLabs have a emulator for the trezor side and the client side written in python (see here and here). They use it for prototyping and testing, mostly the communication protocol and UI stuff. It can also be run on a RasPi using a special shield.

I suspect that using the emulator will be very useful for longer-term development, even if it might be initially more work that a pure firmware hack.

The emulator is mostly targeted for helping people implement Trezor support in their Bitcoin wallet software. If it's possible to implement Monero support without breaking Trezor communication API, then modifying the emulator to emulate Monero support would be easy. Otherwise it's probably not worth the effort yet. I make no promises either way until I've had a chance to see Trezor in action and analysing all of the functionality it provides to see how might Monero fit into there.

Seems like a reasonable course of action. Let me know how it goes, maybe we can help out.

Problem with devices like Bitbox and Ledger is that they're far less versatile than Trezor due to being very specialised. Lack of screen also is kind of a bummer (I own a Ledger).

Also a big red flag from the Bitbox website: Firmware updates not needed and not possible. So it'll probably work well with all Bitcoin forks, but not with Monero or other coins.

Hey Guys,

Just to let you know : I sent the trezor on friday to roosmaa. Will take a couple of days to arrive there....

21st of April - Trezor on it’s way!

Christoph (rottenchris) has mailed me one of his spare Trezors - thank you very much! I’ll be flying to Estonia for a week tomorrow. Unless the package reaches me today, I won’t be able to play around with it until I’m back.

Progress This Week

I spent the better part of last week getting to know Monero wallet better: how it works behind the scenes, what is the code like, etc.

What I learned is that view key can only be used to detect outputs in a transaction which belong to the account. It cannot be used to detect when said output was spent.

The way simplewallet detects outgoing payments is by generating a key image for each of the transaction outputs belonging to the account and monitors the blockchain for usage of that key image. The only way to generate such key image is to have access to the private spend key.

Having Trezor generate key images for each of those outputs would defeat the purpose of a hardware security module. Having access to those key images means it is possible to spend that output.

See my notes below on outgoing payment detection for more information about this.

To get spend detection working for Monero I need to extend the public Trezor communication protocol with Monero specific features. This will decrease the chance of this work getting merged back upstream into official Trezor firmware.

After I’ve played around with the Trezor I’ll know more or less what kind of changes I need to do in the firmware. If they are fairly extensive, then it will make more sense to have Monero specific alternative firmware for Trezor.

Adding Trezor support directly to simplewallet would unnecessarily complicate usage of that tool and it would definitely not be a simplewallet anymore. I think the best option is to create a separate wallet tool for Trezor, dealing with just payments (no RPC for instance).

To do that I have three options:

1. The easiest would be to copy-paste most of the existing wallet code into a new directory, make changes to add Trezor support and delete code (RPC, etc) that isn’t useful for the new tool. I don’t see such code being merged into Monero upstream nor anybody wanting to maintain this hack in the future. So this option isn’t really an option.
2. The better option would be to refactor the existing wallet code extensively, in a way that would make it to be possible to build a second wallet utility with Trezor support on top it. It would be a fairly big undertaking with a lot of swearing involved and a chance of breaking existing simplewallet functionality.
3. Or implement the Trezor wallet in Go, from scratch. This would probably take slightly more time, but it wouldn’t break any existing functionality nor would it have to be merged upstream. It would also mean in the future there would be solid building blocks for people wanting to build something on top of Monero using Go.

Out of the three options I prefer the last one as it would mean less swearing and more fun. I’ve started prototyping various required functionality (encoding/decoding Monero binary formats, generation & verification of ring signatures) to see if they can be implemented using the Go standard library & existing 3rd party libraries already out there.

Plan for Next Week

I am going to continue prototyping the Go wallet implementation idea. I will also be taking a more in depth look at trezor-mcu source code to get a better idea about how I would approach adding Monero support there.

Notes

Outgoing Payment Detection

View key only allows us to detect incoming payments for the address. So far I haven’t found a way to detect with view key if the key image was generated by the spend key holder.

That means detecting when the user has spent some of their money is tricky. The official wallet uses spend key to generate key images for each of the incoming payments. Then it compares those with all key images in the blockchain to see if it has been spent. If the spend key is not available this is not an option.

Hashed Key Images

To sign a transaction the user needs to interact with Trezor. We could however, implement a new API in Trezor which would output the hash of the key image. This would allow us to hash all seen key images and see if the users output was spent.

Educated Guessing

We could attempt to guess spend transactions. This would involve checking if all of the inputs in a transactions contain at least one of transaction output we know is ours. If there are change outputs we can be 99% certain this was an outgoing transaction.

There is an edge case which is difficult to detect using this approach: single input and single output, no change outputs. There just isn’t enough information to be 100% certain these outputs were spent by the user.

This also breaks bad when the transaction contains funds from several accounts. Thus the hashed key images would be a more foolproof way to monitor this.

Thanks for the update, roosmaa! Did you find a way to handle the spent outputs by now?

2nd of May - Trezor has arrived!

Just a quick update. On the PC side, still working on the prototyping the required functionality in Go.

The Trezor rottenchris sent, has arrived! I’ve tested out compiling the official firmware and installing it with non-SatoshiLab signatures. Minor annoyance with custom firmwares (like the one I’ll be making) is that Trezor prompts the user on every startup if they want to continue with the potentially unsafe firmware.

That’s it for now. Hopefully next time I’ll have a Go prototype which can sign and verify ring signatures and communicate with monerod using binary serialisation formats.

Most likely will go down the route of letting Trezor return a hashed key-image for all the detected spendable outputs. That way the wallet software on PC can detect when the (hashed) key-image was used in the blockchain and mark the output as used.