Author

Topic: Ideas on distributed payment processing for merchants (Read 2301 times)

member
Activity: 102
Merit: 10
Yup. That is essentially my original post + NFC Smiley

I'll try to play around on the weekend to get some simple site going, that is able to keep a wallet and keep PGP keys for signing. Maybe based on bitcoinjs stuff.

About QR codes - it's not that bad. You scan one image with your phone, it'll automatically launch a needed app, based on MIME or something. You press 1 button. Another code appears on your screen. Merchant scans it and sees the money arriving. Pretty simple.
newbie
Activity: 23
Merit: 0
I think your original idea is on the right track.
A semi-trusted third party can be used to solve the confirmation delay issue.
Using QR codes to transfer information back and forth is probably a bit too cumbersome, but this scheme would definitely work with NFC.

I posted about this here:
https://bitcointalksearch.org/topic/m.88321

The jist of it is:
You can probably trust MyBitCoin to not attempt a double spend, so if you receive a transaction that you know came from a MyBitCoin account you do not need to wait for confirmation.

You can do this with a cell phone app.  The app received the transaction details from the POS (through QR code or NFC).  It requests confirmation from the user.  It then requests MyBitCoin to transfer the specified number of coins to the specified address.
If the phone may not have Internet access, the POS may provide an encrypted communication channel between your cell phone app and MyBitCoin.

A standardized protocol would be preferable so any new account-holding service can provide this trust service as well (obviously the POS owner would need to be able to specify which account-holding services they choose to trust).
member
Activity: 102
Merit: 10
Or that Smiley Even better Cheesy But I guess in the case of 3rd party, parts of the risk can be handled by said party.

The whole point of posting ideas here, that there'd be a devil's advocate, such as yourself.
sr. member
Activity: 416
Merit: 277
When merchant presents you with the total for your transaction and receiving address in some machine readable form, like a QR code or Aztec code, your device would scan it, display the total on your screen and present you with a prompt to agree with the transaction. Once you do that, it would prepare a data packet to the aforementioned spec, authorizing the site to transfer amount X into the address.

Ok. You've probably covered this elsewhere but for those new to this concept, could you please explain why your device doesn't do the following:

Create a signed transaction crediting the merchant using the details supplied by the merchant.
Give the merchant the signed transaction which the merchant then checks and distributes to the bitcoin network like a normal transaction.

This would remove the need to trust any third party with your bitcoins.

ByteCoin
member
Activity: 102
Merit: 10
After having a discussion about bitcoin PoS and debit card here (https://bitcointalksearch.org/topic/bitcoin-smartcard-point-of-sale-terminal-7539), the conclusion was that the smart card route it's probably not the best idea. Payment with smart device (smartphone, pda) is preferable and less hassle for everyone. There was a mention of sites like mybitcoin to arbitrate payments. Having one site means centralization, which is kinda against bitcoin philosophy. So here's a list of ideas in that regard.

  • There should be a public RFC spec for the online wallet site
  • Anyone should be able to deploy such site online, in case that person has reservations about other such sites out there, aka open source reference design
  • There should be a common API for sending transactions to such site, authorizing the site to perform a money transfer

The way I see it is something like this (from Point of Sale perspective):

Setup
You'd find a site that agrees to keep a certain bitcoin balance on your behalf. You supply the site with your GPG public key. You have the private key on your mobile device.
Sale
When merchant presents you with the total for your transaction and receiving address in some machine readable form, like a QR code or Aztec code, your device would scan it, display the total on your screen and present you with a prompt to agree with the transaction. Once you do that, it would prepare a data packet to the aforementioned spec, authorizing the site to transfer amount X into the address Y. (Ref: https://bitcointalksearch.org/topic/--5171). The packet will include the API endpoint for the wallet site of your choice. It will then encrypt and sign it with your private key and generate another machine readable data packet for the merchant to scan. Once he scans it, the packet would be submitted to the site, and upon successful decryption the funds could be transferred to the merchant's account. And the sale would be concluded.

Best part about it - they don't even need the hardware terminal for processing. A simple app would do, all it needs is a total and an address.
And your mobile device does not need internet access for this to work. Which can make it rather simple. Even a palm pilot would be able to do that Cheesy

Thoughts?
Jump to: