Right now it takes 6 confirmations, which takes about an hour to verify a transaction. Will the rate at which transactions confirm become faster over time?
No. The average time per confirmation will always be about 10 minutes (but it's possible that the variance will be lower in the future). And the number of confirmations required to prevent double-spending by an agent with a given hashrate will also not change (6 is an arbitrary number reflecting a "low enough" probability for someone with a "high enough" hashrate).
What will change is services to bridge the gap. There will be split-key eWallets which cannot steal your money on one hand, and can have trusted green addresses on the other; and there will be insurance agents such as https://zipconf.com/ that absorb confirmation risk based on their model of the probabilities of double-spending.
In the future mining rewards will be based on transaction fees, which gradually increase while waiting for a block to be found. If miners wait until fees accumulate before doing active work, there will be less variance in the time it takes to find a block. May 5, 2012 at 17:52
Isn't it true that these "insurance agents" could easily be singled out and targeted by double-spending attackers? In other words, they would crash and go near-bankrupt the moment someone decides to attack them right?– PacerierMar 4, 2014 at 7:15
@Pacerier: No, because their risk management strategy will be adaptive. They will only have a certain amount of coins at risk at any time. If they're being targeted for double-spending they will quickly increase their parameters to make further attacks more difficult. Attackers have limited ability to attack (based on their hashrate) and the insurer's fees will depend on the probability of double-spending success. Also, the insurer can work completely behind the scenes, so the attacker would not know the specific entity to attack. Mar 4, 2014 at 8:23
there's no way the insurer could hide the IP addresses of its nodes right? Thus, the attacker(s) only have to ensure that they coordinated attack network is stationed near the insurer's nodes to completely bring the insurer's business to a grinding halt isn't it?– PacerierMar 4, 2014 at 10:06
The attacker doesn't need to know there even is an insurer. He gets an address from the business and he doesn't know if there is an insurer who is really in control of it. Tor could be used to hide the IP address. Network topology attacks are different from hashrate attacks. The insurer would do well to have access to several nodes around the globe to ensure an accurate view of the blockchain. Anyway, even if there are some potential vulnerabilities to explore, this is getting beyond the scope of SE comments. Mar 4, 2014 at 13:47
Actually the amount of confirmations is seperate from verification. The more confirmations a transaction has the more certain a transaction is. The point where you say it is "verified" is simply the point where you trust it sufficiently.
When do you trust it? For a person this it's a feeling in your underbelly. How fishy is a certain deal? How trustworthy is the person transacting? How are his/her technical capabilities? How gullible is that person? For companies the equation is more exact, but can still be chosen. Can we take the loss if this was a trick? What is the chance that a transaction is fake after X confirmations and would it be more profitable to have someone cheat us every so often, if it makes our service faster? The perfect one is "Would an attack have been more expensive than the value of the transactions in the block in which they were created and those after?".
The notion of six is certain is a fallacy. However after the third confirmation this is a true 51% attack which is fairly hard to do. So six is abundantly secure.
http://bitcoinwatch.com/ now estimates the PetaFLOPS within the network's capabilities to be nearly 150. In January renting 240 Teraflops came at a price of 1280$ an hour. To get 75% of the current network's hashrate for half an hour one would have to spent 150000/240*1280*.5 = 400 000 USD's. So unless you're dealing with fairly huge numbers, 3 confirmations suffice. Edit: because the hash complexity doesn't grow every block it is 3 confirmations or 35 minutes, whichever takes longer. This should dampen the attacker's ability to burst a few blocks within a short period of time. The additional 5 to ensure sync. If you want that 400k limit you require an additional block to ensure the previous 3 were okay.
The gambling site satoshiDICE has an interesting take on this. They accept bets immediately, with zero confirmations, and pay out immediately if you win. This may seem risky, but there's a trick:
Part of your winnings are paid with the amount you sent as your bet. So if your bet was a double spend, and ends up not making it into the blockchain then neither do your winnings.
I thought that was quite a clever take on the whole question of how many confirmations is enough.
Oh, and to answer the question, each confirmation takes 10 minutes by design. If confirmations start coming faster than every 10 minutes then the network adjusts the difficulty of finding a block to slow down the confirmation rate. Similarly if confirmations are taking longer than 10 minutes then the network reduces the difficulty of finding blocks.
It may be in time that people start trusting transactions with 4 or 5 confirmations, or maybe they're get more cautious and start waiting for 10 confirmations. But that's nothing to do with the Bitcoin network - that's just people and their perception of risk vs. reward.
I don't quite get this... if you were trying to double spend on satoshi dice, you'd only do it if you lost. How does paying winnings out of the bet prevent the loser from double-spending his losses?– BrianApr 9, 2014 at 14:24
@Brian Clever question.. Anybody got an idea?– EralpBJul 7, 2017 at 12:47
No, it probably won't. 6 confirmations, or 1 hour is considered a standard amount of time required for any Bitcoin-like crypto currency to ensure a transaction will not be reversed. The time to generate a Block will not change without changing the protocol (which is unlikely to happen), so one would still require an hour to generate those 6 confirmations.
However, even now you can see 0 confirmations transactions appearing in your client in seconds, and it is only up to you to decide when you consider that money secure. Recently 4 blocks were replaced by a miner with a big amount of hash power, meaning transactions in those abandoned blocks were vulnerable to double-spend attacks. However, such cases are rare.
Moreover, even right now some people are working hard on making the confirmation problems less bothersome to the users. Some want to establish some assurance from pools that would promise to include a transaction in their next block, other build bank-like systems that would process internal transactions without the need for blocks (currently you can do that between MtGox's accounts for example).
Generally, as a user one normally doesn't need faster transaction confirmations as double-spend attacks are not that frequent (not to mention detectable within a couple seconds in most cases) and one rarely needs to provide something to the receiver on the spot. It is mostly an issue for micropayment trasaction providers that need to clear an operation within seconds, not being able to wait even for 1 confirmation.
Could you provide a source for the 4 replaced blocks? It seems like a fairly huge achievement.– LodewijkMay 4, 2012 at 20:29
@Lodewijk updated the answer. May 5, 2012 at 0:49