Topic: 6 confirmations questions (Read 560 times)
just one question my dear friend
I always imagine a scenario where I see a bunch of people standing around and 1 person kills a person .... now only 1 other person saw who did it and he is starting to tell the people around him what happened. So imagine the first person is block 1.. and the other who did not see it... are also being told over a longer period... until you get a bunch of people that know what happened.
Now imagine if I was the killer and I wanted to bribe people to stay quite... well, if I only had to bribe the first guy.. it would cost me very little, but if I have to bribe more and more... it would become very expensive...
The same principle is applied to confirmations.... the more confirmations you get, the more it costs you to remove the evidence of your actions. (In the Blockchain that would apply to a transaction you done)
Now imagine if I was the killer and I wanted to bribe people to stay quite... well, if I only had to bribe the first guy.. it would cost me very little, but if I have to bribe more and more... it would become very expensive...
The same principle is applied to confirmations.... the more confirmations you get, the more it costs you to remove the evidence of your actions. (In the Blockchain that would apply to a transaction you done)
The numbers might be ballpark correct, but without seeing the actual calculations, they're just numbers...
Totally agree, but they do give an indication of just how costly it is to overturn even a handful of confirmations. For the average user who might be spending/sending/trading up to a few bitcoin, 6 confirmations if more than enough to consider any trades "final", as the cost of reversing those confirmations far outweighs the value of the transactions.My train of thought was pretty simple: there's a 2% difference in hashrate, so if the attacker generates 100 blocks, the honest miner creates 98. If the attacker creates 4464, the honest miner creates 4464 - (4464*0.02).
Nah, hosseinimr93 is right. Although there is a 2% difference when considering the sum of the hashrates, 51 is 4% greater than 49. Think of a 60%/40% split - 20% difference, but 60 is 50% greater than 40.I would argue you can not calculate it that way. Simply because access to the amount of gear/hashrate is not possible for anyone to do.
I mean, if we are talking about someone controlling 51% of the hashrate for an entire month, then you can't really calculate it any way because such a thing is practically not going to happen. My comments are purely theoretical. Also worth pointing out that both BCH and BSV have already suffered 51% attacks in the past. 
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 would argue you can not calculate it that way. Simply because access to the amount of gear/hashrate is not possible for anyone to do.
The only way to attack the network at a 51% rate would be to divert the 3 largest pools via hijacking of the hashrate. If this was possible miners would shift to other pools. The attacker would need to be able at access pools at will to divert the hash to his address.
Lessor networks can be attacked.
BCH
BSV could be hit for a 51% attack not that hard
viabtc.com could do it on the sneak. viabtc has 9eh mining at btc they could simply pay the miners out of pocket and divert the the hash to attack with bsv or bch.
My train of thought was pretty simple: there's a 2% difference in hashrate, so if the attacker generates 100 blocks, the honest miner creates 98. If the attacker creates 4464, the honest miner creates 4464 - (4464*0.02).
Yes, The difference is 2%. But actually honest miners hashrate is 3.92% smaller than hashrate of the attacker. If the attacker mines 100 blocks, honest miners mine 96.08 blocks. So, number of blocks mined by honest miners should be 4464 - (4464*0.0392) = 4288
The conclusion still remains the same tough: if you want to roll back a longer time of historic blocks, the time you'll need is a lot more than just the time you need to mine said blocks, since the honest miners will keep adding new blocks on top. If you decide to do a roll back of future blocks to the state at this point in time, this isn't the case.
You are 100% right. that doesn't make any difference to the conclusion. 
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 don't understand how the 4374 was obtained. By the time i reached height (x), the rest of the network would have reached height ~(x+4374). Oops
Let's say I have 51% of the hashrate and 49% of the hashrate is owned by honest miners.
I mine 4464 blocks during a month. Number of blocks mined by honest miners can be easily calculated using proportion method.
So, number of those blocks would be 4464*(49/51) = 4288.
Am I missing something?
nah, you're probably right...I had a hectic day so far, filled with discussions about a huge database scheme and i'm left with most of my ability to concentrate gone. To this point, i'm still unable to get my head wrapped around the method used to solve this problem... This evening, when i'm back to normal, i'll probably either completely agree with what you said, or i'll disagree (altough those odds are small).
My train of thought was pretty simple: there's a 2% difference in hashrate, so if the attacker generates 100 blocks, the honest miner creates 98. If the attacker creates 4464, the honest miner creates 4464 - (4464*0.02).
The conclusion still remains the same tough: if you want to roll back a longer time of historic blocks, the time you'll need is a lot more than just the time you need to mine said blocks, since the honest miners will keep adding new blocks on top. If you decide to do a roll back of future blocks to the state at this point in time, this isn't the case.
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 don't understand how the 4374 was obtained. By the time i reached height (x), the rest of the network would have reached height ~(x+4374). Oops
Let's say I have 51% of the hashrate and 49% of the hashrate is owned by honest miners.
I mine 4464 blocks during a month. Number of blocks mined by honest miners can be easily calculated using proportion method.
So, number of those blocks would be 4464*(49/51) = 4288.
Am I missing something?
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...
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
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
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
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,...
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.
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.
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. 
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 
Mastering Bitcoin, 2nd edition, chapter 9
Quote
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.
< ... >
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.
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.
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.
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.
Ok, that cleared up alot of things I didn't understand, thanks everyone.
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.
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.
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?
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.
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?
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.
Jump to: