Bitcoin Forum
December 08, 2016, 04:18:04 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: [PROPOSAL] Give proof of identity to your customers  (Read 3732 times)
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
January 13, 2012, 09:51:25 AM
 #1

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.

Electrum: the convenience of a web wallet, without the risks
1481213884
Hero Member
*
Offline Offline

Posts: 1481213884

View Profile Personal Message (Offline)

Ignore
1481213884
Reply with quote  #2

1481213884
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Revalin
Hero Member
*****
Offline Offline

Activity: 728


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
January 13, 2012, 08:58:27 PM
 #2

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

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
January 14, 2012, 11:37:52 AM
 #3

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.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
January 14, 2012, 11:40:34 AM
 #4

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
January 14, 2012, 12:12:08 PM
 #5

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...

Electrum: the convenience of a web wallet, without the risks
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
January 14, 2012, 12:37:55 PM
 #6

watching ...

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
January 14, 2012, 01:04:04 PM
 #7

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.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
January 14, 2012, 01:18:42 PM
 #8

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

Electrum: the convenience of a web wallet, without the risks
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
January 16, 2012, 11:13:45 AM
 #9

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)


Electrum: the convenience of a web wallet, without the risks
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
January 16, 2012, 02:11:55 PM
 #10

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.


MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 16, 2012, 02:25:25 PM
 #11

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 16, 2012, 04:49:34 PM
 #12

+ 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...  Wink
(you should see where I'm going with this)

ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
January 16, 2012, 06:06:51 PM
 #13

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.

Electrum: the convenience of a web wallet, without the risks
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
January 16, 2012, 07:01:52 PM
 #14

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

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

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
hex
Jr. Member
*
Offline Offline

Activity: 43



View Profile WWW
January 17, 2012, 12:37:42 AM
 #15

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

http://www.bitcoin.rs - Balkan ex.yu BitCoin community!
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 17, 2012, 01:24:05 AM
 #16

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
Hero Member
*****
Offline Offline

Activity: 756


Bitcoin Mayor of Las Vegas


View Profile WWW
January 17, 2012, 03:57:34 AM
 #17

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.

Generation Bitcoin | G+ | FB | Bitcoins In Vegas | CoinBus.com | TOR Exit Operator 1MVTPATVCKBMfALRHJsXpHfKJu7GyL7nAc
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 17, 2012, 04:03:30 AM
 #18

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
Hero Member
*****
Offline Offline

Activity: 756


Bitcoin Mayor of Las Vegas


View Profile WWW
January 17, 2012, 04:12:10 AM
 #19

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?

Generation Bitcoin | G+ | FB | Bitcoins In Vegas | CoinBus.com | TOR Exit Operator 1MVTPATVCKBMfALRHJsXpHfKJu7GyL7nAc
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 17, 2012, 04:14:36 AM
 #20

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!