6 confirmations questions

[IggySe7ven]

Guys,  I am learning technical side of bitcoin blockchain, I am confused about something.


If it takes 6 blockchain confirmations to confirm a transaction to the network and each confirmation is about 10 minutes,  how come sometimes When I  recieve bitcoin it came faster like 30 min or less?

[AB de Royse777]

You only need 1 confirmation to claim the coins that it's yours. Bitcoin transactions are technically reversible but it cost enormous amount of computing power that once a tx receives 6 confirmation it becomes impossible to reverse. The money that costs to do it is not just reasonable.

[BlackHatCoiner]

It doesn't need 6 confirmations for your transaction to get confirmed from the network. It gets confirmed from the 1st confirmation.

What 6 confirmations do:
Practically impossible for someone to exclude your transaction from the blockchain. The procedure of changing the way a block has been submitted to the network is called 51% attack.

how come sometimes When I  recieve bitcoin it came faster like 30 min or less?

As I mentioned, you get your bitcoins since the transaction has 1 confirmation. Imagine that the 6 confirmations secure your transaction that will not change or get removed in the future.

[bob123]

If it takes 6 blockchain confirmations to confirm a transaction to the network and each confirmation is about 10 minutes,  how come sometimes When I  recieve bitcoin it came faster like 30 min or less?

A transaction is confirmed once it has been included into a block.
Each subsequent block adds 1 confirmation to that transaction. A bitcoin transaction is considered to be completely irreversible after 6 confirmations.
If you are dealing with lots of money, wait for 6 confirmations. For standard transactions or transactions with a lower amount (less than a few thousands), 1-3 confirmations are absolutely fine.

Regarding your second question.. the target (and therefore the difficulty) is chosen so that on average(!) there is a block each 10 minutes.
It is very well possible that we have 3 blocks within 10 minutes, or 2 blocks withon 60 minutes. After all it is pretty random, but the average will be ~10 minutes.

[logfiles]

The average time for each bitcoin block confirmation is 10 minutes but the block confirmation time is in actual sense random.
Have a look at this block explorer to see how random it is; https://mempool.space

Here's a little overview of the last 7 mined blocks at the moment, notice how random the time interval is between the mined blocks

[BlackHatCoiner]

If you are dealing with lots of money, wait for 6 confirmations. For standard transactions or transactions with a lower amount (less than a few thousands), 1-3 confirmations are absolutely fine.

Is there any person that lost lots of money by waiting for only 1 confirmation? Because I've heard that a 51% attack has never happened before.

[AB de Royse777]

Is there any person that lost lots of money by waiting for only 1 confirmation?

Not sure how much it will cost in the computing power but to reverse a tx with only 1 confirmation it will cost good amount of money. So maybe it's not worth to try for few bitcoin.

Because I've heard that a 51% attack has never happened before.

This is where we stand. Source : https://btc.com/stats/pool?pool_mode=all

[BlackHatCoiner]

Guys, maybe I am not understanding something , I am  learning this course on "IvantheTech" its called Bitcoin101

and there they talk like Miners in different parts of the world can simultaneously mine a block and send it to nodes and etc but then one of the 2 miners that send different block will eventually get rejected, that when the next block is mined after the block with my transaction on it that if there is 2 groups of nodes with different versions of same block that whichever group adds another block next will get accepted because blockchain accepts the longest chain and so the other  version will eventually become "stale blocks  and be moved to mempool".

I dont understand , how do we have a choice how many confirmations we can wait? I thought If I send bitcoin to another adress, the other adress will not see it on the chain until 6 confirmations.  Do we actually have a choise how many confirmations we  recieve until we can send that  transaction to another another adress without it being denied?

With 6 confirmations you ensure that miners will not mine simultaneously the same blocks. You do that with fewer blocks too, but this is not the reason why 6 confirmations are needed. As you can see from @Royse777 post, the power of unknown (and known) cpu pools are huge. Let's say that there is a small possibility for a pool to mine 2 blocks at the same minute and your transaction has 1 confirmation. Yes, they could remove your transaction from the blockchain. With 6, though, it's impossible. It requires more than half of that CPU power. Satoshi wrote it on his whitepaper [11) Calculations]

I dont understand , how do we have a choice how many confirmations we can wait? I thought If I send bitcoin to another adress, the other adress will not see it on the chain until 6 confirmations.  Do we actually have a choise how many confirmations we  recieve until we can send that  transaction to another another adress without it being denied?

When someone sends you bitcoins, even if the transaction is not confirmed, you can spend them. The problem is that, in order for your transaction to be confirmed, the first transaction must be confirmed first.

No you don't have to wait 6 confirmations to spend your funds.

[NotATether]

Guys,  I am learning technical side of bitcoin blockchain, I am confused about something.


If it takes 6 blockchain confirmations to confirm a transaction to the network and each confirmation is about 10 minutes,  how come sometimes When I  recieve bitcoin it came faster like 30 min or less?

The time to mine each block is irregular and proportional to a Poisson distribution. According to this Bitcoin Wiki chart, about 55% of all blocks take 0 to 10 minutes to be made, and somewhere around 5% of blocks take more than 30 minutes to mine. So in your case you probably made a transaction that was included in 6 subsequent blocks all mined quickly.



As others already said, you only need 1 confirmation for the transaction to be in the network. But the more confirmations you wait for, the total waiting time averages out, and the >30 minute waiting times of the 5% compensate for the quickly mined 55%.

If you are dealing with lots of money, wait for 6 confirmations. For standard transactions or transactions with a lower amount (less than a few thousands), 1-3 confirmations are absolutely fine.

Is there any person that lost lots of money by waiting for only 1 confirmation? Because I've heard that a 51% attack has never happened before.

You don't need a 51% attack to break 1 confirmation, there is another attack that works on blocks with one confirmation called a vector76 attack, you need a large stash of bitcoin to create a spending transaction to the node you want to defraud, mine a block, and broadcast it only to the target, and only right after the rest of the miners add another block to their blockchain.

At that point, the spending tx wasn't included in the other miners' blocks so it's invalid to them. As soon as the target makes a transaction to the attacker, which is valid on both chains:

- On the attacker's rejected chain, there is a (not broadcasted) spend, and a broadcasted receive
- On the main chain there is only a broadcasted receive

The broadcasted receive goes to the mempool, is scheduled to be included in the next block which will be visible by all of the nodes, including the attacker and victim. So: The spend wasn't valid on the main chain to begin with, but the receive was, and the victim was cheated out of a lot of bitcoin.

The way I described it, only works on full nodes with few connections to other peers. It can also find a weakly-connected node used by SPV wallets to attack, which will allow them to victimize any of the wallet users connecting to it. And it may or may not work on web wallets, it's unknown which nodes are tied to which web wallets. And this attacking process is extremely difficult to carry out because it's time sensitive and relies on a race condition (which block is seen first) which may not work.

[crwth]

Just like what others said, you only need one confirmation. If you have a wallet that receives a transaction, usually, it shows you a clock that is filling up while you get more confirmation. In the settings, IIRC, you could set the amount of proof you need for ”you” to consider it's a full-proof transaction.

On the other hand, if you have a custodial wallet, it depends on how many confirmations it receives before they credit your account. In my experience, wallets require 3-6 confirmation to be credited that amount. For services, one confirmation is enough.

[IggySe7ven]

Ok, that cleared up alot of things I didn't understand, thanks everyone.

[pooya87]

replace the misleading term "confirmation" with a more technically correct term "depth" and a lot of the confusion should go away.
those numbers always represent the depth of the block containing the transaction compared to the head. when it is showing 1 it means it is the head (there is 0 blocks after it). when it shows 6 it means the transaction is 6 blocks deep (5 blocks came after it).
and as it was pointed out, this "depth" is a measure of how costly it would be to reverse those blocks to reach that deep transaction.

[o_e_l_e_o]

Is there any person that lost lots of money by waiting for only 1 confirmation? Because I've heard that a 51% attack has never happened before.

You don't need 51% of the hashrate to have a reasonable chance of overturning a single confirmation. You can see the relevant calculations in "Section 11. Calculations" of the bitcoin whitepaper.

If someone has 51% of the hashrate (and can sustain this for enough time), then they have a 100% chance to overcome 1 confirmation (or 6, or 20, or 100, provided they can sustain this proportion of the hashrate). However, with only a 1 block deficit, a much lower percent of the hashrate can still give a reasonable chance. 40% of the hashrate has a 82.9% chance to overcome a 1 block deficit, and even only 5% of the hashrate still has a 10.1% chance.

This chance falls exponentially with each additional block. After 6 confirmations, 5% of the hashrate falls from a 10.1% chance to a 0.00038% chance.

[tranthidung]

Is there any person that lost lots of money by waiting for only 1 confirmation? Because I've heard that a 51% attack has never happened before.

Risk is something might happen and protection is to avoid loss when risk become real attacks.

Not sure how much it will cost in the computing power but to reverse a tx with only 1 confirmation it will cost good amount of money. So maybe it's not worth to try for few bitcoin.

The estimated cost for 1-hour attack on Bitcoin network is $590,410, according to PoW 51% Attack Cost. Risk of attacks when happen will be for new transactions. If yours are old one (1 month⁺), your fund will mostly be fine. Asssume that such 1-month attack happens, its cost will be about $4,250,952 $425,095,200 ($590,410*24 hours*30 days). It is impossible (cost) and also because the community will do react fastly with such attack.

Some casinos (Bitcasino.io, ie.) allow customers to gamble with unconfirmed deposits but they don't allow to withdraw before deposits are confirmed (1 to 3 confirmations).

Mastering Bitcoin, 2^nd edition, chapter 9

The blockchain is often visualized as a vertical stack, with blocks layered on top of each other and the first block serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms such as "height" to refer to the distance from the first block, and "top" or "tip" to refer to the most recently added block.

< ... >

One way to think about the blockchain is like layers in a geological formation, or glacier core sample. The surface layers might change with the seasons, or even be blown away before they have time to settle. But once you go a few inches deep, geological layers become more and more stable. By the time you look a few hundred feet down, you are looking at a snapshot of the past that has remained undisturbed for millions of years. In the blockchain, the most recent few blocks might be revised if there is a chain recalculation due to a fork. The top six blocks are like a few inches of topsoil. But once you go more deeply into the blockchain, beyond six blocks, blocks are less and less likely to change. After 100 blocks back, there is so much stability that the coinbase transaction—the transaction containing newly mined bitcoin—can be spent. A few thousand blocks back (a month) and the blockchain is settled history, for all practical purposes. While the protocol always allows a chain to be undone by a longer chain and while the possibility of any block being reversed always exists, the probability of such an event decreases as time passes until it becomes infinitesimal.

[ranochigo]

Risk of attacks when happen will be for new transactions. If yours are old one (1 month⁺), your fund will mostly be fine. Asssume that such 1-month attack happens, its cost will be about $4,250,952 ($590,410*24 hours*30 days). It is impossible (cost) and also because the community will do react fastly with such attack.

To be fair, 4 million is still not a lot. Isn't the cost around 500 million or so? The assumption is based on the cost of the resources obtained from NiceHash. This means that the pricing is inflated to some extent still. Depending on how long the attack lasts, some of the block reward could also be spendable in the forked chain. The attacker could do more damage with it. 51% attack isn't meant to last that long; the typical scenario is for when a transaction has been completed (ie. exchanging Bitcoins to fiat).

The main caveat of the attack is not how fast the community would respond but with the fact that their ASICs are worthless at that point. I still stand with your point that 51% attacks are not economical, given its current state.

Some casinos (Bitcasino.io, ie.) allow customers to gamble with unconfirmed deposits but they don't allow to withdraw before deposits are confirmed (1 to 3 confirmations).

It's important to note that most of those casino does implement extra checks to determine the ease of reversing the unconfirmed transaction (ie. non-RBF, high fees, confirmed parent). Some services have been burned from allowing unconfirmed transactions to be credited.

[o_e_l_e_o]

Asssume that such 1-month attack happens, its cost will be about $4,250,952 ($590,410*24 hours*30 days).

You've missed a few digits there. Using those numbers, the cost of a 1 month attack would be $425 million. Although you should also factor in that an attacker who manages to overturn a month of blocks would gain 27,000 BTC in block rewards (plus potentially fees if they chose to include other users transactions in their blocks), which at current prices would give them $280 million, so lowering the cost of a month long attack to around $145 million.

[mocacinno]

Asssume that such 1-month attack happens, its cost will be about $4,250,952 ($590,410*24 hours*30 days).

You've missed a few digits there. Using those numbers, the cost of a 1 month attack would be $425 million. Although you should also factor in that an attacker who manages to overturn a month of blocks would gain 27,000 BTC in block rewards (plus potentially fees if they chose to include other users transactions in their blocks), which at current prices would give them $280 million, so lowering the cost of a month long attack to around $145 million.

I looked at that site (crypto-5-1-.app), but couldn't find their exact methodology... They just say they base their calculations on nicehash's prices...
I'd be weary of taking these numbers at face value without seeing the underlying calculations...

In the rest of my post, i'm going to talk about length and height, but in reality it isn't the longest chain that wins, but the chain with the highes cumulative difficulty (the chain that required the most work). It's perfectly possible to have 2 chains: one with a lenght of 10.000 blocks, and a second one with a lenght of 11.000 blocks, but still your 10k chain could be the winner.

Now, did crypto-5-1-.app take into account you only have 51% of the hashrate? This means that 49% will keep on working on the "honest" chain.
This isn't an issue when you try to do a 51% attack on the last block because you'd be able to start at the same time as the rest of the network:

For example: i'm a thief... I pay a user when the current blockheight is (x-1). My transaction gets included in block with height (x), but i had the opportunity to start working on an alternative chain when the blockheight was still (x-1). If i have 51% of the hashrate, i have a 51% chance of finding a block for height (x) before the rest of the network can. If the rest of the network is first and move on to (x+1), i still have a decent chance of catching up in a relatively short time.
I
But... When i try to reverse the last (let's say) month: I'd have to go back to (x-4464) => 6 blocks/hour * 24 hours/day * 31 days/month.
By the time i reached height (x), the rest of the network would have reached height ~(x+4374). Oops
I have to catch up to those extra 4374 blocks as well... But by the time i reach them the "honest" miners will have added (on average) an other 4286 blocks.
I have to catch up to those extra 4286 blocks as well... But by the time i reach them the "honest" miners will have added (on average) an other 4200 blocks.
I have to catch up to those extra 4200 blocks as well... But by the time i reach them the "honest" miners will have added (on average) an other 4116 blocks.
...

With only 51% of the hashrate, it'll take me years to catch up... If, by the time i caught up, i get the network to accept my longest chain (witch will be allmost impossible), i will have effectively removed all profit for all miners for years and years, i will have rewritten so much history that bitcoin becomes worthless...

When you talk about re-writing more than a couple of blocks, everything becomes variable... I mean, you'll have to start looking at the difficulty, at the mempool, at the resell value of your gear, at the effect your actions will have on bitcoin's value,...

[NotATether]

I found a page that calculates the probability of an attacker subverting the blockchain with their own blocks at http://web.archive.org/web/20200502141047/https://people.xiph.org/~greg/attack_success.html. This page is not on the original site anymore. Looks like it's on gmaxwell's old page?

The first parameter is the percentage of the network's hash power the attacker has, the second is the block depth which I think is the block at the depth an attacker wants to replace, along with all the other blocks above that depth.

I think the calculator is a little inaccurate, because with a large block depth the probability converges to 1 with hash power proportions lower than 0.5, e.g. AttackerSuccessProbability(hashpower=0.43, confirms=1000)=1. It also doesn't take into account that even with hash power greater than 0.5 it may take several years to catch up with the network when using large confirms value, which effectively decreases the probability. This calculator returns 1 for hashpower at least 0.5, for any confirms despite this.

Nevertheless, I scraped the code that computes this and put it here if any of you want to explore it and see how it works: https://gist.github.com/ZenulAbidin/1f9aaa83453ab4c9e6c0992ee3fdad5d

[o_e_l_e_o]

But... When i try to reverse the last (let's say) month: I'd have to go back to (x-4464) => 6 blocks/hour * 24 hours/day * 31 days/month.

Your example is correct with the assumption that the attacker would start their 51% from block x-4464 when the main chain was already at block x. A 51% attacker could start their 51% attack from block x-4464 when the main chain was still at block x-4464, and simply not broadcast their blocks. When the main chain reaches block x, the attacker could broadcast blocks up to x+182 and rewrite an entire month in one go, without having to play "catch up" to the honest chain.

I think the calculator is a little inaccurate, because with a large block depth the probability converges to 1 with hash power proportions lower than 0.5

I'm pretty sure that's just a javascript overflow as opposed to inaccuracies in the code. As I mentioned above, the equations needed are in the bitcoin whitepaper. See also: https://gist.github.com/urokuta/7df03d8a692ff83941af

[mocacinno]

But... When i try to reverse the last (let's say) month: I'd have to go back to (x-4464) => 6 blocks/hour * 24 hours/day * 31 days/month.

Your example is correct with the assumption that the attacker would start their 51% from block x-4464 when the main chain was already at block x. A 51% attacker could start their 51% attack from block x-4464 when the main chain was still at block x-4464, and simply not broadcast their blocks. When the main chain reaches block x, the attacker could broadcast blocks up to x+182 and rewrite an entire month in one go, without having to play "catch up" to the honest chain.

You are correct, i didn't think about 51% attacks in a while, and i kind of forgot there are several ways of looking at this problem

I do still maintain that the numbers generated by crypto-5-1-.app should not be taken at face value without knowing the exact methodology... Adding numbers on a site and telling people you calculated them based on the price of nicehash's hashrate just doesn't cut it for me... The numbers might be ballpark correct, but without seeing the actual calculations, they're just numbers...