Quote from: witcher_sense on Today at 07:56:14 AM

It is not mandatory for every single transaction, it all depends on the amount of money in question. If you are selling a cup of coffee, you can safely accept a transaction with zero confirmations since the cost to attack the network to replace this transaction is significantly higher than the cost of one cup of coffee.

Haha, you're right. But wait I'm only talking about online transaction without involving escrow and also not knowing each other, so it shouldn't be for the equivalent amount for a cup of coffee. But thanks for trying to explain.

Quote from: o_e_l_e_o on Today at 08:03:06 AM

If a single entity controls 51% of the hashrate (which is very unlikely), and can sustain that hashrate indefinitely (which is even more unlikely), then they can theoretically reverse a transaction with any number of confirmations. They would simply mine their own chain in secret which double spends the transaction they want to reverse, and then when their own chain is longer than the main chain they release it to the wider network.
<.....>

Think of confirmations as a continuum. It's not "x is unsafe, y is safe", but rather "1 is fine, 3 is safe, 6 is super safe", and so on. What the individual numbers are depends on your individual risk model and the size of the transaction in question.

o_e_l_e_o, I understand. 51% attacks can be done but with the risk of failure and the cost is quite expensive so that at the same time it will be something that will be difficult to do. I'm not so sure an entity can do it in the future for no apparent reason, but you're right, attacks like this don't need us to think too much about it.

Quote from: BlackHatCoiner on Today at 08:48:33 AM

Someone who owns 51% of the hashrate can reverse any transaction regardless of its confirmations, it's just be a matter of time. They decide what's the correct chain. If they own less than that, then the more the confirmations the more difficult it becomes to catch up.

This probability can be calculated using the C code displayed in the whitepaper:

Code:

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}

Where z is the blocks you expect to be found, q the probability for an attacker to solve those blocks and p the probability for the honest nodes to solve those blocks. Set the proportion of the hash rate and the confirmations accordingly to what you want, here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html

Here's some noteworthy results:

With 30% of the hash rate, you have a ~62% chance to reverse a transaction with 1 confirmation.
With 40% of the hash rate, you have a ~55% chance to reverse a transaction with 5 confirmation.
With 20% of the hash rate, you have a ~10% chance to reverse a transaction with 3 confirmation.

Everything drops off exponentially as confirmations (z) increase. The 6 confirmations have the best security:speed ratio. It takes 1 hour, but even for someone who owns one third of the hash rate, it's improbable for their attack to succeed. (~21% chance)

I'm trying to understand something you're trying to explain about the probability of a 51% attack, which I can understand based on your description of how likely they are to reverse a confirmed transaction. Now I know that you've explained it, but considering the cost and probability of carrying out this attack is very small (a matter of time), I wouldn't think too much into it. Also, thanks for the technical explanation.