Bitcoin Forum

Hello,

Is there a way to use time constraints along with number of confirmations to calculate the probability of a transaction being legit ?

Just wait for 6, 7, 10, confirmations doesn't seems to make sense (mathematically at least), since given enough time any number of computing power will produce the confirmations needed (of course i can use 120 confirmations but no customer want to wait that long), but as I'm kind of new to bitcoins maybe i`m missing something?

Maybe will be a incentive to merchants if there is a more accurate approach on transaction confirmation.

Imagine if we calculate the time an attacker that "owns"  2/3  (btcguild + deepbit) of the hashing network will take to produce the false confirmations and set a time upper bound based on that number.

I know block finding involves luck, so 1 confirmation may never be viable, but the probability of finding, say, 3 confirmations given the attacker maximum strength seems to be calculable.

Regards,
Celso.

When you use the RPC API, you can choose the number of confirmations that you require yourself, depending on the perceived risk. 6 is just a convenient default.

Yes, I'm using 6 for the moment, but, as a newbie, I vividly remember the "fear" of my first transfer not appearing at my mtgox account.

I think the average Joe is already scared enough of using this "crypto currency", so finding a way to reduce the transfer waiting time for my customers will be very well welcomed (structural, not "insurance for a fee" based ones).

So— using time and delaying confirmation when things look weird would be a useful enhancement, but its less important that I think you think it is:

If, say, btcguild goes evil and starts mining a fork which reverses and respends— then yes, given enough time they will mine six blocks.  _BUT_ in that same time the rest of the network would have mined 14 and so the chain produced by the rest of the network would be much larger and your client would ignore the chain produced by btcguild.

So the only way this would matter is if they were also able to get enough control of your network connectivity that they could prevent you from hearing about the blocks produced by the rest of the network.  The fact that this isn't impossible is why some additional logic would be useful.  (Along with peer rotation, explicitly configured trusted peers, etc)  But the fact that both significant hashpower and the network attack are required is why it's less of an issue than you might guess.

Thanks for the explanation!

In fact I'm trying to require only the absolute minimum confirmations so the site users will have a nicer experience using the site. Just putting 6 out of the blue on my code sounded too random.

If i understood correctly any fork will only be viable if the evil persons involved have more hash power than all the network combined, because the client will ignore the shorter blocks.

So why the "standard" number of confirmations is, lets say, 2, instead of those larger numbers people out there are using?

What is the probability of some malicious attacker find 2 blocks in a row having, lets say, 40% of the total network hash on his hands ?

The mean case is easy, supposing the false blocks will not be discarded by my client because of some network tampering, the attacker will only be able to generate 4 blocks per hour, so if 2 confirmations take more than 30 minutes something is wrong and i wait more confirmations, if 2 confirmations take 15 minutes or less the transaction is legitimate.

The problem here is the "lucky" attacker who can guess 2 blocks out of luck, someone did the math or can help me calculate those odds ? I did some search and found nothing.

Thanks.