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.
Topic: [PROPOSAL] Give proof of identity to your customers - page 2. (Read 4103 times)
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://bitcointalksearch.org/topic/ecdsa-signatures-allow-recovery-of-the-public-key-6430)
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://bitcointalksearch.org/topic/ecdsa-signatures-allow-recovery-of-the-public-key-6430)
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:
in this example the payment address is 15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777 and the authentication address is 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
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:HHMNlNJYbc6ppJ1UUT1PMXuHdG2e54RZNh3vamrSpDfh442jOwb+JHyfSQNRhQt0dB0uf8kJxNbO4lA95byKhx4=
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
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.
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.
watching ...
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.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.
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.
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.
That's clever. I like the idea. I would use it.
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 BTC to address ", 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.
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
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.
Jump to: