Is there a way to accept bitcoin payments and verify the identity of the people who paid without asking for any other information?

Question

I have a website and I am considering supporting bitcoins, but I would like to do this without asking the users to log in nor give me their email or details before buying.

Is there a way to accept bitcoin payments and verify the identity of the people who paid without asking for any other information?

I would like the buyers to claim their product after they pay, using the transaction id, the confirmation number, the address... or something like this, so I do not have to ask for any other information before they buy, but I can be sure that I deliver the product to the right person.

That is, you can pay directly using my btc address (that will be different for each transaction) and you do not have to enter anything else. After the transaction is confirmed, you can come back to the website and you can claim the product entering a "code". (Only then you'll be asked for the email or more details).

Can I use the pair of transaction addresses as this code? Is this secret or other people will be able to claim they paid?

Thank you very much!!

Answer 1

I made something exactly like what you need with sample code to be used with electrum bitcoin client. check it here. https://bitcointalk.org/index.php?topic=220494.0

I have been busy to develop it further but eventually I will get to it ^_^.

Enjoy and please share feedback.

Answer 2

You could have the customer send a message signed with the Bitcoin address used. This can be done with most Bitcoin clients or with most of the online wallets. This proves they have access to the private key for that address and are the owner.

Where they send the email from is not important as long as you can verify the message.

https://blockchain.info/wallet/features

Sign Message - Sign a message to prove you own a bitcoin adddress.

https://bitcoinarmory.com/start-page/what-is-armory/features/

Message signing with your Bitcoin addresses: sign messages using the private keys of your bitcoin addresses, that can then be verified by someone else. For instance, you pay someone 200 BTC for merchandise to be shipped to you. You send the seller your postal address, but someone intercepts the message and replaces it with their own address! This is avoidable by using signed messages: the seller sees the money came from address X, so you send them a signature block, which tells them your postal address, and sign it with address X. If someone tries to change the address, the signature will become invalid!

Answer 3

The best way is to generate a new bitcoin address for each order. When the customer wants to check out, you display this address to the customer. You also store this address in your database, associated with this particular order. Once you see (by checking the blockchain) that the proper payment amount has been made to this address, and after waiting for however many confirmations you are comfortable with (usually 6) you should ship the product.

If you use an integrated payment system like bitpay, all this should be taken care of for you.

Answer 4

If for some reason you don't want to create multiple bitcoin addresses*, you can use this arrangement:

• Customer is given your single bitcoin address and a unique invoice number. The invoice number doesn't have to be secret just unique.
• Customer is required to pay from a bitcoin address they have the private key for. Until they pay they don't have to tell anyone what this bitcoin address will be.
• Once you have received and verified the payment, you record the bitcoin address it came from.
• Customer picks up the purchase (or triggers physical delivery) by signing their invoice number with their private key. You verify the signature with their public key and send the delivery.
• You can then delete the customer record from the database if you wish ^{(and if legally permitted)}.

You should warn the customer that a purchase will not be delivered without a signed invoice number; and if automatic refunds occur for this service the refund will be to the address it came from - which may not be their specific logical wallet if they used an aggregate service provider or clearing house (the money becomes lost).

_{* Maybe to avoid transaction fees for aggregating payments, or you have a favorite wallet service, or you have a joint account with a company partner.}

Answer 5

I think I have an alternative that will work, since you are generating a unique address for each transaction.

When you generate the receiving address on your web server, also sign the address using the private key of the address; this generates a hash. You can present the address and the hash to your (potential) customer, letting them know that this hash is the code they will need to claim the product. The full hash is probably not necessary, you could get away with only presenting them with part of the hash (maybe the first 8-12 bytes).

Now the only person who knows the hash is your customer (assuming a secure web connection, no MITM, etc). It's not something that can be derived by anyone else based on what is in the blockchain since only you have the private key, and your customer can't do anything malicious with the hash.

You could do one of two things -- store the address and hash on your server (for easy lookup), or not (since there is no knowing whether they went through with a transaction or not, and you could end up with a database full of never-to-be-used hashes).

When the customer comes to claim their goods, they provide the address and the hash. Your server once again signs the address using the address's private key, and compares that hash against the claim code provided by the customer (or if you opted to store the addr/hash pairs you just do a lookup). If they match, you deliver their product.

I'm not sure if there are any gaps in this process; any feedback would be appreciated.

Answer 6

As I understood you are doing this without any login system, what you can do is generate a random alpha numeric code along with the address store this code with the address in database and prompt it to the customer. Also prompt a message that this is the unique identification number required to later claim their product. Rest process goes same like 6 confirmations etc.