Topic: Are 6 confirmations really that necessary (Read 1088 times)
Care to tell us the probability of an attack right now since the fork issue started? I bet you will not like the numbers.
There's nothing magic about the number 6 - it is simply an arbitrary choice of 1 hour's worth of blocks.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
With two confirmations you would have to mine two blocks in a row with your conflicting transaction before you spend. That's much more rare, but still statistically possible to do at least on very rare occasions, and might be viable for high value, very low friction transactions.
By 6 confirmations it simply won't work. The frequency that you'll just happen to mine six blocks before the rest of the network gets one is extremely low unless you have a significant double-digits percentage of global hashpower. At that point you're already close to a 51% attack.
On the other hand, 2 confirmations is usually enough for low value transactions involving nonfungible products.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
With two confirmations you would have to mine two blocks in a row with your conflicting transaction before you spend. That's much more rare, but still statistically possible to do at least on very rare occasions, and might be viable for high value, very low friction transactions.
By 6 confirmations it simply won't work. The frequency that you'll just happen to mine six blocks before the rest of the network gets one is extremely low unless you have a significant double-digits percentage of global hashpower. At that point you're already close to a 51% attack.
On the other hand, 2 confirmations is usually enough for low value transactions involving nonfungible products.
False. The number of confirmations determines the probability of attack, not the time. The time is irrelevant because Bitcoin doesn't care about time. 6 confirmations is an arbitrary choice, but it is not chosen because it is 1 hour's worth of blocks. In fact, recently, this time has been closer to 50 minutes.
Now it is like more than 12+ confrms.....
Well, this is timely. About an hour ago, there was a blockchain fork due to a subtle difference in the 0.7 and 0.8 clients. The offending block was 225430. Around the time block 225433 was mined, all the biggest mining pool operators were contacted and told to revert back to the 0.7 chain while the issue was being looked into.
Meaning, if you had accepted a transaction with only 4 confirmations using an 0.8 client, your transaction would have later disappeared. Waiting six confirmations is a hedge for when stuff like this comes up.
Meaning, if you had accepted a transaction with only 4 confirmations using an 0.8 client, your transaction would have later disappeared. Waiting six confirmations is a hedge for when stuff like this comes up.
Well not exactly. The transaction would exist on the 0.7 chain as well. It may not be a block yet but it would at the very least exists as an unconfirmed tx.
Well, this is timely. About an hour ago, there was a blockchain fork due to a subtle difference in the 0.7 and 0.8 clients. The offending block was 225430. Around the time block 225433 was mined, all the biggest mining pool operators were contacted and told to revert back to the 0.7 chain while the issue was being looked into.
Meaning, if you had accepted a transaction with only 4 confirmations using an 0.8 client, your transaction would have later disappeared. Waiting six confirmations is a hedge for when stuff like this comes up.
Meaning, if you had accepted a transaction with only 4 confirmations using an 0.8 client, your transaction would have later disappeared. Waiting six confirmations is a hedge for when stuff like this comes up.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend.
That's now how Finney attacks work. You can only Finney attack an unconfirmed transaction, not one that already appeared in a block.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
There's nothing magic about the number 6 - it is simply an arbitrary choice of 1 hour's worth of blocks.
If you only require 1 confirmation it's very easy to perform a Finney attack.
Theory. No proof. If you only require 1 confirmation it's very easy to perform a Finney attack.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
No, it's not easy to perform Finney attack. It is either economical for you, or not. E.g. for $1 worth tx Finney attack is too expensive. Even unconfirmed double spend can be detected within seconds (otherwise it's unlikely it will come faster to the miners than the original tx), so people have no problem accepting unconfirmed transactions for sub-$10 payments (e.g. coindl.com).
On the other hand, when you buy something for $1000, it is a less frequent purchase and maybe requires physical shipping. So waiting an hour or two for several confirmations increases security and does not add any hassle for the client (he would wait for couple of days anyway, 1 hour delay won't change anything). It can also be used as a feature. Imagine, you order a macbook for $1500 from Apple. They will not start shipping it until they get, say, 12 confirmations (about 2 hours). During that time you may cancel your order and after 12 confirmations Apple will send your money back to you. This is exactly how "one click purchase" works in Amazon: you click a button without filling any forms, they wait some time before shipping, so you can cancel (e.g. accidental click), then ship. But in case of BTC, the delay is not an arbitrary number, but a measure of security.
There's nothing magic about the number 6 - it is simply an arbitrary choice of 1 hour's worth of blocks.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
With two confirmations you would have to mine two blocks in a row with your conflicting transaction before you spend. That's much more rare, but still statistically possible to do at least on very rare occasions, and might be viable for high value, very low friction transactions.
By 6 confirmations it simply won't work. The frequency that you'll just happen to mine six blocks before the rest of the network gets one is extremely low unless you have a significant double-digits percentage of global hashpower. At that point you're already close to a 51% attack.
On the other hand, 2 confirmations is usually enough for low value transactions involving nonfungible products.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
With two confirmations you would have to mine two blocks in a row with your conflicting transaction before you spend. That's much more rare, but still statistically possible to do at least on very rare occasions, and might be viable for high value, very low friction transactions.
By 6 confirmations it simply won't work. The frequency that you'll just happen to mine six blocks before the rest of the network gets one is extremely low unless you have a significant double-digits percentage of global hashpower. At that point you're already close to a 51% attack.
On the other hand, 2 confirmations is usually enough for low value transactions involving nonfungible products.
We've all read about the 0 confirmation double spend, but I have yet to see ANYONE cheat a transaction with so much as 1 confirmation, let alone 2, 3, 4, 5, or 6.
So why are 6 confirmations touted as full proof? It sounds like someone arbitrarily picked 1 hr as the magic number. If you had the power to manipulate a transaction with even 2 confirmations, wouldn't the bitcoin network have far bigger problems than even 6 confirmations could solve?
So why are 6 confirmations touted as full proof? It sounds like someone arbitrarily picked 1 hr as the magic number. If you had the power to manipulate a transaction with even 2 confirmations, wouldn't the bitcoin network have far bigger problems than even 6 confirmations could solve?
Jump to: