Transaction fees and speeding up transactions

[ascent]

Clear this up for me as I'm not clear on it.

I walk into a burger joint and pay $5 in Bitcoins for a burger. Let's presume this is the near future and I can do this with my smartphone.

Now, the transaction needs to be approved in about 3 seconds. You can argue with me about this until we're both blue in the face, but let's not. Let's just accept, for purposes of this argument, that it reasonably should approve within about 3 seconds.

Let's also assume that there is no such thing as just assuming it's good because it's an inexpensive transaction. That doesn't work for me either. If a business assumes that, then I guarantee they'll stop assuming that as soon as a set of regulars take advantage of that somehow.

Final assumption: the burger joint doesn't really care whether they collect $5 or $4.90 or some figure close to that. And the customer doesn't really care whether the burger costs $4.90 or $5 or something close to that.

Therefore, it seems reasonable that the burger joint can tack on an extra fee to the transaction (they need not state it like that though). They just advertise burgers for $5 and eat a 10 cent transaction fee.

So, my question is, can a transaction fee in the realm of 10 cents or so on a $5 transaction get this transaction approved in 3 seconds or less? If so, great! If not, then that's not so good.

[wolftaur]

The block chain has a generation target of ten minutes. So for the burger's purchase to be approved in 3 seconds you have to try and buy the burger 3 seconds before a miner successfully creates a block... if you buy it just after a block is posted, then the average target wait time is going to be 10 minutes, though that is based on statistical expectations, not an event on a timer.

[ascent]

Thanks for the speedy explanation.

So what's it going to take to get transaction times down to about 3 seconds, and not require shenanigans on the part of the customer?

[phillipsjk]

A trusted payment processor. Or, the business can assume the transaction will go through once transmitted with no confirmations for small transactions.

[ascent]

Or, the business can assume the transaction will go through once transmitted with no confirmations for small transactions.

What does this assumption entail? Does it mean a customer can initiate the transaction and not actually have the funds? If so, as I stated in the OP, that's not going to work.

[wolftaur]

Thanks for the speedy explanation.

So what's it going to take to get transaction times down to about 3 seconds, and not require shenanigans on the part of the customer?

Transactions are relayed by nodes even before being inserted in a block chain, at which point they will generally eventually be placed into a block. However, before they have been placed into a block, it is possible the person could simply send another transaction to spend the same coins elsewhere. When people are talking about "a small amount like for a hamburger" they usually are proposing that the merchant look at all relayed transactions -- they should see the burger purchase, and if a bit of time goes by and they don't see any other purchases from the same address, a double-spend would be harder. The attack scenario usually involves a network or other problem which causes some relay nodes to not be connected together, i.e., if the network has COMPLETELY split into 2 segments due to a faulty power line, I could theoretically spend coins differently on each of the two networks. On a sufficiently large network this would be very difficult.

[ascent]

When people are talking about "a small amount like for a hamburger" they usually are proposing that the merchant look at all relayed transactions -- they should see the burger purchase, and if a bit of time goes by and they don't see any other purchases from the same address, a double-spend would be harder.

So when you say, the merchant "looks at all relayed...", do you mean, a software application does all this automatically for the vendor and comes back with an "It looks good" message?

And then when you say, "a bit of time goes by...", do you mean, less than 5 seconds?

The point I'm getting at here, in a nutshell, is, can we reliably process transactions less than, say $50, in 5 seconds or less, or not?

[imperi]

When people are talking about "a small amount like for a hamburger" they usually are proposing that the merchant look at all relayed transactions -- they should see the burger purchase, and if a bit of time goes by and they don't see any other purchases from the same address, a double-spend would be harder.

So when you say, the merchant "looks at all relayed...", do you mean, a software application does all this automatically for the vendor and comes back with an "It looks good" message?

And then when you say, "a bit of time goes by...", do you mean, less than 5 seconds?

The point I'm getting at here, in a nutshell, is, can we reliably process transactions less than, say $50, in 5 seconds or less, or not?

Customers could create an account with an online site and deposit a few of their Bitcoins into this site. The customer could then use their credentials at this site, possibly using a smartphone, to purchase a burger. The burger restaurant trusts the site when it says the payment is coming, and surely enough the site wires BTC to the burger restaurant (at this point the customer is already eating). The site then credits the cost to the account of the customer.

[FuzzyCoins]

The point I'm getting at here, in a nutshell, is, can we reliably process transactions less than, say $50, in 5 seconds or less, or not?

It depends on what you mean by "reliably", but if you mean that the merchant has 100% confidence that they will get their money, the answer is no. The protocol just doesn't work that way.

[ascent]

It depends on what you mean by "reliably", but if you mean that the merchant has 100% confidence that they will get their money, the answer is no. The protocol just doesn't work that way.

It doesn't need to be 100 percent. But, factoring in criminal intent, can a merchant reliably process, say 999 out 1000 transactions reliably? I don't think merchants are going to be happier with less than that.

[phillipsjk]

To accept a transaction with zero confirmations: the merchant should, at the very least, verify the coins exist. To do that they would check the block-chain for the coin creation transaction. I am not sure what kind of hardware you would need to guarantee that it happens within seconds though.

[BitQuestr (BitCoinWorldMarket)]

I think this should be on the feature list of any online wallet service. It shouldn't be hard to initiate a transfer from the site using a mobile version on a smartphone, then the site allows you to also enter an email of the recipient. The site checks that you have enough in your account and instantly emails the recipient that the transaction is approved and on its way. Even better if this could all be implemented with a QR code that the vendor has.

Near instant verification and notification of transactions should be a feature of future clients, maybe even the official client.

Some of us may want anonymity, but I would bet the majority would like to have the option to verify, transmit or receive instant notification, and the security of a 3rd party verification.

[ctoon6]

An online wallet would fix this, if both parties had accounts and the same wallet service you could allow funds to be secure in that wallet. then transfer funds inside the wallet service, the service replies that the one buying actually has the coins and they selling party will get the coins. it would be near instant.

However, REAL coins must be transferred, not just the database saying they were, they should show up on the network in the chain.

[d.james]

And then when you say, "a bit of time goes by...", do you mean, less than 5 seconds?

The point I'm getting at here, in a nutshell, is, can we reliably process transactions less than, say $50, in 5 seconds or less, or not?

I would say Yes, and I'll use a real example from my own experience here:

I'm a miner on BTC Guild, they have an "Instant Payout" button, whenever I press that button, they automatically sends me my balance (usually 1-2BTCs), and as long as I have my client open at the time, I'd always INSTANTLY see that transaction appear in my client.
 (ie: Received 1.25 BTC on BTCguild address,  0 confirmations)

Now since I trust that BTCGuild will not screw me over that 1-2 BTC, I never wait for the confirmation to happen.

I'd say the burger shop can safely assume that the buyer won't screw them over an $5 order. thus they should be able to instantly release that burger to the customer, after seeing a "0 confirmation" transaction appear on their client.

[ascent]

I'd say the burger shop can safely assume that the buyer won't screw them over an $5 order. thus they're able to release that burger after seeing "0 confirmation" transaction appear on their client.

They may assume that, but from your explanation, you make it sound like the buyer could conceivably screw them over, which guarantees that a group of individuals will exploit this to maximum benefit, which then means vendors cannot assume that. Maybe burger joints wouldn't be the target of said evil individuals on regular basis, but it's not clear to me that the mechanism is ready for prime time.

[d.james]

I'd say the burger shop can safely assume that the buyer won't screw them over an $5 order. thus they're able to release that burger after seeing "0 confirmation" transaction appear on their client.

They may assume that, but from your explanation, you make it sound like the buyer could conceivably screw them over, which guarantees that a group of individuals will exploit this to maximum benefit, which then means vendors cannot assume that. Maybe burger joints wouldn't be the target of said evil individuals on regular basis, but it's not clear to me that the mechanism is ready for prime time.

True, organized Burger Burglars can technically sync up and buy 1000 burgers at the same time at different locations.

But the chances of that happening is way less than say, someone using a stolen credit card doing much more damages.

[dood001]

Those $5 transactions are his/her business - and if it was my business I would want to know that it is guaranteed that I am getting paid. Like cash money - a quick check that the money is not counterfeit and I am all good.

[d.james]

Let's list some of the risks comparing BTC to other Payment methods.

Credit Card:  Chargebacks from dishonest buyer, or stolen card
Cash: Counterfeit Bills
Check: troublesome and risky...


BTC with 0 confirmation:
Not 100% secure but you will find out usually within 10minutes,
This can be very risky for the scammer if deals are done in person,
The next block could be solved seconds after the transaction, store owner can probably catch him before he gets out of the store.

Cons: NO STORES ACCEPT BTCS, YET

[ascent]

Risky for the scammer if deals are done in person,
if the next block is solved with in a minute or two,
the seller can probably catch him before he gets out of the store.

Not really risky though for the scammer. He can just claim he lost track of what his balance was. Oops. Sorry about that. Let me pull out my other wallet... Kind of like a credit card decline. Not really a crime at all.

[ctoon6]

another idea, you give stores and other places BTC, and they just withdraw it off your "account" you could buy universal cards that contain an open standard code

than you just swipe your card and they take the money from your store specific account