Topic: [PROPOSAL] Give proof of identity to your customers (Read 4151 times)

I added these features to Electrum.
See the announcement here:
https://bitcointalksearch.org/topic/m.735942

This should be possible with bitcoind 0.5 and Bitcoin-Qt 0.6.

Also a key thing to remember is we want the payment address signed BEFORE payment.  

We want to prove not just a payment was made but it was made to an address controlled by the merchant/payee and (optionally) for what purpose. 

Example:
D&T paid ThomasV 100 BTC on 01/17/2012.  
I wouldn't want to rely on website as for example  http:thomasV.com and https://tho.masV.com are different identities.  While I could save the pages & signatures for https://tho.masV.com it doesn't prove anything other than I got scammed.

Compare that to a system where I can obtain ThomasV public key in advance and import it into my wallet.  I then get a payment URL which is signed by ThomasV private key.  The wallet can then notify me that I am not just paying a random bitcoin address I am paying an address signed by ThomasV (or warn me if it isn't signed).  Once I make that payment I now have proof of the time (via block timestamp), the entity paid, and the amount.    By including more information in the payment url (as a note) it eliminates the ability to even say  "no that 100 BTC was for an unrelated order.  I loaned him 100 BTC and he was paying me back".   As an example the protocol should allow (optionally) to include a plain text note ("Order # 12345 for 3 HD 5970 graphics cards").

If ThomasV doesn't deliver, delivers the wrong item, or claims nonpayment all those things can be proven false.

TL/DR version:
The goal is a system/protocol that using digital signatures one can obtain proof of payment for a specific transaction.

the fact that we don't know if such a thing exists already illustrates my point...
in addition, there are situations where the communication channel is not https, and where signed URIs would still be useful.

It could be practical if you have a browser plugin which saves a https page together with its signature, and that would have a much broader usage. I wonder if such a thing doesn't exist already...

yes, but that's not practical.
do you keep a record of the webpage and its https signature everytime you do a Bitcoin transaction?

Pardon my ignorance, but doesn't https already signs every response sent by the server?
Or authenticity is assumed due to the knowledge of the common symmetric key used for encryption?

update: here is a more detailed proposal for the proposed URI syntax: http://ecdsa.org/bitcoin_URIs.html

The Bitcoin client should keep the signature in its records.

The struck part is useless.  Yes that is what this thread is about.  The merchants signature is only useful if there is some mechanism to validate it.  One would also want some mechanism to validate merchant BEFORE paying.  Otherwise you pay, and merchant doesn't sign receipt.  Oops you have no proof of nothing.

merchant doesn't present receipt until payment is made. merchant signs receipt before presenting it to customer for their signature.

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.

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?

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.

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.

Yes AND provide proof of payment.

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

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

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

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.

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)

subscribed.  interesting ideas. 

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