Topic: Can/Will Transactions Ever Be Processed Faster Than Every 10 Minutes? (Read 6471 times)

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.

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.

10 Print "Hello World";
20 Goto 10


Hello World.bas v0.1   It was Perfect. 

We were not discussing the code, but the protocol.

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?

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

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.

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

Care to offer an alternative?

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.

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.

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.

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.

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.

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. 

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

No. The only timestamps in Bitcoin are in the blocks.

I was wrong - the client does add a timestamp to transactions it puts into its wallet. I was only looking at transactions as they appear "on the wire" - i.e. being broadcast just after they're created.

I believe the client timestamps every transaction it receives at the time it first gets it.

Is there a time stamp of when the transfer was initiated?

Without major modifications the average time between blocks will be 10 minutes. This does not mean that the average time from you making a transaction to it getting it's first confirm will necessarily be 10 minutes. This is because in the future when the fixed block reward is less important and fees are more important hashing power supplied will be variable and the more fee tx that are queued up they faster they get confirmed. There will probably be some time of day and day of week effects too, but maybe only minor. You can even have some control by offering a huge fee that will get previously marginally unprofitable miners to switch on.