Topic: Store purchases concept - sorry somewhat long (Read 1476 times)

Bitcoin already has long-dormant code to send transactions directly between clients, so NFC is definitely a possibility. Though it also still has to go out to the network, so you only gain a few seconds.

Those are damn good points!

I thought if it was unconfirmed that meant it hadn't shown up yet!

The confirmation code system is now officially depreciated and moot.

Wow, that would make coding the 2 necessary systems alot easier, as it would just be modified versions of existing clients.

If only I had coding skills.

EDIT: by 2 systems, I mean the point of sale integration for the retailer, and the mobile app to send payments.

This could be the NFC of bitcoin. lol

EDIT 2:

so this would mean that the process would be as follows...

cashier selects bitcoin

pos creates recieve address and qr code with said address and payment amount

screen shows qr code

shopper scans with camera and confirms dollar amount

transaction approved when the unconfirmed transaction shows on client

The whole network becomes aware of a transaction within a few seconds. Faster than "Processing Your Card" when you swipe it at a POS. Inclusion in a block isn't STRICTLY necessary as long as you can verify the transaction itself isn't a double spend (and this happens already). Unless you envision an attack where someone who controls a large segment of the Bitcoin miners decides to go shopping at Wally World. Actually mounting such an attack while standing in line at a register requires some very good timing and probably some outside help.

Is there a reason retailers couldn't accept 0/unconfirmed transactions?  I mean, the only way that those transactions wouldn't be confirmed is if they were generated from a double spent, right?  And anyone who is trying to double-spend on the network would probably go after bigger fish than a retail store?

Maybe I'm wrong.  But it seems like bitcoin fraud on a 0/unconfirmed transaction would be just as difficult as something like forging a check, and retailers could simply create a bad debt accrual account for it.

I've heard that it only takes a few seconds for a 0/unconfirmed tx to show on every client.  If it takes longer, a client could be created that allows direct connection from client to client.  When you walk in to walmart, it detects the proximity of a "retailer" client, and automatically connects to one of them.  That way, you are assured that the transaction will show up instantaneously.

yeah, the confirmation code seems pointless. Its point was to speed transaction time. This raises the question if the network can confirm the transaction quickly enough, as it seems now that its approximately a 10 minute wait for the transaction to show up.

If the network can pass the transaction from the shopper to the stores bitcoin server fast enough, it can make deploying a system like this even easier still. Its just a matter of developing a bitcoin plugin for a pos and a mobile app to send the payments from.

Hmmm

Since virtually anywhere there's a Walmart, a mobile phone will have some sort of data connection, forget about the confirmation code crap and just get the transaction from the Bitcoin network.

 ok so i had an idea for how stores can offer bitcoin purchases.

This concept seems best targeted to chain stores, as it requires a well connected pos server and custom coding on their part. If it becomes standardized; however it may work out better. In general this concept will use a secure smartphone app, and software running on the chains pos server.

After I had thought of this idea I found this - http://www.androidzoom.com/android_applications/finance/bitcoin_zsuj.html

This seems to have a similar concept; however my concept is very specific. The description on that site seems fairly ambiguous, and directed
towards individual to individual transactions.

Lets use Wal-Mart as an example...

So walmart decides to accept bitcoins, They set up in their server farm a bitcoin specific server. This server acts as a bitcoin transaction processor as well as an extremely well connected node. This is important as to minimize the transaction processing time. Now an individual has an app on their phone, this app is basically the desktop app. It holds their bitcoins in a secure wallet that is encrypted on the device.

Walmarts server is responsible for a few things, generation of a recieve address, noting the correct dollar amount, encoding the recieve address within a qr code, and transmitting code to the display on their pos.

So how it would work in an everyday example is as follows:

customer is checking out, says would like to pay with bitcoin. Here it splits into the front end and back end. In the front end the cashier selects bitcoin as the payment method, a qr code appears on the display where one would normally sign, shopper scans with camera phone confirms the dollar amount and taps ok, and finally it processes and approves.

On the back end it becomes more complicated, but is still no more complicated than a standard credit card transaction. The key press triggers the pos system to initiate a receive, the system then generates a new address for a receive, it encodes the address and some additional details into a qr code, and transmits it to the display. When the smartphone takes the picture and confirms the amount this will work exactly like in the desktop app when send coins is clicked. The app interprets the send address, a dollar amount, and a confirmation code. The app presents the confirmation screen with a dollar amount to pay and an ok button. When ok is clicked the bitcoin is transmitted as usual. A new confirmation code is then generated for the cashier to key in to the register.

A qr code can accommodate up to 4296 alphanumeric characters. This should be sufficient to accommodate all the data needed to process a transaction quickly.

Now here is where I run into a problem; however, so we have a confirmation code from the server and a confirmation code generated by the phone and displayed. A secure method to calculate the second confirmation code needs to be devised. I imagine an algorithm to calculate the new confirmation code should work, but what is needed is a way that the store can receive a confirm able code to ensure the payment was sent.

ok lets say the store takes the payment amount omitting the decimal and the confirmation code and multiplies them together and then divides them by the first numeric digit occuring in the receive address. for example purchase is 20.59 confirmation code is 72345622 and first digit is 2.

This means the final confirmation code would be 74479817849 this is the total of the math, and the confirmation code would be the first 8 digits. This is something that could be kept a secret formula of the system only, but if someone discovered it that could lead to massive fraud. This is why I believe it must be much more secure than above. This would need the help of someone with better math skills than me.

Thankfully at some point in the future the network could be fast enough that transactions post and confirm instantly rendering the confirmation codes needless.

But on the consumers end this takes no longer than a traditional bank card transaction, as a matter of fact there could be no confirmation needed under say 25 dollars, just like credit cards. just scan click ok and go.


So thats my concept, I have no way to implement it myself, but I would love some opinons or conversation about how plausible this concept is..