Hardware Wallet: Trezor Support

[prusnak]

Wasabi wallet is a very good step towards Bitcoin fungibility/privacy. However, without hardware wallets support this makes people again vulnerable against coin-stealing malware. Let's add Trezor support to Wasabi!

There is already a library for interacting with Trezor:

• https://www.nuget.org/packages/Trezor.Net/
• https://github.com/MelbourneDeveloper/Trezor.Net

Reach me via email (stick@satoshilabs.com - put your postal address + phone number there) if you are a Wasabi developer and you want Trezor devices for testing.

[nopara73]

There's a recent discussion on Twitter right now about hardware wallets and coinjoins.
This also applies to P2EndPoint server receiver scheme, not only coinjoins.

The root of the issue is that coinjoins must be signed when the user is AFK. Thus in order to start working on it, a special setting is needed that let the user configure something like:

• Automatically Sign all the transactions, if
  • 99% of the coin comes back to one of our addresses.
  • rate limit to 5 times a day,
  • feerate is lower than 2 sat/b
  • etc...

It'd take some time to figure out what are these exact setting those would make sense to add. Nevertheless without autosign, timely coinjoins are not possible.

[JuniperTonic]

I agree it would be difficult to implement hardware wallet CJ operations in the current state. The whole point of hardware wallets is to have the user manually sign the transactions and only the signed transaction ever leaves the device. If the user is AFK and doesn't sign the transaction they would be dropped from the CJ and possibly banned for some hours.
Instead of rehashing already known information, here are some possible alternatives...

• Add functionality to import external addresses to Wasabi (watch only w/label?)
• Ability to send dequeued CJ coins (After a certain anonymity threshold is reached) to certain "labels"
• Link the watch only address to the CJ dequeue "label", allowing final CJ to go directly to your hardware wallet.

Some things to watch out for/ concerns:

• Output address would have to be a segwit address so your transaction matches the rest of the CJ addresses
• Removing coins from Wasabi wallet could lower liquidity for everyone else trying to run multiple joins
• Adding old "watch only" addresses could break Wasabi's functionality because it scans new incoming blocks for transactions instead of re-scanning the blockchain for an address. Possible information leak here.

[JuniperTonic]

I took a stab at implementing the Melbourne/Trezor.net code but I am having trouble due to the lack of documentation. After searching the Trezor site I found the Low-level HID API that may be useful for anyone that wants to look into this. I am not a very strong c# coder so its gonna take me a while to hack through it all.
Trezor API's, Low level API

[dpc]

@prusnak I think this requirement is going to happen more and more often - people will want hardware wallets to sign stuff automatically, just like @nopara73 mentioned

How about Trezor added a functionality, that one would be able to specifiy "trusted" xpubs etc. just like some banks allow skipping 2FA when sending money to known and trusted recipients. User would sign some form of a document that would make Trezor auto-sign transactions when the transactions submitted for signing comes with a documented like that.

Ideally, some form of a predicate-based language would be accepted to allow user to specify arbitrary rules, but that's complicated and huge surface for bugs, so right now Trezor could start with something of a form:

from_account: HD Path
to_account: HD Path
max_total_fee: Number
max_fee_per_sat: Number
min_ratio: 0.00-100.00%
min_locktime: Height
max_locktime: Height

after user confirms and signs a document like that with the Trezor, Wallets like Wasabi could be left online with Trezor attached, and coinjoin coins from from_account to to_account, and Trezor would auto-sign all txes that have a ratio of funds from from_account to to_account at least that many percent, and fees not higher than specified. locktime would be more of a help for the user to limit the duration of a trust, as I don't believe it can be fully enforced. Even if the computer would be compromised, the worst thing that the attacker could do is to prevent the tumbling, wasting some fees and and maybe stealing "100.00%-min_ratio" of the funds (where min_ratio should be very tiny, mostly to cover the coinjoin fee or something of that sort).

I am not sure if all of this is enough to be compatible with the way wallets like Wasabi do CoinJoin, but I just wanted to point to the general mechanism: sign something with Trezor beforehand, that allows Wasabi to coinjoin when the users is AFK, as long as the Trezor is still attached. Maybe not a perfect, but good-enough for many people and use-cases, I believe.

[prusnak]

@dpc what is the point of Coinjoin if you can derive recipients via a simple XPUB?

[dpc]

@prusnak I might be wrong about something here, but I though coinjoin builds a n-inputs m-outputs tx where one of inputs is mine from my from_account and one output is mine to my to-account. Something that Trezor could check against a signed document. If multiple txs are involved or is something else entirely than tough luck.

[prusnak]

@dpc I understand what you meant now, the xpub part confused me.

@nopara73 You mentioned "rate limit to 5 times a day" - is this hardcoded in CJ protocol? Or this is just an arbitrary setting mentioned as an example?

[dpc]

@nopara73 rate limiting would require Trezor remember stuff which is undesirable, imo, and I don't think it is really required. All we want is user be able to automatically tumble stuff from account a to b, without risking someone send them elsewhere, no? I don't think rate limit buys much if anything.

[nopara73]

You mentioned "rate limit to 5 times a day" - is this hardcoded in CJ protocol? Or this is just an arbitrary setting mentioned as an example?

It wasn't arbitrary. Rounds were progressing about 5 a day back then. However, today it's more like 1-15. It can grow to many, our anonymity set and denomination can change, even worse, we're planning change the system to unequal mixing at some point in the future.

On the bright side, I think the rate limit should be set by you what you consider reasonable on your side and Wasabi should work with that limitation in mind.

rate limiting would require Trezor remember stuff which is undesirable

There are a bunch of undesirable stuff about coinjoins in a hardware wallet, that's why I am afraid the whole scheme doesn't even make sense in the first place.
Why rate limit is necessary is that otherwise someone who acquires a trezor could just empty it out by calling autosign many times, which defeats the purpose of a hardware wallet.
The point of rate limiting is to not be able to do that within a timeframe that the user recognizes his trezor is lost and uses its mnemonics. Unfortunately some balance sucking is unavoidable, so I'm really not sure what to do about it.

There are two approaches. Generic autosign and Wasabi specific autosign. Generic autosign may be quite hard to implement in a secure way, however Wasabi specific autosign could go a longer way, since that could check the exact format and requirements of the coinjoins.

But for that we need to wait until our coinjoins are set in stone. Maybe we should just implement partial hardware wallet integration after all. We have a good wallet management system. So a user could setup two wallets:

1. Hardware wallet capable - no coinjoin
2. Coinjoin capable - no hardware wallet

I'm not happy about this, but if a generic autosign is just insecure no matter how it's implemented, then there's no good solution here.

[dpc]

Why rate limit is necessary is that otherwise someone who acquires a trezor could just empty it out by calling autosign many times, which defeats the purpose of a hardware wallet.

Do you mean "empty it out" by making user continuously pay fees etc.? At very least there is less motivation for the attacker to even try, if it doesn't make them any money.

Another problem with rate-limiting is that I don't think Trezor has any idea what time it is (I'm not sure about it, but I think that's the csase), and has to rely on what host would tell it, which can be gamed by an attacker.

Maybe instead of rate-limiting, we could have a counter on how many times given certificate could be used. This way trezor would have to keep maybe a digest + counter per pre-signed certificate, with some fixed number of outstanding certificates issues like this.

[nopara73]

Do you mean "empty it out" by making user continuously pay fees etc.? At very least there is less motivation for the attacker to even try, if it doesn't make them any money.

There are coinjoin coordinator fees, too, so there's no incentive misalignment here.

Maybe instead of rate-limiting, we could have a counter on how many times given certificate could be used. This way trezor would have to keep maybe a digest + counter per pre-signed certificate, with some fixed number of outstanding certificates issues like this.

Sounds like a good idea.