Electrum is a lightweight client written in Python. The design is an improvement over Bitcoin-Qt because the user interface and core code are split into a client and a server. This means you can run an Electrum server instance, and use the same bitcoin from a wide variety of devices. Server instances are analogous to email servers, and the Electrum client with email clients.
Version 0.38 brings two new features. Aliases and signed URIs.
Aliases are dynamic pointers to Bitcoin addresses. They may be signed by a trusted authority, or self-signed. Think of sending your bitcoins to foo@genjix.net instead of 1hard1to1remember1code.
Signed URIs are URIs that are signed by a merchant, with an address that is linked to the reputation of the merchant. The goal is to provide a proof of purchase for consumers. When you click a link on a website to pay bitcoins, it will add a funny code which you can use as a receipt for proof of purchase.
See here for a complete description of aliases and signed URIs. It is possible to combine both: merchants may have their main address signed by a trusted authority, and use that address in order to sign the URIs they give to their customers.
Many scamming opportunities arise from bitcoin URI concept. The risk here is to create a totally false sense of security. URIs that are not signed are completely useless as there is no verifiable association between any of the URI parts (address, message, amount).
The following is completely obvious lest we invite the scammers,
- Merchants need to have proof of their identity (public key of sort)
- Each purchase should provide a corresponding invoice, stating the usual (whom, what, when, amount etc) and the bitcoin address, and it must be SIGNED by the the merchant. The proposed signed URI could provide all this.
- Unsigned aliases are just for scammers.
- Signed aliases are not useful for merchants as they need to provide invoice anyway. They are useful for donations however but the protocol should state that the returned address should only be used once.
In short, unsigned URI are worse than not having them. Signed URIs should be great, so one problem remains, to agree on some authority to trust for proof of identity.
URIs … is not to protect merchants against attackers, but to protect customers against malicious merchants pretending they have not been paid.
dixit: “to agree on /some authority/ to trust for proof of identity”
I prefer the circles of confidence-p2p.
@genjix: A) What are the main strengths and weaknesses and comparisons between Multibit and Electrum? B) What relationship exists between Electrum and Mtgox?
::-|
“URIs … is not to protect merchants against attackers, but to protect customers against malicious merchants pretending they have not been paid.”
Exactly, so they *must* be signed so the customer can verify the identity of the merchant. Signing could be done with Web Certs, PGP, Namecoin, etc.
Bitcoin URIs are simply a way of saying “please pay XXX to address YYY” in structured data, nothing more. They were never supposed to add extra security.
That’s why unsigned URIs add superfluous nonsense which in the use of the average internet user adds serious insecurity. It brings up the bitcoin app and purports that a payment can be associated with a receiver, message or other extra information which it cannot (unless the whole message is signed).
A few attack scenarios for unsigned URIs:
- Somebody buys some article online. The payment address is displayed
in the browser. He sends his money there. But in the browser, a
ZEUS-like financial malware is running which has altered the real
URI to the one of the attacker. Such malwere is already deployed to
rob users of online banking.
- A client gets a payment receipt by unsigned e-mail. However some
criminals have altered the mail transfer agent software of his e-mail provider so that all bitcoin payment addresses processed by the
provider are changed to numerous addresses that belong to them.
- A programmer sets up a webshop system for a merchant. The system displays the URI and the client sends money there. However, the
programmer has introduced an underhanded function which replaces the
URIs with one of his own – first very rarely, then with increasing frequency.
In all this cases, the client can say and possibly prove that he
send money to the given address. But, he can never confirm that this address does not belong to him. To the vendor, it will look like he simply did not pay.
To the customer, it will look like he lies about receipt of payment.
In other words: unverified payment URIs can raise mayor trust issues.