Bitcoin Confirmations

[klrgoten]

Hey all,

I'm curious about Bitcoin confirmations. I'm having a discussion with a friend and I'm sure there are tons of threads on this but what exactly is a confirmation? Is a confirmation a new block? Why do I get some confirmations done in a few minutes and other times t may take hours... Yesterday for example it took 15 minutes for 5 confirmations... Why does it happen faster sometimes?

Thanks much

[1715256941]

1715256941

[achow101]

A confirmation means that it has been included in a block. Confirmation times are on average about 10 minutes because a block is mined every ten minutes. However, due to the random nature of blocks, confirmation time could vary wildly depending on whether a block is mined or not. Sometimes miners are lucky and find blocks very quickly, other times they are not and the block is not found in less than 10 minutes.

[melody82]

Also keep in mind that different businesses require more or less confirmations.  So far I have seen 1-6 confirmations needed before transferred funds are available.  Also if you change the default fee in your wallet then your confirmations may take longer.  Here is a decent overview of all the basics.  You don't need to read all that stuff, but if you have any questions that is a good place to start.  Of course you are always welcome to ask here, after all that is what the beginners section of the forums is for.

[ranochigo]

Just to add on, a confirmation doesn't automatically secures you from a double spending attack. It only prevent you from race and finney attack. If a single entity controls more than 51% of the network hashrates, even with a lot of confirmations, the transactions can be reversed. Note that attacks can only be 100% successful if attacker controls more than 51% even if the confirmation is 100. If the attacker controls less than that, the probability will decrease gradually.
However, for everyday transactions, 0-1 confirmations is enough depending on the price of the items sold. If the transaction is 1000BTC, you would more likely be looking for 20+ confirmations. If its only 0.01BTC, you can even accept it at 0 confirmations. Special precautions can be made, for example, you can wait for a few minutes or seconds to check for competing transaction and make sure it propagates well. POS systems like bitpay does this well.

[odolvlobo]

0 confirmations -- hasn't been included in a block yet
1 confirmation -- included in the last block
2 confirmations -- included in the next to last block (1 block added since first confirmation)
3 confirmations -- 2 blocks added since first confirmation
4 confirmations -- 3 blocks added since first confirmation
...

The average time it takes for a block to be added is 10 minutes, but the actual time varies greatly.

[Amph]

i was thinking that there should be a way for the next block, to confirm the inclusion of the transaction, without actually including it, but it is just based on the first block inclusion, in this way you need only 1 confirmation

is something like this even possible?

[LiteCoinGuy]

Just to add on, a confirmation doesn't automatically secures you from a double spending attack. It only prevent you from race and finney attack. If a single entity controls more than 51% of the network hashrates, even with a lot of confirmations, the transactions can be reversed. Note that attacks can only be 100% successful if attacker controls more than 51% even if the confirmation is 100. If the attacker controls less than that, the probability will decrease gradually.
However, for everyday transactions, 0-1 confirmations is enough depending on the price of the items sold. If the transaction is 1000BTC, you would more likely be looking for 20+ confirmations. If its only 0.01BTC, you can even accept it at 0 confirmations. Special precautions can be made, for example, you can wait for a few minutes or seconds to check for competing transaction and make sure it propagates well. POS systems like bitpay does this well.

wrong.


An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

    -Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
    -Prevent some or all transactions from gaining any confirmations
    -Prevent some or all other miners from mining any valid blocks

The attacker can't:

    -Reverse other people's transactions
    -Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
    -Change the number of coins generated per block
    -Create coins out of thin air
    -Send coins that never belonged to him

[Muhammed Zakir]

i was thinking that there should be a way for the next block, to confirm the inclusion of the transaction, without actually including it, but it is just based on the first block inclusion, in this way you need only 1 confirmation

is something like this even possible?

Don't think so. There are problems with this. We can't know how the owner will spend the UTXO and without knowing it, I don't know how can we confirm a transaction which is going to happen.

[odolvlobo]

i was thinking that there should be a way for the next block, to confirm the inclusion of the transaction, without actually including it, but it is just based on the first block inclusion, in this way you need only 1 confirmation

is something like this even possible?

Well, that's exactly how it works. That's why it is called a block chain. The reason that there is a need for multiple confirmations is that the block chain can be rewritten, though the older the block is, the less likely it is that it will be undone.

[Slark]

Just to add on, a confirmation doesn't automatically secures you from a double spending attack. It only prevent you from race and finney attack. If a single entity controls more than 51% of the network hashrates, even with a lot of confirmations, the transactions can be reversed. Note that attacks can only be 100% successful if attacker controls more than 51% even if the confirmation is 100. If the attacker controls less than that, the probability will decrease gradually.
However, for everyday transactions, 0-1 confirmations is enough depending on the price of the items sold. If the transaction is 1000BTC, you would more likely be looking for 20+ confirmations. If its only 0.01BTC, you can even accept it at 0 confirmations. Special precautions can be made, for example, you can wait for a few minutes or seconds to check for competing transaction and make sure it propagates well. POS systems like bitpay does this well.

wrong.


An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

    -Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
    -Prevent some or all transactions from gaining any confirmations
    -Prevent some or all other miners from mining any valid blocks

The attacker can't:

    -Reverse other people's transactions
    -Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
    -Change the number of coins generated per block
    -Create coins out of thin air
    -Send coins that never belonged to him

An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations.
Attack like would be very costly in resources, and for such not-so-great benefits there is little rational economic drive to do such a thing.

[melody82]

I was going to add that because of the incredible amount of computing power aimed towards mining coins a 51% attack would be really difficult to pull off and its doubtful that it would be worth the effort.  I see it more as a theoretical threat than a real one at this point.

[ranochigo]

Just to add on, a confirmation doesn't automatically secures you from a double spending attack. It only prevent you from race and finney attack. If a single entity controls more than 51% of the network hashrates, even with a lot of confirmations, the transactions can be reversed. Note that attacks can only be 100% successful if attacker controls more than 51% even if the confirmation is 100. If the attacker controls less than that, the probability will decrease gradually.
However, for everyday transactions, 0-1 confirmations is enough depending on the price of the items sold. If the transaction is 1000BTC, you would more likely be looking for 20+ confirmations. If its only 0.01BTC, you can even accept it at 0 confirmations. Special precautions can be made, for example, you can wait for a few minutes or seconds to check for competing transaction and make sure it propagates well. POS systems like bitpay does this well.

wrong.


An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

    -Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
    -Prevent some or all transactions from gaining any confirmations
    -Prevent some or all other miners from mining any valid blocks

The attacker can't:

    -Reverse other people's transactions
    -Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
    -Change the number of coins generated per block
    -Create coins out of thin air
    -Send coins that never belonged to him

An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations.
Attack like would be very costly in resources, and for such not-so-great benefits there is little rational economic drive to do such a thing.

Wrong, the attacker can possibly hack a large mining pool or use his own pool for such attacks. If the attacker is afraid of someone finding out, then he can create seperate mining pools and merge them during the attack. If the attacker owns a cloudmining service, such attacks can be easily executed without much cost since they are beared by the customers already.

[BIT-Sharon]

Due to the random nature of bitcoin, how to make the confirmation more regular for miners?

[Jamacn]

yes it can
if you pay more transition fee 

[achow101]

Due to the random nature of bitcoin, how to make the confirmation more regular for miners?

This is done through adjusting the difficulty, but that does not guarantee more regular confirmations, only that confirmations are more likely to occur within 10 minutes.

[achow101]

Wrong, the attacker can possibly hack a large mining pool or use his own pool for such attacks.

As soon as people begin noticing that one pool is nearing or has 51% of the hashrate, there will be shitstorm on this forum, and the miners will switch off of that pool to prevent the attack. This happened to Ghash.io a while ago.

If the attacker is afraid of someone finding out, then he can create seperate mining pools and merge them during the attack.

How do you "merge" mining pools?

If the attacker owns a cloudmining service, such attacks can be easily executed without much cost since they are beared by the customers already.

Assuming that it is not a scam like most cloudmining services, it still costs a significant amount in order to start up and then the service needs to profit in order to buy more equipment. Profiting would be rather difficult because the service needs to constantly payout.

What hasn't been mentioned is that it is more profitable to have 51% and mine normally than it is to have 51% and try to attack the network.

[ranochigo]

Wrong, the attacker can possibly hack a large mining pool or use his own pool for such attacks.

As soon as people begin noticing that one pool is nearing or has 51% of the hashrate, there will be shitstorm on this forum, and the miners will switch off of that pool to prevent the attack. This happened to Ghash.io a while ago.

If the attacker is afraid of someone finding out, then he can create seperate mining pools and merge them during the attack.

How do you "merge" mining pools?

If the attacker owns a cloudmining service, such attacks can be easily executed without much cost since they are beared by the customers already.

Assuming that it is not a scam like most cloudmining services, it still costs a significant amount in order to start up and then the service needs to profit in order to buy more equipment. Profiting would be rather difficult because the service needs to constantly payout.

What hasn't been mentioned is that it is more profitable to have 51% and mine normally than it is to have 51% and try to attack the network.

True that there was a lot of argument about the 51% attack but it actually took sometime for a lot of miners to shut their machines down. Even though many people were scared that there may be a possibility of 51% attack, many didn't take actions and even after a day, the pool was still in the high 40%.

I'm pretty sure that can be done if you redirect the shares to one pool. (Correct me if I'm wrong but people has been talking about how this can be done).

If you are going to host a cloudmining service, it can take sometime before you can even ROI. If you are in need of money, you would consider to do an attack since revenue is going to be generated slowly. There is also a possibility of decline in the purchases which will impact your revenue. After the attack, you can still sell off your equipments fast.

[dollarneed]

yes it can
if you pay more transition fee 

yup its depend your fee to,as long as your fee very low the confirmation would be slow,but in blockchain you can adjust it cmiiw

[ranochigo]

yes it can
if you pay more transition fee  

yup its depend your fee to,as long as your fee very low the confirmation would be slow,but in blockchain you can adjust it cmiiw

Transaction fees only affect the ranking of your transaction, based on the fees per kilobyte*[Highest fee included first] . However, 50kb in the block is reserved for the transactions with the highest priority. The miner that mined the block have the last say whether to include your transaction into the block. However, high priority and/or transaction fees may not mean that it will be confirmed very fast. It may get confirmed at the next block but it would depend on the time that it gets mined.

*Only if they pay the 0.00001BTC/KB

[Amph]

Due to the random nature of bitcoin, how to make the confirmation more regular for miners?

you mean no swings of the average time? i think that's impossible, unless the diff stay there indefinitely, without rising or decreasing, and diff is based on price, so again we are returning to the stability of the price, to reach that point