Question on confirmation time and blocks

[Charles-Tim]

I am using electrum wallet, it has a fee control feature and also I noticed about more than 10 confirmations.

1. When I read about bitcoin confirmation, I read after 10 confirmations the bitcoin sent will be completely mined which means has full (10) confirmations but I still noticed after the recipient had received the bitcoin, I checked the transactions details the next day, and I saw 2099 confirmations which is more than 10. What caused this?

2. When I wanted to use the fee control, I saw target to be within the range of the next block for highest fee and 25 blocks for the lowest fee. What is the relationship of time of transactions with the blocks? If it the bitcoin is mined in the next block, what will be the clearance time? I mean time for full confirmation.

3. What is the relationship between blocks and numbers of confirmations.

[LoyceV]

If it the bitcoin is mined in the next block, what will be the clearance time? I mean time for full confirmation.

It can be anything from 1 second to several hours. On average, 1 block is found every 10 minutes.

3. What is the relationship between blocks and numbers of confirmations.

Each new block adds one confirmation.

[nc50lc]

2. When I wanted to use the fee control, I saw target to be within the range of the next block for highest fee and 25 blocks for the lowest fee. What is the relationship of time of transactions with the blocks? If it the bitcoin is mined in the next block, what will be the clearance time? I mean time for full confirmation.

You must be talking about the fee-slider when you selected "ETA".
Then it was based from your selected server's node's result for the optimum fee for the target block;
according to ThomasVSomberNight, it's based from this command: estimatesmartfee (you can run it online, the result is in BTC/kB)
Ref-comment: https://github.com/spesmilo/electrum/issues/2447#issuecomment-381366160

I suggest you to switch to "mempool" and use 1mB from tip + a few satoshis for priority transactions, because personally, I find it more accurate.

"Full confirmation" is '1' confirmation, means that it's "mined", the consecutive confirmations required by services are just for safety purposes.

[HeRetiK]

1. When I read about bitcoin confirmation, I read after 10 confirmations the bitcoin sent will be completely mined which means has full (10) confirmations but I still noticed after the recipient had received the bitcoin, I checked the transactions details the next day, and I saw 2099 confirmations which is more than 10. What caused this?

Total confirmation basically means total blocks after your transaction included in a block and the number will increased over time.

Besides, where do you read "after 10 confirmations the bitcoin sent will be completely mined"? Total confirmation is used to determine whether we can conclude the transaction is done, for example 1 confirmation is good enough if you sell a cup of coffee, but if you sell a car, you probably wants the transaction have 6 confirmation more.

To expand on this -- there's no confirmation count that defines a transaction as "completely mined" or "fully confirmed".

There's no predefined limit that says "welp, now it's settled" except for the one defined by the recipient of the coins.

So for low risk transactions 1 confirmation is fine but with high risk transactions you might want to wait for a few more confirmations before regarding the transaction as settled, with 6 confirmations often being regarded as the sweet spot between security and practicality (ie. waiting time) in that case. Rationale being that the higher the confirmation count the more expensive an attack (which, accounting for oppportunity cost, get exponentially more expensive with each confirmation, starting in the tens of thousands for the first confirmation).

[Charles-Tim]

Besides, where do you read "after 10 confirmations the bitcoin sent will be completely mined"?

That was a reading mistake, and I have understood more about blocks and confirmation now.

With 1 confirmation, transactions could be mined in the next block with high transaction fee, but with lower fee it could take few blocks before it is mined which means more confirmations.

The remaining confirmations after the transaction is mine are for security and safety sake.

[o_e_l_e_o]

With 1 confirmation, transactions could be mined in the next block with high transaction fee, but with lower fee it could take few blocks before it is mined which means more confirmations.

I think you are still confused.

The transaction fee only determines how long it takes your transaction to be included in a block, and therefore achieve its first confirmation. Your transaction will have zero confirmations until it is included in a block. The higher the fee, the quicker it will be included in a block and therefore obtain one confirmation.

However, once it has a single confirmation, then the fee is irrelevant. Your transaction is not included in subsequent blocks - these blocks simply build on top of the block your transaction was included in. Each subsequent block will always increase the number of confirmations of all previous transactions by one.

[tranthidung]

If it the bitcoin is mined in the next block, what will be the clearance time? I mean time for full confirmation.

It can be anything from 1 second to several hours. On average, 1 block is found every 10 minutes.

I have a small discovery on time gap (in seconds) between empty blocks and one-before-empty blocks for 2 big pools: AntPool and F2Pool. Of course it is not a full data over more than 10 years history of bitcoin blockchain. It give some statistics for your statement. 

• AntPool
• F2Pool

[Charles-Tim]

With 1 confirmation, transactions could be mined in the next block with high transaction fee, but with lower fee it could take few blocks before it is mined which means more confirmations.

I think you are still confused.

The transaction fee only determines how long it takes your transaction to be included in a block, and therefore achieve its first confirmation. Your transaction will have zero confirmations until it is included in a block. The higher the fee, the quicker it will be included in a block and therefore obtain one confirmation.

However, once it has a single confirmation, then the fee is irrelevant. Your transaction is not included in subsequent blocks - these blocks simply build on top of the block your transaction was included in. Each subsequent block will always increase the number of confirmations of all previous transactions by one.

For example, if someone pay a fee for his transaction to be included within the next 25 blocks (low fee), it means the estimated block his transaction will just be within the 25 blocks but the transaction could get first (1) confirmation before the 25th blocks. But, regardless of the block it got first confirmation, the fee paid is required for the first confirmation. Thanks, and hope I get it right this time.

[o_e_l_e_o]

For example, if someone pay a fee for his transaction to be included within the next 25 blocks (low fee), it means the estimated block his transaction will just be within the 25 blocks but the transaction could get first (1) confirmation before the 25th blocks.

Correct. It could also be well after 25 blocks by the time the transaction gets its first confirmation. When you are selecting a fee, it is only ever an educated guess and is never set in stone. It depends on how many other transactions are broadcast in between the time you broadcast your transaction and the time it gets its first confirmation, what fees these other transactions pay, and how long it takes to mine the upcoming blocks.

If I pay a fee with a 25 block estimate now, and then suddenly some exchange dumps 10 MB of transactions with a higher fee than mine in to the mempool, then my transaction will be pushed much further back. Similarly, if I pay a fee with a 25 block estimate now, and then the majority of new transactions being broadcast in the next few hours pay a much lower fee than you might expect, then my transaction will be mined sooner.

[HCP]

But, regardless of the block it got first confirmation, the fee paid is required for the first confirmation.

To really throw a spanner in the works... it is actually technically possible to have zero fee transactions (and historically there have been a few).

However, these days, the vast majority of nodes will refuse to accept and/or relay transactions with fee rates below a certain threshold... the so-called "min relay fee" (which is customisable). But, if you're friendly with a miner/mining pool, it is possible for them to take your zero fee transaction and put it in a block and everything will validate just fine. It just isn't practical for the general public

[Mpamaegbu]

It can be anything from 1 second to several hours. On average, 1 block is found every 10 minutes.

I don't know how the miners do it, but I think it's faster when it goes from one Segwit address to another Segwit address. Unlike when one is sending from a Legacy to a Segwit. I have had a transaction last almost 24hours before it finally went through. However, I have discovered that at a particular time of the day my transactions send faster than at any other time (even when I choose low priority fee), usually it's during midnight. I am wondering if there's any connection to that or just a coincidence.

[o_e_l_e_o]

I don't know how the miners do it, but I think it's faster when it goes from one Segwit address to another Segwit address.

Kind of, but not really.

The miners do not care what type of addresses are used in the transaction. What they care about is how large the transaction is in bytes, and how large the fee is in sats, and will choose the transactions which pay the highest fee in terms of sats per vbyte. SegWit transactions take up less space than legacy transactions, and so are cheaper to send with a higher fee, which will mean they get confirmed sooner. However, a legacy transaction and a SegWit transaction with same fee in sats per vbyte will be confirmed at the same time (on average).

However, I have discovered that at a particular time of the day my transactions send faster than at any other time (even when I choose low priority fee), usually it's during midnight.

Usually the cheapest time to send is somewhere around 0700 UTC. Have a look at this graph: https://jochen-hoenicke.de/queue/#1,30d. You can see regular dips more or less every day around this time.

[Charles-Tim]

It can be anything from 1 second to several hours. On average, 1 block is found every 10 minutes.

However, I have discovered that at a particular time of the day my transactions send faster than at any other time (even when I choose low priority fee), usually it's during midnight. I am wondering if there's any connection to that or just a coincidence.

I think during that time of the day, the mempool is not often congested. Another example people do mention is during the weekend, when the mempool is not congested compared to during the weekdays.

About sending from one segwit address to another segwit address, the transaction will be faster because there is increase in block size and the fee paid is lower compared to legacy addresses.

But I am confused about something, I thought before that sending from segwit to legacy or sending from legacy to segwit address will not work and the transaction will be reversed but compatible addresses that started with 3 are the bridge between segwit and legacy.

[Lucius]

About sending from one segwit address to another segwit address, the transaction will be faster because there is increase in block size and the fee paid is lower compared to legacy addresses.

You cannot speed up a transaction by using SegWit because you are still using the main network to get confirmation, which means that until someone finds the next block your transaction will not be confirmed regardless of the fee or what type of address you use. What is important with SegWit is that the user pays a lower fee because the amount of data in your transaction is significantly reduced compared to if you use a Legacy address. Users are pay fee based on size of their transaction.

But I am confused about something, I thought before that sending from segwit to legacy or sending from legacy to segwit address will not work and the transaction will be reversed but compatible addresses that started with 3 are the bridge between segwit and legacy.

In the beginning (and even today) there are some crypto exchanges that did not implement Native SegWit (bc1 address), so that was and still is a problem for some users. Nested SegWit is of course much easier to implement, so it is a much more common type of address.

[nc50lc]

About sending from one segwit address to another segwit address, the transaction will be faster because there is increase in block size and the fee paid is lower compared to legacy addresses.

But I am confused about something, I thought before that sending from segwit to legacy or sending from legacy to segwit address will not work and the transaction will be reversed but compatible addresses that started with 3 are the bridge between segwit and legacy.

Witness data is just computed 4 times lower in "vBytes" (Virtual Bytes) than non-witness data, not all parts of the transactions are Witness data even for SegWit to SegWit address transaction.
And transaction prioritization is based from vBytes not the raw size of the transaction, so SegWit transactions are "virtually" smaller than legacy.

For the confusion, as far as I know, it wont be based from the outputs at all.
So only SegWit inputs counts, Sending to Segwit address while using a legacy address wont count it as SegWit transaction.

[o_e_l_e_o]

But I am confused about something, I thought before that sending from segwit to legacy or sending from legacy to segwit address will not work and the transaction will be reversed but compatible addresses that started with 3 are the bridge between segwit and legacy.

No. Any address can send to any other type of address. There are some centralized exchanges which don't support SegWit addresses, but that is because they are crap exchanges and has nothing to do with bitcoin itself.

What is important with SegWit is that the user pays a lower fee because the amount of data in your transaction is significantly reduced compared to if you use a Legacy address.

This isn't correct. SegWit transactions will contain roughly the same amount of data (or in the case of nested SegWit, actually much more data) than legacy transactions. What changes is how the data is weighted when calculating weight units, not the actual volume of the data itself.