Bitcoin versus Credit Cards, help Bitcoin compete

[morningtime]

Credit Cards provide certain functionality like recurrent billing. This matters from merchants' and customers' point of view. I would like to discuss technical implementation of such features on top of the Bitcoin system. It will make Bitcoin more adoptable by the masses.

The point is to make Bitcoin more competitive compared to credit cards. I'm not arguing for credit cards, just trying to invent Bitcoin workflows. Please help me design the solutions!

Case A: automatic refunds
Use case: merchants sometimes need to provide refunds. A Bitcoin transaction does not include a from address. Although you could do a blockchain lookup to figure it out, I guess. The implication is that Bitcoin cannot handle automated refunds.

Possible solutions: send a refund 'request' via email. Customer needs to enter Bitcoin refund address online. Automated script then processes the refund.

Alternatively, would it be possible to include a return address in a Bitcoin transaction? If so, then refunds could be automated. This is a valuable feature to merchants. Note, this is different from 'reversible' transactions. The merchant only uses the return address to return coins back to the sender via a new transaction.

Another solution would be to ask customers to "please enter your refund address" in case of a refund. Online wallets can play a role too.

Case B: split payments
Use case: the European Union has enacted laws that customers may not be forced to pay >50% of an online purchase in advanced. Split payments, e.g. 50% in advanced, 50% upon receipt.

Possible solution: again, using email. A merchant asks for 50% Bitcoin payment. Upon shipping he sends an email requesting another 50% payment.

Case C: recurrent billing
Use case: imagine dating sites or selling magazines etc. Recurrent billing (like PayPal or credit cards offer) is obivously not doable with Bitcion out of the box.

Possible solution: using email merchants can send periodic payment reminders. Customers would click a bitcoin: URI link to pay.
Perhaps a better solution would be to hold an online wallet from which to deduct Bitcoins.

--

I think online wallets are going to have to play an important role in these scenarios. But then you have a problem: online wallets are centralized systems. It would be better to implement features within Bitcoin itself, to keep the features decentralized.

[1714968939]

1714968939

[1714968939]

1714968939

[1714968939]

1714968939

[1714968939]

1714968939

[1714968939]

1714968939

[Stephen Gornick]

Another solution would be to ask customers to "please enter your refund address" in case of a refund. Online wallets can play a role too.

I'm not going to comment on the "automatic" part of the refund process, but as far as the actual refund payment, you are correct that a new address needs to be obtained to process a refund.     This is a problem when the original purchase may have been made without an account and perhaps from an E-Wallet where the buyer doesn't have control of the address used to send payment.

This opens it up to where any party can request a refund on someone else's order in this scenario.  

Most E-commerce involves use of an authenticated account (e.g., authenticated username and password), so this isn't a problem for most merchants.   If selling anonymously, or without account authentication, then either a refund address should be provided by the customer at the time the order is placed (yuck) or the refund handling would need to be something otherwise appropriate.  For example, if a physical address was used for the order but a refund is requested then a letter with a refund verification code could be sent to the same address.  There are workable solutions that protect both the merchant and the customer for nearly every scenario.  

There is a payment protocol being built for the Bitcoin client that will further protect the person sending payment:
 - https://bitcoinfoundation.org/blog/?p=85

Case B: split payments
Use case: the European Union has enacted laws that customers may not be forced to pay >50% of an online purchase in advanced.

There are laws affecting specific payment methods (e.g, credit cards) that don't apply to other payment methods (cash).   If something like a payment sent upon notice from the delivery service were desired,  an escrow partner could facilitate that.

[joecascio]

I think simple email "bills" that included a bitcoin address would be a phishers dream come true. It's important to be able to authenticate the source of an such an email before making a payment, especially automatically. Email is notoriously easy to spoof. All a phisher would have to do is sent out a bazillion emails with their btc address and wait for the dummies who just press "pay" or set their account to "auto-pay".

One of the best and most consumer-empowering things about bitcoin is that it's based on giving money, like you give a merchant cash, not taking it, like someone with your credit card or bank account number can take money from you. I wouldn't want to see that compromised. That said, you are spot on with the need to accomodate subscriptions, refunds, etc.

I think refunds may be partly addressed by something similar to the escrow capability Mike Hearn talked about in his Bitcoin 2012 talk. http://youtu.be/mD4L7xDNCmA

[sebastian]

Email can in fact be authenticated securely.

I have for example authentication set up for my outgoing mail. Try doing a TXT lookup for "sebbe.eu" and you will se this: "v=spf1 +mx -all"
This means:
"Only accept email originating from a sebbe.eu domain that is sent from a mailserver that has the IP set as the A records for the domains in my MX records, in other ways - dns1.sebbe.eu (193.13.142.178) or dns2.sebbe.eu (46.59.86.163)"

Also DKIM is a Another email authentication system based on signing.

And don't get me wrong. Rerouting emails in transit will change its origin - thus SPF will fail. Only way to "fake" a SPF message is to modify it WHILE in transit, and thats much harder, since you would need access to one Point in the path between mailservers. And thats not a easy thing. Modifying a email over for example Wifi are not being viable for attackers, since the customer needs to download a "Merchant Email Bill" just in the same time as the attacker sits on the same Wifi.

Normally, your upstream server (your incoming SMTP) authenticates mail, but you can also authenticate mails yourself - provided that you trust your email provider's server to insert a Received:-line in the mail, for example if your email provider does not authenticate SPF.
The topmost Received:-line is then trustworthy, and the rest of them should be considered spoofed.
DKIM can be authenticated locally without any trust for your mail provider.

DNS based authentication can also be used for Bitcoin - just put up a TXT record with the bitcoin adress. The bitcoin client could have a extension so upon receiving a domain name as adress - lookup in TXT record and picks the first valid bitcoin adress it gets.
Merchants could simply publish per-customer domains, like "Sebastian_nielsen.customer.thismerchant.com" that will Point to the merchant's payment adress for my order.