Can/Will Transactions Ever Be Processed Faster Than Every 10 Minutes?

[bitlotto]

I've thought about it too for when stores/fast food places start using Bitcoin. I think it could work. Say I go to a store. I have my smart phone with Bitcoin running. Since I would be used to buying stuff with Bitcoin one of the first things I would do is 'make funds available' for the store when I enter. The app would communicate with the store and get a unique address and I'd give a refund address. I'd then send a max amount I intend on spending. Send the BTC and start shopping. Then when I go to the checkout after the total is calculated the remainder is sent back. Something like that. If I didn't make enough available I guess I'd have to hang around. It would remind me to always over guess the amount so I don't wait next time. That way the user just has to trust the store and not the store trust everyone who enters. 

[tomcollins]

As that aspect of Bitcoin severely limits it's "world currency status" potential.

Huh.  One-to-three day transfer times doesn't seem to have hurt the dollar much: http://www.depositaccounts.com/blog/inside-look-at-ach-transfer-speeds-at.html

"Instant" payments with world currencies is an illusion created by your bank of financial institution based on how much they trust the person or institution sending the money.  There is nothing stopping bitcoin financial institutions from using the same trick, and I think as the bitcoin economy grows and companies start to trust each other instant transfer times will happen.

This is an interesting perspective.  BTC crushes similar systems with actual transactions.  10 minutes or an hour or whatever it takes, is far, far superior to the systems in place for actual transfers of money.  But of course it's often compared to the methods of instant transactions, which of course are not really instant, but can be instantly verified by the agencies that handle this.

This does leave a huge growth opportunity for the BTC economy to grow by having institutions being able to provide these services, and then square up at the end of the day/week/month.

But another question is, why does it have to be that way?  Was it based on technical limitations of having too many blocks if there was 1 per minute or 1 per second?  Is it possible to change the difficulty and rewards by making blocks more often if that was needed?  I'm sure there's a good reason.  It just is unfortunate that the model seems to have been based upon the outdated banking model rather than the more modern reality.  But even with a modern banking system, I can hand a cashier $10, and he gives me change and my food.  I can't hand him 10BTC and get change back for in person transactions.  BTC seems to serve a more niche need rather than being a full-service currency.  Which isn't a bad thing, but maybe it would have been nicer if it could handle such things.

[theymos]

But another question is, why does it have to be that way?  Was it based on technical limitations of having too many blocks if there was 1 per minute or 1 per second?

It's to allow for high latency between nodes. If it was one minute, a few seconds of latency between ends of the network could give someone with good network resources a better chance of winning blocks, damaging the "one vote per CPU" principle.

Also, remember that a confirmation is valuable because it represents some CPU power. If it took a minute on average to get a confirmation, you'd have to get 10 confirmations to match the protection of a single 10-minute confirmation. 1-minute confirmations might even be less valuable than 0 confirmations in such a system because it could be cheaper for an attacker to solve the required number of blocks than to overcome the TCP network.

[Jim Hyslop]

So is it possible to independently verify when someone initiated a transfer from the client?

The only independent timestamp is the one in the block, since the transaction is only timestamped upon receipt, and that timestamp isn't shared with other clients.

The block timestamp will indicate a "not later than" date, i.e. it will indicate the latest time that the transaction could possibly have been created (within the margin of error allowed by Bitcoins, which is I believe two hours).

So, there's a service to offer - set up a reputable, highly-accurate timestamp service. Basically, as long as you ensure your workstation's clock is accurate, you could use the standard client, and charge someone a fee to "prove" the timestamp of the transaction. Of course, even then you'd be subject to network latency, so the timestamp will still have a margin of error, but it will probably be under a minute or two.

[tomcollins]

But another question is, why does it have to be that way?  Was it based on technical limitations of having too many blocks if there was 1 per minute or 1 per second?

It's to allow for high latency between nodes. If it was one minute, a few seconds of latency between ends of the network could give someone with good network resources a better chance of winning blocks, damaging the "one vote per CPU" principle.

Also, remember that a confirmation is valuable because it represents some CPU power. If it took a minute on average to get a confirmation, you'd have to get 10 confirmations to match the protection of a single 10-minute confirmation. 1-minute confirmations might even be less valuable than 0 confirmations in such a system because it could be cheaper for an attacker to solve the required number of blocks than to overcome the TCP network.

Perhaps the one vote per CPU principle is wrong.  Network speed is a hugely valuable part of the system.  I want those finding blocks to have fast connections.  I need to really put effort into understanding how someone could double-spend to really understand the problem well, though.

But perhaps it's better to think about BitCoin as a "between-bank" system for larger transfers done less often, rather than down to the individual.  You of course could do it down to the individual for transactions that may take a while and you don't care (which actually is a lot of them, any time someone writes a check, it's pretty much the same thing).  A separate solution would be needed for more instant purchases, which may be fine, but if you end up with 50 different implementations, it starts to look more like the current system, transaction fees will creep back in, etc...  But maybe that's ok.

[Mike Hearn]

You can just connect to the backbone nodes and verify that they have received and accepted the transaction you're interested in. If enough miners expose the fact that they are miners and let people check their tx acceptance easily, you can be pretty sure it'll confirm sooner or later, even if there are no confirmations.

Exception: Finney attack. Solution: don't rely on 0-conf spends for high value transactions.

[MoonShadow]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

[tomcollins]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

[MoonShadow]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

[tomcollins]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

[Alex Beckenham]

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

I'm not saying the design is perfect, but there's a big difference between the principle rules of the design and the actual coded and released software.

p.s. Can you design a better formula for the area of a circle than pie are squared?

[MoonShadow]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

We were not discussing the code, but the protocol.

[wb3]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

10 Print "Hello World";
20 Goto 10


Hello World.bas v0.1   It was Perfect. 

[tomcollins]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

We were not discussing the code, but the protocol.

Even protocols are improved upon all the time.  They work *good enough* for a while, then someone comes up with something better.  I'm not trying to badmouth bitcoin.  Everything I've seen with it so far is *really* good.  But there's almost always room for improvement.  Unless you want to talk about trivial hello world programs.

[tomcollins]

Perhaps the one vote per CPU principle is wrong. 

Care to offer an alternative?

I'm just starting to understand how it works.  However, I don't think we should assume everything is perfect as is.

I, for one, never assumed that until after I understood the system, and realized it's elegance.  I seriously doubt that anyone can come up with a better system.

Really?  It might be the first time in the history of computer software that a 0.x release was perfect.

10 Print "Hello World";
20 Goto 10


Hello World.bas v0.1   It was Perfect. 

No, not perfect.  Performance is not optimal, for example (it might be for Basic).  Plus the semi-colon is valid syntax?   If you want to get into nittery, I can too.