[ESHOP launched] Trezor: Bitcoin hardware wallet

[stick]

So please send them right away. I didn't expect to trust it with larger amount for a few weeks anyway.

What would you do with the hardware if you cannot use it yet?

[michaelmclees]

Why would someone who spent 3 BTC at $100 per want to have their product now, at a point when 1 BTC is $200?  They're trying to preserve value.  They wish to resell it as a strategy to minimize losses on this product that was promised.  If they can resell for 1.5 BTC, they'll break even.  As it appears now, they're losing money nearly every day, assuming you'll later adjust your prices in the future to line up with USD value.

[Polvos]

Do we start asking for a refund or must we wait for the next delay?  

[stick]

As it appears now, they're losing money nearly every day, assuming you'll later adjust your prices in the future to line up with USD value.

You are clearly confusing hardware wallet business with mining business. No one is losing money except us ...

[Transisto]

Haven't been following much, but...

During this year, Either you were planning to mass produce this wallet and acheive per unit cost into 10-20$ range or you don't see the urge for this kind of product!

[Coiner.de]

So please send them right away. I didn't expect to trust it with larger amount for a few weeks anyway.

What would you do with the hardware if you cannot use it yet?

Are you saying the hardware sent to open source developers is completely useless to them?
Can we talk refund then?

A developer version of MultiBit or bitcoin-qt would be enough for me. I don't need online wallets.
You should be glad to get some more testers.


What about my other question?
This starts to look like a communication disaster as it is sadly very common in the bitcoin world.
 

[Mike Hearn]

At the moment I don't believe there are any wallet apps that are usable with the Trezor, so there's no developer version of MultiBit or Bitcoin-Qt that you could run.

Work was being done on extending MultiBit to support it, but currently Jim and Gary are busy with some contract work. I think they plan to resume work on TrezorJ after finishing their current contract.

[weaknesswaran]

Nobody needs a hardware wallet that isn´t bullet proof or unuseable on a daily basis.

After loosing some btc people will realise it would have been better spending 1 btc for a trezor.

Just keep developing - Hardware wallets are the way to mass adoption.

[molecular]

This starts to look like a communication disaster as it is sadly very common in the bitcoin world.

This is extremely far from a disaster... honestly people like you probably know nothing about hardware development should be amazed at what the bitcoin community has a developed and pioneered themselves. So while you call a disaster I look around and say we are in a great age when people have hardware ideas and they create amazing products!

Yes, it is amazing.

Some people just seem to have a thirst for drama.

[michaelmclees]

As it appears now, they're losing money nearly every day, assuming you'll later adjust your prices in the future to line up with USD value.

You are clearly confusing hardware wallet business with mining business. No one is losing money except us ...

No.  Not confused at all.  Let's take an extreme example.  Suppose one orders a 3 BTC Trezor when BTC are $33.33.  They essentially paid $100.  They can do nothing but sit and wait until the product is delivered.  Delivered instantly, assuming your rates are the market rates, the buyer could turn around a sell it again for about 3 BTC.

Now suppose that they wait so long that 3 BTC at the time of delivery is $30,000.  Can the buyer turn around and sell the unit for either 3 BTC or $30,000?  Doubtful on both fronts.  Or are you saying that you'll sell a metal Trezor for no less than 3 BTC for all time, regardless of was MtGox, Bitstamp, and Coinbase have to say about it?

Up to a point in time, the buyer assumes that risk that the BTC value with go up, and the seller assumes the risk that the BTC value will go down.  The point in time is the promised delivery date.  Now that it looks like we're going beyond that date, the tables turn, and the risk bearer ought to be the one who missed the deadline.  In this case, it is the Trezor folks.

[chrisrico]

No.  Not confused at all.  Let's take an extreme example.  Suppose one orders a 3 BTC Trezor when BTC are $33.33.  They essentially paid $100.  They can do nothing but sit and wait until the product is delivered.  Delivered instantly, assuming your rates are the market rates, the buyer could turn around a sell it again for about 3 BTC.

Now suppose that they wait so long that 3 BTC at the time of delivery is $30,000.  Can the buyer turn around and sell the unit for either 3 BTC or $30,000?  Doubtful on both fronts.  Or are you saying that you'll sell a metal Trezor for no less than 3 BTC for all time, regardless of was MtGox, Bitstamp, and Coinbase have to say about it?

Up to a point in time, the buyer assumes that risk that the BTC value with go up, and the seller assumes the risk that the BTC value will go down.  The point in time is the promised delivery date.  Now that it looks like we're going beyond that date, the tables turn, and the risk bearer ought to be the one who missed the deadline.  In this case, it is the Trezor folks.

All of this is moot, as the buyer can easily negate this issue by repurchasing bitcoin after spending on the Trezor.

[stick]

No.  Not confused at all.  Let's take an extreme example.  Suppose one orders a 3 BTC Trezor when BTC are $33.33.  They essentially paid $100.  They can do nothing but sit and wait until the product is delivered.  Delivered instantly, assuming your rates are the market rates, the buyer could turn around a sell it again for about 3 BTC.

Sorry, I cannot shake the feeling that what you are describing is a speculator not a supporter who funded a hardware project in crowd-funding campaign.

[michaelmclees]

Sorry, I cannot shake the feeling that what you are describing is a speculator not a supporter who funded a hardware project in crowd-funding campaign.

Perhaps I'm not making myself clear.  In any event ... good luck.  I hope you don't run into any more delays, as these devices are essential to the Bitcoin world.

[drazvan]

This might have been answered before (if it has, I couldn't find it): can the Trezor help in the case of malware that simply modifies the destination Bitcoin address (for instance when you browse to an online shop, it silently changes the Bitcoin address that you're supposed to send funds to to one that it generates). The user then visually checks that the address displayed by the Trezor is the one that he sees on the website but he has no idea that the address belongs to the attacker.

I understand how the Trezor protects against malware trying to modify the address you're paying to by displaying it on the Trezor itself before signing, but I don't see how it can protect against the malware simply modifying the address shown on the web page. Also, given that receiving addresses are supposed to be one-shot, they will change on each payment so the user has no chance of whitelisting or visually recognizing the correct one.

A rogue Chrome extension for instance could just do a quick find/replace on the page (Bitcoin addresses are easily identifiable, not many words start with 1 and are 27-34 characters long ) and change all Bitcoin addresses to the ones of the attacker. If anyone is interested, I could probably write one as a proof of concept.

Any ideas?

[chrisrico]

The Trezor alone can't protect against that attack, but the payment protocol can, and the Trezor already speaks the payment protocol, or an implementation is in the works. Can't remember which.

[600watt]

watching...

[drazvan]

What would happen to merchants that do not speak/use the payment protocol? If the Trezor is set to a "safe mode" and only accepts addresses that are verified using their associated X.509 certificates, it would be unable to pay merchants that do not use it. If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.

But I guess users will ask the merchants to support the payment protocol in order to feel safe buying there.

[caveden]

If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.

Hey, that's an interesting question, not really related to Trezor but to the payment protocol itself.

If you request a https page and receive a http one, your browser can clearly detect something's not right.

But how does that work with PaymentRequests? AFAIK they're pushed by the payee, not requested by the payer, right? What if a malware sees that an authenticated payment request is passing by, and simply replace it by an non-authenticated one? If you know the merchant is supposed to send you an authenticated payment request, you'll realize there's something wrong. But can we really expect people to understand this?

[marcus_of_augustus]

If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.

Hey, that's an interesting question, not really related to Trezor but to the payment protocol itself.

If you request a https page and receive a http one, your browser can clearly detect something's not right.

But how does that work with PaymentRequests? AFAIK they're pushed by the payee, not requested by the payer, right? What if a malware sees that an authenticated payment request is passing buy, and simply replace it by an non-authenticated one? If you know the merchant is supposed to send you an authenticated payment request, you'll realize there's something wrong. But can we really expect people to understand this?

... don't dig too far down with this kind thinking, it's turtles all the way and then there is .... yes CA's

[btc_uzr]

If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.

Hey, that's an interesting question, not really related to Trezor but to the payment protocol itself.

If you request a https page and receive a http one, your browser can clearly detect something's not right.

But how does that work with PaymentRequests? AFAIK they're pushed by the payee, not requested by the payer, right? What if a malware sees that an authenticated payment request is passing buy, and simply replace it by an non-authenticated one? If you know the merchant is supposed to send you an authenticated payment request, you'll realize there's something wrong. But can we really expect people to understand this?

... don't dig too far down with this kind thinking, it's turtles all the way and then there is .... yes CA's

CA's don't help at all, even if they want you make believe it, but indeed it's a lie proven to be wrong..
(nevertheless the myth of protection through SSL CAs remains alive)

Feb' 13

(...)
Well, we just spotted a new malware sample (Brazilian banking/password stealer) which happens to be signed with a real and valid digital certificate issued by DigiCert
(...)

Misusing Digital Certificates

In the recent years, the PKI environment within which digital certificates are created, maintained and used began showing its weaknesses. We’ve witnessed several ways in which the certs have been misused in attacks on individuals, enterprises and government organizations:

    Stolen code-signing certificates and the associated private keys were used to sign malicious software. For instance, a breach at the security firm Bit9 allowed attackers to steal one of the company’s certs and use it to distribute malware. An apparently-stolen cert was used to sign a malicious Java applet. An attack on the browser company Opera allowed the intruder to access a code-signing cert and use it to sign malware. Code-signing certs stolen from Adobe were used to sign malicious software. It’s not uncommon for malware to be programmed to capture victims’ code-signing and other certificates, which will ensure that we’ll see more incidents of stolen certificates being misused.

    CAs issued weak or improper certificates, which were later used in attacks. For example, DigiCert mistakenly sold a certificate to a company that didn’t actually exist; the cert was used to sign a malicious executable. Another CA named Digicert Sdn (no relation to DigiCert), issued certs with weak “512-bit RSA keys and missing certificate extensions,” according to its parent company Entrust. Later, two of the certs “were used to sign malware used in a spear phishing attack against another Asian certificate authority.” In another blunder, a CA named TURKTRUST mistakenly issued certs that have led to the impersonation of Google’s servers.

    Man-in-the-middle (MITM) attacks abused certificates to intercept SSL/TLS traffic. Software rarely complains when a server’s SSL/TLS certificate has been signed by a trusted, but unexpected CA. For example, one person noticed that when connecting to Gmail via IMAP/SSL from a hotel, the server’s certificate was signed by an entity other than Google. A similar technique was allegedly used by Nokia, presumably for legitimate purposes, to decrypt phones’ HTTPS activities. There are probably many MITM instances where the traffic was captured illegitimately; unfortunately, such situations are often hard to detect.

    Malware installed illegitimate certificates, configuring infected systems to trust them. For instance, a malicious Browser Helper Object (BHO) installed a fake Verisign cert as a Trusted Root Certificate Authority after infecting the system to eliminate security warnings. In another example, spyware acted as a local proxy for SSL/TLS traffic and installed a rogue certificate to conceal this behavior. Installing a fake root CA certificate on the compromised system can also assist with phishing scams, because they allow the attacker to set up a fake domain that uses SSL/TLS and passes certificate validation steps.

These were just some examples of real-world incidents where digital certificates were misused. In a follow-up post, I discuss the initiatives aimed at strengthening the PKI ecosystem within which the certificates are issued, validated and utilized. Read on.

and there is a lot of router harware able to incept SSL btw, so Man-in-the-middle -like it's mentioned above in the hotel example when connection to gmail- is not unusual but quite common