The math behind confirmations?

[Berk]

Can you guys help me understand the math behind 6 confirmations? I have read that at 6 confirmations there is less than a 0.1% chance of a successful attack but I cannot remember where I read that. I have always wondered why the standard of waiting for confirmations to prevent a double spend attack was always 6 confirmations. I am aware that some places do allow at least 1 confirmation but if you accept 1 confirmation what percentage difference compared to 6 confirmations would I be taking a big risk by accepting 1 confirmations compared to 6?.

I've searched around the internet and most just say that it reduces the chances but the exact numbers haven't been declared. For someone who might be developing a Bitcoin payment system or accepting Bitcoin on their website or for a service this should probably be more clear than it is. We should not blindly trust because it is the standard. I do not doubt that the standard has solid reasons I am more intrigued on why we have come up with that magic number. Does 6 confirmations reduce an attack by >99%?

I ask because the wiki is no longer up to date but this information was answered before on there. Take this quote as an example:

Transactions with 0/unconfirmed can be reversed with not too much cost via Finney attack and race attack, but in some cases may still be acceptable especially for low-value goods and services, or ones which can be clawed back.

For transactions with confirmations, the website (https://people.xiph.org/~greg/attack_success.html) can be used to calculate the probability of a successful doublespend given a hashrate proportion and number of confirmations. Note that in the reality of bitcoin mining today, more than 6 confirmations are required. (60 confirmations to have <1% odds of succeeding against an entity with 40% hash power). See Section 11 of the (https://bitcoin.org/bitcoin.pdf bitcoin whitepaper) for the AttackerSuccessProbability formula.

The only problem with this quote is that it talks about more confirmations preventing an attack which I understand but it talks about up to 60 confirmations to fully mitigate the attack so why are we using a 6 confirmation standard when there is still a chance of an attack succeeding is it because it is so low chance that it realistically will never happen?

The reference https://people.xiph.org/~greg/attack_success.html returns a error and does not have the information any more.

Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

The Bitcoin whitepaper has this information which I assume is related to confirmations but this does not make any sense to me. What is Satoshi trying to say here?

[1714973741]

1714973741

[1714973741]

1714973741

[1714973741]

1714973741

[1714973741]

1714973741

[bitmover]

Can you guys help me understand the math behind 6 confirmations? I have read that at 6 confirmations there is less than a 0.1% chance of a successful attack but I cannot remember where I read that. I have always wondered why the standard of waiting for confirmations to prevent a double spend attack was always 6 confirmations. I am aware that some places do allow at least 1 confirmation but if you accept 1 confirmation what percentage difference compared to 6 confirmations would I be taking a big risk by accepting 1 confirmations compared to 6?.

2 confirmations is more than enough for the bitcoin network, unless you are talking about millions of dollars.

When you make a transaction, that transaction is recorded in the blockchain.  Each subsequent block that is mined adds one more confirmation  to that transaction.

A successful attacker will need to mine all blocks again since your transaction. It is considered  permanent and practically impossible for an attacker to mine 6 blocks faster than the whole network. This is why 6 confirmations is enough.

If you are talking about altcoins, like bch or brg which have significant lower hashrate, the 6 confirmation rule is not enough.

[n0nce]

Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

The Bitcoin whitepaper has this information which I assume is related to confirmations but this does not make any sense to me. What is Satoshi trying to say here?

He is showing an example: q = probability the attacker finds the next block.
You get a table for q=0.1, so basically an attacker with 10% of the hashrate, and the probability of catching up with the real chain of depth z.

He sampled the same table for q=0.3 (30% of the hashrate) as well.

The last part shows if you want this probability to be under 0.1%, with an attacker that has 10% of the hashrate, you need to wait for 5 confirmations, or if an attacker has 30% of the hashrate you need 24 confirmations and so on.

Can you guys help me understand the math behind 6 confirmations? I have read that at 6 confirmations there is less than a 0.1% chance of a successful attack but I cannot remember where I read that. I have always wondered why the standard of waiting for confirmations to prevent a double spend attack was always 6 confirmations. I am aware that some places do allow at least 1 confirmation but if you accept 1 confirmation what percentage difference compared to 6 confirmations would I be taking a big risk by accepting 1 confirmations compared to 6?.

I'd say that it's fairly close to the figure 5 that is needed if we assume there is a miner or pool with 10% of the hashrate, so that's probably the assumption made when deciding for number 6, as well as it being easy to remember since 6 blocks in Bitcoin take exactly one hour on average.

[odolvlobo]

Here is more recent work: https://arxiv.org/pdf/1912.06412.pdf

[ranochigo]

The probability of any miner finding a block is a Poisson process, where the probability of an attacker finding a block is relative to the hashrate that the rest of the network. Hence, you can see that the expected value of the number of blocks being found by an attacker is z(q/p), where for eg. if you have 50% of the hashrate, you are likely to find the next block 50% of the time.

What the rest of the simulation is would be to calculate calculate the probability of the attacker getting the next block given that he has also mined the last z blocks. The reason why Poisson distribution is used, is because the probability of getting a block with q percentage of the hashrate is not an uniform distribution, and hence we have to use Poisson distribution to approximate the number of blocks to catch up.

The point here is that the attacker needs to outpace the network, by catching up with the number of blocks that it is behind on the network. The re-organization has to be strictly mined such that the successive blocks all belongs to the attacker. As such, this calculation assumes that the attacker is simultaneously mining with the network and is able to mine d successive blocks to outrun the network. This assumes that the miner isn't selfish mining, which would skew the probability significantly.

Now, if you observe from the results, 6 confirmations only provide a 0.1% chance of the miner doing a double spend assuming that the attacker only controls 10% of the network hashrate. This number increases with proportion of the network hashrate that the attacker hold. 10% of the hashrate is fairly large, and that is also where game theory comes into play; attackers are unlikely to be willing to waste more than that to double spend a transaction and the probability of success is reasonably low across various proportion of the hashrate as well.

It is not correct that the probability of double spends beyond 6 confirmations is 0.1% at all of the scenarios, but if the attacker controls 51% of the hashrate, it will always be a 100% probability of success because it is always able to generate blocks faster than the rest of the network.

[NotATether]

Can you guys help me understand the math behind 6 confirmations? I have read that at 6 confirmations there is less than a 0.1% chance of a successful attack but I cannot remember where I read that. I have always wondered why the standard of waiting for confirmations to prevent a double spend attack was always 6 confirmations. I am aware that some places do allow at least 1 confirmation but if you accept 1 confirmation what percentage difference compared to 6 confirmations would I be taking a big risk by accepting 1 confirmations compared to 6?.

I'd say that it's fairly close to the figure 5 that is needed if we assume there is a miner or pool with 10% of the hashrate, so that's probably the assumption made when deciding for number 6, as well as it being easy to remember since 6 blocks in Bitcoin take exactly one hour on average.

That makes sense, because the largest pool (still F2Pool I believe) only has 13ish% of the total hashrate, so the advice of 6 confirms reflects the reality of the mining landscape.

It would be difficult, but not impossible, for an owner of multiple large pools to make them collude and thus require additional confirmations, but tensions inside the management resisting such an operation keep this a strictly theoretical scenario.

[o_e_l_e_o]

The reference https://people.xiph.org/~greg/attack_success.html returns a error and does not have the information any more.

You can still access an archived but fully functioning version of this page here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html

You can play around with the numbers yourself to understand things. In the top box enter the proportion of the hash rate that an attacker has. So if they have 10%, enter 0.1. For 35%, enter 0.35. And so on.
In the second box, enter the number of confirmations they are attempting to reverse.
Multiply the result by 100 to get the chance of an attack being successful.

So if you enter 0.1 and 6, you get 0.0002. This means that an attacker with 10% of the hashrate would have a 0.02% chance to reverse 6 confirmations.

[rlirs]

Although Bitcoin paper considered an attacker when doing probability calculation, competing blocks can be mined randomly without ill intentions. These competing blocks will be broadcast to the network and someone sending large amount should watch for a possible blockchain reorganization. If my transaction has one or two confirmations and there are no competing blocks that don't have my transaction then I am pretty sure that my transaction went through.

[BlackHatCoiner]

These competing blocks will be broadcast to the network and someone sending large amount should watch for a possible blockchain reorganization.

Still, though. Once the chain gets reorged, which happens usually for 1 block, the transactions of the block that was dumped become unconfirmed and return to the mempool. Now they can get mined within the next blocks. If I was going to receive a lot of money, I'd ask to disable RBF and have at least 1 confirmation. Disabling RBF means you can't (practically) double-spend your unconfirmed transaction.

If my transaction has one or two confirmations and there are no competing blocks that don't have my transaction then I am pretty sure that my transaction went through.

That's true. Chain reorgs, as I've said, usually affect the last block. I don't believe it has ever happened for 2 or more.

[ranochigo]

Still, though. Once the chain gets reorged, which happens usually for 1 block, the transactions of the block that was dumped become unconfirmed and return to the mempool. Now they can get mined within the next blocks. If I was going to receive a lot of money, I'd ask to disable RBF and have at least 1 confirmation. Disabling RBF means you can't (practically) double-spend your unconfirmed transaction.

Not necessary. Disabling RBF does nothing other than preventing another miner from potentially mining a competing transaction by chance. If there is any ill-intent present, then there is no point asking them to disable RBF because they would have gone a little further to try to get their transaction to get double spent. There's this misconception that disabling RBF prevents any easy double spending but that is false; the primary purpose of RBF is to allow users to replace their transaction with another that spends a higher fee and disabling defeats that purpose especially in instances where fees spike were to occur.

The one and only way to be certain is to wait for 3 or more confirmations (if you are that paranoid). Otherwise, there is little to no security benefits. Anyways, stale block candidates are easily detectable with a well-connected node. It isn't a big problem.

That's true. Chain reorgs, as I've said, usually affect the last block. I don't believe it has ever happened for 2 or more.

Record is about 6 in a very specific scenario, IIRC. Otherwise, normal circumstances would be about 1.

[BlackHatCoiner]

If there is any ill-intent present, then there is no point asking them to disable RBF because they would have gone a little further to try to get their transaction to get double spent.

That's true, just wait for a couple confirmations and you're fine. RBF or not.

There's this misconception that disabling RBF prevents any easy double spending but that is false; the primary purpose of RBF is to allow users to replace their transaction with another that spends a higher fee and disabling defeats that purposes especially in instances where fees spike were to occur.

Yes, but it also makes it difficult to reverse or replace the transaction. If I was a merchant I'd rather accepting a low-fee unconfirmed non-RBF transaction than a high-fee with RBF enabled, because the latter makes double-spend easygoing.

[ranochigo]

Yes, but it also makes it difficult to reverse or replace the transaction. If I was a merchant I'd rather accepting a low-fee unconfirmed non-RBF transaction than a high-fee with RBF enabled, because the latter makes double-spend easygoing.

I don't recommend people accepting unconfirmed transactions, because you are creating potential problems for yourself and your customer. If it remains unconfirmed for an extended period of time, you won't be able to spend it and neither will the customer be able to spend their change. The latter is more than fine, because you should be accepting confirmed transactions. The volatility of the fees in recent times hasn't been very kind and there is still a good enough possibility for the customer to be able to push it directly to a mining pool, RBF or not. Which is what my point on this "false sense of security" about.

If you absolutely have to accept unconfirmed near instant TXes, do so via lightning network. Though 10 minutes for a confirmation isn't always undesirable.

[BlackHatCoiner]

If it remains unconfirmed for an extended period of time, you won't be able to spend it and neither will the customer be able to spend their change.

If they want to spend their output, they can broadcast a child-pays-for-parent transaction and incentivize the miners to include both.

The volatility of the fees in recent times hasn't been very kind and there is still a good enough possibility for the customer to be able to push it directly to a mining pool, RBF or not.

It really depends on the amount transacted. I, as a merchant again, wouldn't be bothered to accept such unconfirmed transaction for an amount less than $300. I don't believe that a customer would choose to defraud me that way, I find it difficult thing to happen, there's still a decent percentage of uncertainty for the double-spending to occur, and I'd, either way, also accept credit card payments which are far easier to reverse and whose finality takes about 6 months more than a bitcoin transaction does.

Furthermore, "the customer is always right". If he asks for unconfirmed transactions, I might dissatisfy him by disagreeing, which is definitely not a smart move.


For thousands of dollars worth of bitcoin, you should absolutely require at least 1 confirmation.

[PrimeNumber7]

attacker

I don't think the OP is asking about a 51% attack. My understanding of the OP's question is that he is asking about the probability of there being a chain of orphaned blocks that is 6 blocks deep. The OP does use the words "double spend attack", but the context of his question appears to be asking about orphaned blocks.

When a block is found, it will take x amount of time to propagate throughout the network, and if another miner finds a competing block within that time, there is the potential for some of the network to be working on top of one block at height y, and some of the network to be working on top of another block at the time height. If this were to happen, and both parts of the network find block y + 1 within the aforementioned x time, there will be a chain of two orphaned blocks.

Without knowing how long it typically takes for blocks to propagate, it is difficult to calculate the chances of a chain split that is n blocks deep. I do know that the miners, and mining pools have invested heavily in getting their found blocks to the other miners quickly, and over time, the time required for a block to propagate has been reduced.

With the above being said, just because there is a chain of orphaned blocks, it is not necessarily going to be true that there will be a different set of confirmed transactions in each of the blocks. In general, miners will fill their blocks with transactions based on transaction fee rate, so all miners are more or less expected to include the same transaction set in each of their blocks, notwithstanding transactions that were very recently broadcast immediately prior to a block being found.

[ranochigo]

If they want to spend their output, they can broadcast a child-pays-for-parent transaction and incentivize the miners to include both.

CPFP is actually a very inefficient way of 'accelerating' a transaction. The user have to either intentionally make a transaction with a higher fee or do so in a subsequent transaction, provided that the next user doesn't care about the unconfirmed output. Mempool seems to accumulate over time and it would be far more expensive to do a CPFP later than to have an RBF now. I'd very much prefer having the flexibility of doing so without incurring additional costs or time. If I'm the merchant, I'm definitely not looking to wait for a transaction to be confirmed in a day or two.

It really depends on the amount transacted. I, as a merchant again, wouldn't be bothered to accept such unconfirmed transaction for an amount less than $300. I don't believe that a customer would choose defraud me that way, I find it difficult thing to happen, there's still a decent percentage of uncertainty and I'd, either way, also accept credit card payments which are far easier to reverse and whose finality takes about 6 months more than a bitcoin transaction does.

Furthermore, "the customer is always right". If he asks for unconfirmed transactions, I might dissatisfy him by disagreeing, which is definitely not a smart move.

For starters, credit card settlements and Bitcoin transaction finality are completely different and they cannot be equated to be the same. The former has some accountability on both the user and the merchants and there is a case to be contested for most cases, not the main point anyways.

Customers won't be there to defraud you for a cup of coffee or for lunch and it really depends on the risk tolerance. It's either LN or you pay and I make your food, by the time I serve you, the TX should probably be confirmed. I'm not sure if the customers would be willing to do a transaction without RBF, knowing that there is a possibility of the funds being stuck for a while. I won't be comfortable with that and I don't really think it is a good way to manage the risk or neither is it a good trade off, but that might just be me.

A successful attacker will need to mine all blocks again since your transaction. It is considered  permanent and practically impossible for an attacker to mine 6 blocks faster than the whole network. This is why 6 confirmations is enough.

If you are talking about altcoins, like bch or brg which have significant lower hashrate, the 6 confirmation rule is not enough.

Any attacker having more hashrate than the rest of the honest network will always be able to mine any number of blocks more than the rest of the network, given time. The 6 confirmation rule is based on game theory and is not a strictly mathematical concept. 6 confirmations can be enough for any other altcoin, so long as you think the amount being transacted is very much less than the cost of the hashrate for 51% of that network.

[BlackHatCoiner]

CPFP is actually a very inefficient way of 'accelerating' a transaction.

Definitely, RBF is a much efficient way of saying "I want this confirmed", but I'm just pointing out that, even without RBF, you can still use this "bump" feature, without the danger of trivial double-spending.

For starters, credit card settlements and Bitcoin transaction finality are completely different and they cannot be equated to be the same.

They're different, but not completely different. They both satisfy the same need; transaction settlement. And I can compare them, from both merchant's and customer's perspective. What's cheaper for both? Bitcoin, because trust costs. What's more secure for the merchant? Bitcoin, because there are no chargebacks, bank reversal, disputes. What's more private for both? Bitcoin.

Customers won't be there to defraud you for a cup of coffee or for lunch and it really depends on the risk tolerance.

Exactly, which is why I said I would approve an unconfirmed <= $300 worth of bitcoin transaction as settled. For a cup of coffee, though, Lightning is a better solution. But, for supermarket fulled cart, that can't be easily paid with Lightning, since there's high chance of routing failure, and where there's rush, the merchant should accept unconfirmed transactions.

I'd be willing to open a channel with my supermarket, if it was possible, though, and make my purchases instantly. But, that's just me, I can't expect the others behave same like.

[n0nce]

It would be difficult, but not impossible, for an owner of multiple large pools to make them collude and thus require additional confirmations, but tensions inside the management resisting such an operation keep this a strictly theoretical scenario.

Not to speak of the economic cost of this all. If your probability is as low as 0.1% or 1%, it's a big gamble to make, with a lot of money on the line (a big chunk of the mining network in electricity cost for an hour). This only makes sense to double-spend a pretty rare transaction, worth millions or with a very well paying lobbyist / politician (in the case of a censorship-motivated attack).

[BlackHatCoiner]

If your probability is as low as 0.1% or 1%

If you have a 1% probability of reversing the last 6 blocks, then you have about 28.5% 19% of the total hash power. This can happen if a big mining pool decides to. So, yeah, it's a big gamble since that is likely to ruin their huge business.

This only makes sense to double-spend a pretty rare transaction, worth millions or with a very well paying lobbyist / politician

But, what kind of transaction moves so much money and can be successfully double-spent that way, at the same time? I mean, if the USA agreed on paying 10,000 BTC to Putin for, say, buying a lot portion of Russia's gas, and somehow managed to double-spend that, first of all, they wouldn't get any gas since it'd take some days (hundreds of blocks) to deliver, and second, that would probably be the reason to officially set sail to the second cold war.

It makes sense to double-spend only if you do things anonymously or if the seller can't reach you.

[n0nce]

If your probability is as low as 0.1% or 1%

If you have a 1% probability of reversing the last 6 blocks, then you have about 28.5% of the total hash power. That can only happen if there's cooperation between 2 or more of the mining pools. So, yeah, it's a big gamble since that is likely to ruin huge businesses.

Exactly. Even with a third of the hashrate cooperating, and a lot of money on the line, the probability of success will still make it a big gamble to reverse a 6 confirmation transaction.

This only makes sense to double-spend a pretty rare transaction, worth millions or with a very well paying lobbyist / politician

But, what kind of transaction moves so much money and can be successfully double-spent that way, at the same time? I mean, if the USA agreed on paying 10,000 BTC to Putin for, say, buying a lot portion of Russia's gas, and somehow managed to double-spend that, first of all, they wouldn't get any gas since it'd take some days (hundreds of blocks) to deliver, and second, that would probably be the reason to officially set sail to the second cold war.

That's a good point. It would need to be something of very high value that can be transferred with total finality within 6 blocks or roughly one hour's time.

[Dabs]

For all intents and practical purposes up to around 100 BTC or equivalent fiat value, 1 confirmation is good enough.

If you are the one sending from your own wallet (Bitcoin Core, Electrum, Spectre) then you can see your transaction in the mempool and once it has confirmed once or 1 block, you can be sure that whoever you sent it to will get it, even if they want to wait for more than 1 confirmation.

If you are the one receiving it, in your own wallet, same thing.

If you are sending or receiving it using a third party or custodial service, or exchange, then you are subject to whatever number of blocks confirmation they require before they let you use it. Receiving it, may show as pending, and you just wait. Sending it, depending on if they batch your transaction or send it later, you'll also have to wait.

Normally you don't wait more than half an hour to an hour anyway.

To fuss about some transaction not having 6 or 10 confirmations and it's less than the price of a pizza (whether that's back then, or today) is just wasting everyone's time.