How I'd like it to work (Bitcoin face-to-face) feel free to steal idea

[[Coins!]]

I'd like to see an App that uses bluetooth or something on a phone that will allow you to broadcast an ID.

The ID isn't really human readable, but somehow it correlates via encryption to your BitWallet ID.  For it to be decrypted, the same app needs to be operational on another phone, or PC, or Point of Sale system.

You can also put a username of some kind if you want, on the ID, so it shows 'Grocery Store X' or 'MyNameHere', aliasing it.

Then using the secure IDs, you can initiate a bitcoin exchange of whatever value you like.  It could show up as a 'request' from the grocery store, which you verify and approve.  Or it could be a straight-payment, as with a bet or donation or loan or other payment peer to peer.

Since the address used would be your 'newest' address, the recipient of the coins couldn't easily look up your net worth, so there is some privacy there on both sides.

Thoughts? Is it overcomplicated?  Could something like this be created as a payment method for smartphones?

It seems that at some point we'll need to get our bitwallets onto our smartphones, or have some kind of service that keeps our bitwallets secure, and lets us transfer bitcoins from anywhere in the world.  I.E. like a bank card.

[dmiii]

I don`t see much sense in making my wallet public. IMHO, this system would be useful only in form when Point of Sale generates temporary bitcoin account just like MTGox does now. But in such case bluetooth is not appropriate (in public places it's use may be misleading), QR code should be used instead.As far as I know, Bitcoin e-shop API already exists, so QR code generation and transaction processing (on Point of Sale side) is not to hard to implement. Also, mobile bitcoin java client exists (written bysomebode from Google), as far as free QR codes processing libraries. I think, we will see prototype implementation in few months. On the other hand, current market instability prevents further bitcoin adoption  

[bji]

Everyone seems to be forgetting that bitcoin transactions take an average of 10 minutes to verify once, and most clients should not consider the transaction actually verified until 6 transactions, which would take about an hour.

Bitcoin will never be a point-of-sale payment system because of this.  Nobody is going to wait around 1 hour for payments to clear.  I guess there is only one possibility here and that is that point-of-sale bitcoin is the buyer giving the seller a signed transaction to submit, with the seller taking it on faith that the buyer won't do a double-spend within the next 10 minutes to 1 hour.

The seller could get better insurance against fraud in the form of personal identification that the buyer provides to give the seller someone to come after if the transaction is fraudulent.  But then the buyer has given up their pseudoanonymity, which defeats one of the major purposes of bitcoin.  Might as well just use a visa or bank card if you're going to be giving your identify up, and that's a system that's already just about as widely accepted and as easy to use as any point-of-sale system could be.

Like everyone else, I got very excited when I read about the cool technical genius of the bitcoin system and I would appreciate a nice non-fiat currency.  But it will never be widely accepted just because of ideology.  It needs to provide practical value as a currency, and it can't even come close to being as practical as most of the other forms of payment out there.  The only thing bitcoin is going to be good for is its pseudoanonymity, which will be useful for illegal transactions and otherwise unsavory transactions that can occur online and that can be delayed by hours.  This is a monetary niche and it is real and bitcoin will fill it.  But it's still a niche, and a small one at that in the world of currencies.

[FreeMoney]

You gotta make your own decisions, but right now I'd be comfortable giving up to ~$500 to a stranger based on an unconfirmed transaction, and 1 confirmation is gold. Obviously not for hundreds of thousands, but come on, the guy meeting you in Starbucks is not rewriting blocks.

[bji]

You gotta make your own decisions, but right now I'd be comfortable giving up to ~$500 to a stranger based on an unconfirmed transaction, and 1 confirmation is gold. Obviously not for hundreds of thousands, but come on, the guy meeting you in Starbucks is not rewriting blocks.

You're not a retailer.  And your clearly ready to take risks that most other people wouldn't take.

[SgtSpike]

You gotta make your own decisions, but right now I'd be comfortable giving up to ~$500 to a stranger based on an unconfirmed transaction, and 1 confirmation is gold. Obviously not for hundreds of thousands, but come on, the guy meeting you in Starbucks is not rewriting blocks.

You're not a retailer.  And your clearly ready to take risks that most other people wouldn't take.

A retailer is perfectly fine with 1/1000 people scamming them out of their money.  And I doubt it would be even close to that high anyway.  I mean, how easy IS it to fake a transaction like that?

Retailers will readily accept all transactions on 0 confirmations.  They take far more risk letting people or companies buy on credit...

[bji]

You gotta make your own decisions, but right now I'd be comfortable giving up to ~$500 to a stranger based on an unconfirmed transaction, and 1 confirmation is gold. Obviously not for hundreds of thousands, but come on, the guy meeting you in Starbucks is not rewriting blocks.

You're not a retailer.  And your clearly ready to take risks that most other people wouldn't take.

A retailer is perfectly fine with 1/1000 people scamming them out of their money.  And I doubt it would be even close to that high anyway.  I mean, how easy IS it to fake a transaction like that?

EDIT: I think there may be some confusion here on exactly what is being argued.  Is the argument now that the first verification is sufficient (which still takes 10 minutes on average, still unacceptable for point-of-sale)?  If so, then what I have written in the following is not directly addressing that point because I thought we were arguing whether or not retailers will just accept bitcoin transactions without any verification ...

It's super-duper easy to screw a retailer like this.

Step 1) Eat in restaurant.
Step 2) Pay the restaurant owner with bitcoin in this hypothetical situation in which the restaurant owner does not require you to wait until the transaction has 'cleared' (i.e. embedded itself a few levels deep in the block chain).
Step 3) Walk out the door and immediately make another transaction that sends the total balance from the bitcoin address that you just paid with to a new address owned by you.
Step 4) You have a 50% chance (better if you are faster at submitting transactions than the other guy) that your transaction will end up in the block chain first and the restaurant owner will get nothing.

Accepting a bitcoin transaction without verifying it in the block chain is nothing more having someone tell you that they paid you but without any way of knowing whether or not they really did.  It becomes an 'honor system' form of payment.

How many retailers do you know of accept a payment system where people can walk in the door, flash a $100 bill, and then walk out with whatever merchandise they want on the promise that they'll send the money when they get home?  This is the same as accepting unverified bitcoin.  Retailers would get screwed 75%+ of the time in such a scheme and there is no way they're going to go along with it.

Retailers will readily accept all transactions on 0 confirmations.  They take far more risk letting people or companies buy on credit...

False.  Retailers only accept transactions with the confirmation of VISA and with the verification that the signature matches.  I know of no retailer that lets you take stuff with a promise that you'll pay later without identifying yourself in any way.

[Zagitta]

To start off with: I haven't studied the bitcoin protocol extensively so by all means correct me if i'm wrong!

Okay so a confirmation of a transaction happens every 10'th minute because that's what the difficulty system aims to have a block sovled at right? Why is this set to 10 minutes and not something like once every minute? (ofc with 1/10 the reward for finding the block) I mean doing this would not only solve the wait for x amount of confirmations but also make it a lot more compelling to solo mine because of it lowering variance and thus solving the problem with pools being single points of failure...

I guess bandwidth could be a problem but what else is hindering this?

[SgtSpike]

bji, you do have a point about sending all your bitcoins to a different address after paying a retailer.  How would a block prioritize between two conflicting transactions?  Biggest one wins?  First one to be submitted wins?

I agree with Zagitta's idea of reducing blocks to being found at a rate of 60 per hour, and cutting the reward for each block down to 5 BTC.  Not only would this solve the issue of pools (solo mining and small pool mining suddenly becomes less variable by a factor of 10), but it would allow retailers to verify transactions much more quickly.  The expense would be the overhead of more blocks in the blockchain, but we need to deal with the ever-expanding size of the blockchain files anyway, so I think it is a fine price to pay.

My thinking about a retailer accepting transactions with 0 confirmations relates to checks.  Most retailers still accept them, and really, the risk is entirely on the retailer if the customer doesn't have enough funds in his checking account to cover the transaction.  I view a bitcoin payment in the same manner as a payment made by check.

[bji]

out a retailer accepting transactions with 0 confirmations relates to checks.  Most retailers still accept them, and really, the risk is entirely on the retailer if the customer doesn't have enough funds in his checking account to cover the transaction.  I view a bitcoin payment in the same manner as a payment made by check.

With a check you have given the retailer your identity (and they confirm this by checking your i.d.).  Not (necessarily) so with bitcoin.

[xc]

This scenario could be handled nicely with the concept of listening nodes:

Transactions are nearly instantaneous.  It's traditional network confirmations that require tens of minutes.  However, as explained by Satoshi, merchants can significantly reduce the probability of a double-spend through the use of a listening period:

https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn_t_possible_because_of_the_10_minute_wait_for_confirmation
http://forum.bitcoin.org/?topic=423.msg3819#msg3819

The longer the listening period the greater the assurance that the transaction will be confirmed as is. 10-30 seconds would probably be sufficient.  Theoretically, it's possible that the attacker might have a huge cache of hidden miners that would only accept his version of the transaction.  But this seems highly unlikely and a huge waste of effort for skimping on a simple meal.  It's so much less likely that a payment processor offering the listening node service could likely guarantee the restaurant's payments for a fee far less than what banks charge for the use of credit cards.

[Zagitta]

bji, you do have a point about sending all your bitcoins to a different address after paying a retailer.  How would a block prioritize between two conflicting transactions?  Biggest one wins?  First one to be submitted wins?

I agree with Zagitta's idea of reducing blocks to being found at a rate of 60 per hour, and cutting the reward for each block down to 5 BTC.  Not only would this solve the issue of pools (solo mining and small pool mining suddenly becomes less variable by a factor of 10), but it would allow retailers to verify transactions much more quickly.  The expense would be the overhead of more blocks in the blockchain, but we need to deal with the ever-expanding size of the blockchain files anyway, so I think it is a fine price to pay.

My thinking about a retailer accepting transactions with 0 confirmations relates to checks.  Most retailers still accept them, and really, the risk is entirely on the retailer if the customer doesn't have enough funds in his checking account to cover the transaction.  I view a bitcoin payment in the same manner as a payment made by check.

Thanks for making it more clear what i meant

I actually got another idea from reading the links provided by xc... How about improving upon the idea of listening nodes?

Simply create a distributed network of small nodes who sole purpose is to be well connected and listen for transactions that the store have told it to and then report back about it. Essentially this would work as a different form of mining because shops would through an extension of the bitcoin protocol send a fee together with the address to listen.
Depending on the type of shop and its location it would send this listen command to multiply nodes run by different persons/companies at different locations.
For example if it's just a small community shop located in a small city it would most likely be enough to send it to the local node however with a shop that has a lot of in country tourists it would most likely send the command to either more nodes or A node network with favorable placements throughout the country owned by a company...

Shopkeepers would even be able to run their own local nodes if they wanted to.

At the top of my head this seems like an apporach that avoids a centralized structure however i guess that's under the assumption that more than one company would be competing about running these node networks :/

[xc]

A further optimization would be to focus on what the mining pools 'see.'  Because pool miners work on the transaction data received by their pool operator, it should be relatively straight-forward to directly connect to pool operators in such a way as to see what transactions they have received.  Hashing power working on the merchant's transaction could therefore be roughly calculated.  Once a large majority of network hashing power is behind the merchant's transaction, the listening node processor could verify the transaction for the merchant.

[xc]

Actually, expanding on this idea, a simple public website akin to blockexplorer could offer this service.  For a given transaction, it would report how much hashing power was working on the requested transaction.  Assuming pools do not reject a given transaction and relay transactions that they are working on, this would be done by simply requesting current transaction data from specific pool operator nodes to check what transactions they have seen.  By estimating total network hashing power, it could then calculate a propagation metric (50% propagation = 50% of hashing power has seen transaction).

[Gr.Green]

The idea discussed by OP would be easily possible if the retailer dealt with the customer indirectly, i.e. via Google Wallet for example. Google would provide insurance and would handle all the trust issues while taking a small cut of the transaction. It would be up to Google to verify the identities of payees and ensure they have enough funds available to them.

[bji]

The idea discussed by OP would be easily possible if the retailer dealt with the customer indirectly, i.e. via Google Wallet for example. Google would provide insurance and would handle all the trust issues while taking a small cut of the transaction. It would be up to Google to verify the identities of payees and ensure they have enough funds available to them.

Then bitcoin becomes a transaction routing method for big banks and becomes significantly less interesting or useful.

[bji]

This scenario could be handled nicely with the concept of listening nodes:

Transactions are nearly instantaneous.  It's traditional network confirmations that require tens of minutes.  However, as explained by Satoshi, merchants can significantly reduce the probability of a double-spend through the use of a listening period:

https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn_t_possible_because_of_the_10_minute_wait_for_confirmation
http://forum.bitcoin.org/?topic=423.msg3819#msg3819

The longer the listening period the greater the assurance that the transaction will be confirmed as is. 10-30 seconds would probably be sufficient.  Theoretically, it's possible that the attacker might have a huge cache of hidden miners that would only accept his version of the transaction.  But this seems highly unlikely and a huge waste of effort for skimping on a simple meal.  It's so much less likely that a payment processor offering the listening node service could likely guarantee the restaurant's payments for a fee far less than what banks charge for the use of credit cards.

Watching transactions is not good enough.  I could easily trick a retailer:

1) I have 10 bitcoins in a bitcoin address
2) I buy something for 6 bitcoins
3) I pay by sending the retailer 6 bitcoins but unbeknownst to the retailer I also send myself 5 bitcoins.

If the retailer doesn't see my transaction to myself, and it gets verified first (10 minutes later, long after the retailer was satisfied with my payment and I've left the point of sale), then the transaction to the retailer will fail and be rejected because the funds weren't there (there were only 5 left).

If the retailer does see my transaction to myself because I sent it 10 seconds before my transaction and it passed by the retailer's listener before I even told the retailer my bitcoin address to watch for the transaction from), then how can they prove that this means that my transaction with them will fail?  They can claim it will, but I can claim that it won't.  I guess they could have a policy that "if anything looks fishy with a transaction then I don't accept it."

But what if I anticipate making a purchase - say, 5 minutes before I am going to go to the point of sale.  Then I "empty" out the bitcoins from a bitcoin address with a transaction 5 minutes before I even walk up to the counter.  The retailer doesn't know who I am and of course didn't have their 'listener' tuned into any of my transactions until I walk up to their counter.  Their listener watches my transaction (that I know will almost certainly fail because my other transaction had a 5 minute head start), sees it go by, and gives the all clear.

Simply put, unless a transaction is in the block chain, embedded deeply enough that the chances of anyone rewriting the block chain to change it are infinitesimal, accepting that transaction is taking a huge risk.  There are probably other ways to game the system also.  Retailers will never accept non-validated transactions.

[ByteCoin]

bji, you appear neither to understand how transactions work, nor how they propagate across the network and you make dogmatic assertions of things that just aren't true.

Your "screwing a restaurant" scenario doesn't work as the transaction paying the restaurant owner has a significant lead in propagating across the network. Your "tricking a retailer" strategem doesn't work as the retailer would see the double-spend transaction to yourself and refuse to part with the goods. Your "5 minutes in advance" scenario doesn't work as the retailers "listener" is "tuned" to all transactions and hence rejects your transaction.

Contrary to your assertions, accepting small transactions with no confirmations can be made fairly safe.

I invite you to prove me wrong by implementing one of your attacks in a reasonable setting.

ByteCoin

[bji]

bji, you appear neither to understand how transactions work, nor how they propagate across the network and you make dogmatic assertions of things that just aren't true.

Please stick to the point at hand.  I don't really need you telling me what you think I do and don't know.

Your "screwing a restaurant" scenario doesn't work as the transaction paying the restaurant owner has a significant lead in propagating across the network.

Let's get one thing straight before more unfounded logic ensues: by the time that bitcoin is used by a significant number of retails at point-of-sale, it will have grown to be much, much larger than it is now with many, many more transactions per second.  Hundreds of transactions per second is what we're talking about here.

With a stream of hundreds of transactions per second being injected into the network from various places all around the world, there is no way that the ordering of transactions are going to be guaranteed, nor is the timing.  It will be quite likely for one transaction to be delayed in reaching the listener you speak of - if it ever gets there at all - relative to another transaction, simply because at hundreds of transactions per second, there is no way that every peer is going to be passing all of its messages on to every other peer.   Well that's my conjecture anyway, I can't prove it any better than you can because until Bitcoin grows this big, no one will really know how it will handle such loads.

Your "tricking a retailer" strategem doesn't work as the retailer would see the double-spend transaction to yourself and refuse to part with the goods.

The retailer only knows that it's a double-spend if they are able to validate the transaction, and if they see both transactions.  The former condition requires them to be a 'super node', and the latter is not guaranteed when the network is big and complex.  By the time that bitcoin is used significantly at point-of-sale, with hundreds of transactions per second, being a super node will entail a major resource investment.  Although maybe at that point this kind of information will be provided by super nodes and retailers will pay to issue queries about what transactions the super node knows about.  Still, it's not nearly as simple as 'the retailer will just watch the transactions'.

Your "5 minutes in advance" scenario doesn't work as the retailers "listener" is "tuned" to all transactions and hence rejects your transaction.

It was my assumption that retailers would only watch for transactions from bitcoin addresses that they are expecting payments from, because the firehose of all transactions in such a situation is likely too great, as I have mentioned numerous times here.

The system you are talking about doesn't look anything like bitcoin does today, nor as it was described in the whitepaper or implemented in the client.  You're talking about services and methods of validating transactions in ways that have not been tested yet.  I don't think that the advantages of bitcoin - potentially lower transaction fees (although I'm not convinced of this myself) and pseudoanonymity will be enough to convince people to use it in preference to much more workable, and already existing, point of sale systems.

Contrary to your assertions, accepting small transactions with no confirmations can be made fairly safe.

Well obviously the disagreement is over the meaning of the term 'fairly safe'.

I invite you to prove me wrong by implementing one of your attacks in a reasonable setting.

Why is the burden of proof on me?  How about you build a retailer business that accepts bitcoin at point-of-sale without validating transactions in the block chain and we'll see how long you last.

I'm not seriously proposing that you do that, by the way, because I don't think that assertions that one party has to prove by doing rather than prove by logical argument have any place in serious discussion.