[PROPOSAL] Give proof of identity to your customers

[ThomasV]

I understand the reason why chargebacks are a bad idea for online commerce.
Bitcoin makes more sense, because it is a system where consumers have to trust the reputation of established sellers, instead of asking sellers to trust random customers.

However, the current system could be improved.
When I place an order, I receive a Bitcoin address from the merchant. At that point, sending my coins to that address remains a leap of faith.

As a buyer, I would feel more comfortable if I had a public proof that I sent coins to that merchant, (not just to an anonymous address), in case of  litigation.

I propose the following:
Instead of simply displaying "Please send <xx> BTC to address <aaa>", the merchant's website should also sign that message with a private key, and give the signature to the customer.
The corresponding public key should be visible on their website. That way, a customer can prove that he actually sent money to the merchant, not just to a random address.

The signed message could also contain the description of the purchased good, and maybe the shipping address of the customer (in that case, customers would lose anonymity if they publish the proof).

Are there online sellers interested in such a solution?
The "signmessage" and "verifymessage" RPC commands of the bitcoin daemon should make this easy. For example, you could use a bitcoin address of your wallet in order to sign messages with it.

[1714663536]

1714663536

[1714663536]

1714663536

[1714663536]

1714663536

[1714663536]

1714663536

[Revalin]

That's clever.  I like the idea.  I would use it.

[jim618]

This is also a good way of stopping various attacks by an attacker substituting their bitcoin address in a bitcoin payment request URI for the merchant's real bitcoin URI.

The bitcoin URI a merchant uses is likely to have a 'one-time' address but by signing it with a private key which has a well known public key it gives it veracity.

Of course the user has to have confidence in the advertised public key of the merchant which is probably best served by a locked down server via SSL.

[kokjo]

Of course the user has to have confidence in the advertised public key of the merchant which is probably best served by a locked down server via SSL.

but then again: you have to trust a SSL provider, Cert. authority.

[ThomasV]

Of course the user has to have confidence in the advertised public key of the merchant which is probably best served by a locked down server via SSL.

but then again: you have to trust a SSL provider, Cert. authority.

indeed, a merchant could sign with a certified SSL public key, but I don't think that this is what jim618 was saying...

[HostFat]

watching ...

[jim618]

The main thing about publicising your public key / address from a locked down SSL server is to to make attacks such as the following more difficult:

Webmaster: this is a great Javascript utility to 'insert something neat here' I will just pop that on my website.
Behind the scenes, utility code swops out real bitcoin payment address for attacker's.

Buyer sees authentic looking bitcoin payment URI with right amount, label etc. The address is one-time so would not be in buyer's address book. Buyer pays happily. Attacker receives bitcoin. Merchant just sees 'no purchase'. Several days later buyer complains to merchant - where's my stuff ? Merchant : What stuff ? You never paid.

You *could* sign with an SSL cert but I think using the bitcoin crypto is better. It is defence in depth. The signed payment request and payment are effectively a key exchange that you could then use for, say, secure chat between the two parties.

[ThomasV]

ideally, the signature should be verified by a browser extension or bitcoin client.
if the message is just a bitcoin address + amount, then perhaps the signature could be integrated to the bitcoin URI scheme. https://en.bitcoin.it/wiki/URI_Scheme

Edit: a straight-forward method would be to sign the unsigned URI.
Example:

Code:

$ bitcoind signmessage 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 "bitcoin:15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777?amount=50&message=how%20are%20you"
HHMNlNJYbc6ppJ1UUT1PMXuHdG2e54RZNh3vamrSpDfh442jOwb+JHyfSQNRhQt0dB0uf8kJxNbO4lA95byKhx4=

which yields the following signed URI:

Code:

bitcoin:15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777?amount=50&message=how%20are%20you&signature=HHMNlNJYbc6ppJ1UUT1PMXuHdG2e54RZNh3vamrSpDfh442jOwb+JHyfSQNRhQt0dB0uf8kJxNbO4lA95byKhx4=

in this example the payment address is 15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777 and the authentication address is 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8

[ThomasV]

I have been thinking about it a bit more.
I believe that URI Scheme is indeed the best way to do this.
I have added URI support to Electrum, similar to what Multibit does. now I need to add a 'verifymessage' capability.

Here is how I think we should implement identity verification:
 - the browser should verify that the Bitcoin address used to sign a bitcoin: URI matches the address provided by the website (i.e. the identity of the merchant).
 - the bitcoin client should verify that the provided signature matches the address and message. it will show a warning if the URI is unsigned.
 - if the user accepts the transaction, the bitcoin client will store the message and the signature in its records, so that the user keeps a proof of identity.
 - I guess the URI should contain the signature AND the bitcoin address corresponding to the signing key. Even though the public key can be recovered from the signature, this is not something that can be done easily by a browser extension

(reference: https://bitcointalk.org/index.php?topic=6430.0)

[jim618]

Hi Thomas,
I like your previous post but think that you will very likely have:
+ the bitcoin address the website is offering to that specific customer / order.
   (unique to customer / session and used by the merchant software to track order)
+ a merchant specific address - the merchant's identity - unchanging.

I think you need both the 'address for this payment' and 'merchant identity address'.
I know in MultiBitMerchant we use one address per potential customer order and never recycle them.

Edit: rereading your post I think you have got this covered. I think you are proposing:
+ have the customer specific address in the bitcoin URI.
+ look up the merchant public address from a 'well known' SSL location on the website.

(a bit like everyone knows where to get the favicon from)

You could then show on the UI 'signed by myWebsiteName.com' - the location of the website you got the public key from.

[DeathAndTaxes]

subscribed.  interesting ideas. 

A system which implements proof of payment and assurance payment is going to the right entity is a great step forward.

[Maged]

+ a merchant specific address - the merchant's identity - unchanging.

But how do you ensure that they don't change it anyway? It's almost as if we need a distributed, timestamped, database system... 
(you should see where I'm going with this)

[ThomasV]

Hi Thomas,
I like your previous post but think that you will very likely have:
+ the bitcoin address the website is offering to that specific customer / order.
   (unique to customer / session and used by the merchant software to track order)
+ a merchant specific address - the merchant's identity - unchanging.

I think you need both the 'address for this payment' and 'merchant identity address'.
I know in MultiBitMerchant we use one address per potential customer order and never recycle them.

Edit: rereading your post I think you have got this covered. I think you are proposing:
+ have the customer specific address in the bitcoin URI.
+ look up the merchant public address from a 'well known' SSL location on the website.

(a bit like everyone knows where to get the favicon from)

You could then show on the UI 'signed by myWebsiteName.com' - the location of the website you got the public key from.

If we sign the URI with a bitcoin address, then the verification will need ecdsa, and it is better to do it with the bitcoin client. Thus, we need to send the merchant's public address to the bitcoin client. The easiest way to do it is to include the merchant's address in the URI, but this means that the browser needs to verify that the URI contains a public address that matches the public address of the website.

Another solution, as you suggest, is to lookup the merchant address from a standard location on the website. But in that case too, we will need to make sure that the bitcoin client gets the correct public address. I assume that the URI is the only information passed to the bitcoin client; this means that the URI would need to contain the hostname of the web server, so that the client can request the public key; and again, we need to verify that the hostname is correct.

This is why I wrote that two things need to be verified: the public address and the signature. It seems that a web browser extension is necessary in order to perform the first verification.

We could also use the ssl public key of the website in order to sign the URI. This might fit better with the existing infrastructure.

[jim618]

@Thomas.  Agreed - both the public address and signature need verification.

@Maged.  I like the hint to a full distributed "blockchain-ey" PKI solution !   :-)

[hex]

I don't get this.
You are trying to verify that bitcoin address on sellers website belogns to seller ?

[DeathAndTaxes]

I don't get this.
You are trying to verify that bitcoin address on sellers website belogns to seller ?

Yes AND provide proof of payment.

[Tuxavant]

Maybe I missed something, but stores still need TLS to transport bitcoin addresses so they cannot be tampered with.

Proof of payment is easy - customer provides a bitcoin address (any) at registration. Merchant presents a receipt (arbitrary string associated with purchase details) at checkout. Customer sends Bitcoins and signs receipt to complete the purchase.

[DeathAndTaxes]

Maybe I missed something, but stores still need TLS to transport bitcoin addresses so they cannot be tampered with.

Proof of payment is easy - customer provides a bitcoin address (any) at registration. Merchant presents a receipt (arbitrary string associated with purchase details) at checkout. Customer sends Bitcoins and signs receipt to complete the purchase.

That proves absolutely nothing.

"Um.  That address isn't mine.  He didn't pay me he likely sent 100 BTC to his friend and is now trying to pull a scam."

Someone signing their own receipt is no proof the counterparty exists.

[Tuxavant]

Maybe I missed something, but stores still need TLS to transport bitcoin addresses so they cannot be tampered with.

Proof of payment is easy - customer provides a bitcoin address (any) at registration. Merchant presents a receipt (arbitrary string associated with purchase details) at checkout. Customer sends Bitcoins and signs receipt to complete the purchase.

That proves absolutely nothing.

"Um.  That address isn't mine.  He didn't pay me he likely sent 100 BTC to his friend and is now trying to pull a scam."

Someone signing their own receipt is no proof the counterparty exists.

Sorry, I didn't quite think that through... When you register, you could be required to pay a small random amount micropayment to register your key with the merchant. From that point, this key would be required to sign a receipt.

How's that?

[DeathAndTaxes]

Maybe I missed something, but stores still need TLS to transport bitcoin addresses so they cannot be tampered with.

Proof of payment is easy - customer provides a bitcoin address (any) at registration. Merchant presents a receipt (arbitrary string associated with purchase details) at checkout. Customer sends Bitcoins and signs receipt to complete the purchase.

That proves absolutely nothing.

"Um.  That address isn't mine.  He didn't pay me he likely sent 100 BTC to his friend and is now trying to pull a scam."

Someone signing their own receipt is no proof the counterparty exists.

Sorry, I didn't quite think that through... When you register, you could be required to pay a small random amount micropayment to register your key with the merchant. From that point, this key would be required to sign a receipt.

How's that?

Doesn't prove anything.

The CUSTOMER can't sign a receipt and PROVE a payment was made to a merchant.

Merchant can say:
a) customer made up receipt
b) customer send money to someone else
c) customer signed his own bogus scam crap

it provides no proof is the CUSTOMER is signing something to prove the MERCHANT got paid.