Bitcoin Forum

I am reading a book about Bitcoin and how it works, and while reading it I came up with this question.

So, turns out it will take ~10 minutes to create a block and block includes all transactions. Now, in a situation where I want to buy a grocery from the local shop for 0.0001 Bitcoin, should I wait 10 minutes (maybe 5) so that the seller makes sure that the transaction is valid? What if I will spend twice more Bitcoins then I have in my wallet while waiting the block to be completed? Thanks.

In most cases, you have to let the transaction to be confirmed before it would be accepted as a valid payment.

Next block mined in which your transaction would be included if high fee is used can take less or more than 10 minutes, that is why it is said to be 10 minutes on average.

But there are cases unconfirmed transaction that does not support replace-by-fee can be accepted immediately after the transaction is broadcasted.

If you spend on-chain, indeed, in order to verify at least one confirmation you're restricted to block speed, which is on average at 10 minutes (it can be seconds, in rare occasions it can be even more than 20 minutes).
If you use LN, you don't have this restriction.


In theory you can try that, although in reality your wallet won't allow it (eg. if you try from the same wallet). But, since the seller will wait until the transaction is confirmed, he's safe. After one of the transactions in confirmed, the other one(s), trying to spend coins you don't have, will not be confirmed and will also be discarded.

You're technically going to wait some time between 1 second and 10 minutes. Obviously this really isn't viable when it comes to physical person-to-person transactions hence why we have the likes of bitcoin debit cards and the likes of Cash App (which are temporary band aid solutions). To address the privacy and custodial problems while still having quick and cheap transactions, layer-2s like the Lightning Network are being worked on.

As a long as a bitcoin transaction is unconfirmed, there's a chance that it will never be confirmed.
In theory even a confirmed transaction has still the chance to become invalid.

So, accepting an unconfirmed transaction depends on your risk acceptance.

I would never accept an unconfirmed transaction which is flagged as RBF even if the amount is very small.
I may accept a non-RBF unconfirmed transaction if the amount is small.
If the amount is big, I would accept the transaction only if it's confirmed.

Many services don't accept your transaction even if it has received 1 confirmation and they require more confirmations.


If the fee you pay for the transaction isn't enough, there's the probability that the transaction takes a very longer time to be confirmed. (In the worst case, your transaction will never be confirmed)

As far as I know, this can only happen in the case of a 51% attack, when the one who would gain majority control over the hash rate could do double-spend transactions and prevent new transactions from being confirmed.


This has already become the standard procedure for all transactions involving large amounts, but it is completely illogical for me that some ask for 3+ confirmation for any amount - especially if it is a physical store/crypto exchange which only unnecessarily prolongs the whole process. I had several personal experiences where I received the first confirmation in less than 1 minute, but then I waited at least another 10+ minutes for two additional confirmations which, considering the amount, were completely unnecessary.

The transaction is valid if it's complied with the protocol (https://en.bitcoin.it/wiki/Protocol_rules). Once it's been included into a block we call it confirmed.

If your transaction has replace-by-fee (https://en.bitcoin.it/wiki/Replace_by_fee) disabled, then it's safe enough from the merchant's side to consider the transaction settled, even if it isn't confirmed yet. It's still possible to have it reversed, say if you paid a miner to include a different transaction that spends the same output(s).

If the merchant disagrees with the unconfirmed settlement and you don't want to wait, then you can't use Bitcoin on-chain. Introducing... The Lightning Network (https://www.lopp.net/lightning-information.html)!

Not only. With 51%, it's highly likely that you can reverse anything; it's just a matter of time. With less than 50%, your chances drop exponentially, but for one who wants to reverse a transaction that was just confirmed, much less percentage of the hash rate is sufficient. For example, with 24% you have a 50.1% chance of overwriting the previous block.

For anyone who owns less than 50%, say 10%, it's improbable to succeed, even for a block; it's 20.4%. Check this (https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html). It'll return you the probability of any combination you submit.

There's another scenario in which the transaction is included in a stale block.

Assume that miners A and B mine a block simultaneously. Miner A has included your transaction. Miner B hasn't included your transaction. Now your transaction has 1 confirmation.
The next block is mined and is added to the chain including the block mined by miner B. The block mined by miner A is now a stale block.
Now your transaction isn't on the chain with the most work and it's unconfirmed.

Also if the non replace-by-fee (child) transaction is not having a replace-by-fee parent transaction because the replace-by-fee parent transaction can be double spent which can make the child transaction to become invalid.

It is highly unlikely that transactions included in block A would not be included in block B, but if this happens, the transaction would not become invalid but it will become unconfirmed, which would be confirmed later if high transaction fee is used. But if low fee is used and the mempool become congested, maybe the unconfirmed transaction can drop out of mempool in a way the sender can rebroadcast it and send it to another address, making the transaction to become invalid.

I will like o_e_l_e_o take on this.

If there's a legacy or a nested segwit address in inputs of the unconfirmed parent, there's the chance of malleability attack too.
Nodes can change the hash of the unconfirmed parent and makes the child invalid. This can happen even if the parent hasn't been flagged as RBF.

in today cases is rarerly that transcation goes unconfirmed as long you put the fee for miner is good and like the other said merchant usually using lighting network for fast transaction or the merhant and user using same app that doesnt require to include in blockchain to do the transaction

With two competing blocks at the same height (let's call them A and B), then they will usually contain the majority of the same transactions (the ones with the highest fee rates). There will be a small number of transactions which are included in one block, but not the other. Let's consider a transaction which is included in Block A, but not in Block B. Such a transaction, since it is not present in Block B, will instead be present in the mempool of the nodes which have accepted Block B. Now, if Block A+1 is the next block found, then the transaction (which is included in Block A), now has 2 confirmations. If Block B+1 is the next block found, then there is a high likelihood that this transaction which was not included in Block B will now instead be included in Block B+1. In the case, the transaction has 1 confirmation.

So usually when the split is resolved, there are very few, if any, transactions which go from having 1 confirmation (according to some nodes) to going back to being unconfirmed. And even if this does happen, the transaction is still valid and can be mined in future blocks. And usually if there are are double spends, then more often than not it is because of a fee bump with RBF, rather than attempted fraud.

For example, there was a chain split at height 714,637. This transaction (https://blockstream.info/tx/027a59355ffd43904da4e097d60027aaa93a61d82448c3ccf3924d7629e3965e) was present in the losing block, while this conflicting transaction (https://blockstream.info/tx/0bc67fec1c95af549aa77e0ef0f9c9796900855ec7a05d7cbe7e8a28b4b31d77) was present in the winning block. The only difference between the two is a slightly higher fee and a slightly lower change output.

That makes sense, not much to add there. A new block was added on top of the one where your transaction was mined, and that increases your confirmations by 1.

In this scenario, this would only happen if the network conditions haven't changed drastically between blocks B and B+1. If the mempools got filled with other transactions paying higher fees, that would be a reason it wouldn't be included in block B+1 and instead remain unconfirmed. The same thing is true if there is a longer waiting period between blocks B and B+1 and not all unconfirmed transactions can fit in the next block. Again, it's a question of if miners have the financial incentive to pick your transaction. Nevertheless, that doesn't affect its validity.   

It had happened in 2021 and there was a temporary FUD prevailing in the media, if anyone remembers it; one had their confirmed transaction unconfirmed. It was due to that you describe.

I wonder if there's a way, such as a plugin we can install to Bitcoin Core, so that we can count the number of transactions that have made their way into the chain, but got removed afterwards. The frequency of stale blocks is 0.1%, if I recall correctly.

Yes, you will have to wait till the transaction get enough confirmations (depending on the seller's preference) and this may take way more than 10 minutes depending on the fees you paid and the network status. There is also the possibility that the transaction will never get confirmed.
Unfoetunately, this is one of the downsides of using bitcoin for small transactions specially when you are in a hurry. Lightning payments are the best solution in such situations.

No, you can't spend more than you have. You can create a new transaction which spends the same inputs while the first one is still unconfirmed (known as double spending/replace by fee). The first transaction will become invalid and nodes will drop it from their mempools.

When you go to the grocery store and pay with your credit card for example, do you wait for 6 months for the transaction to be confirmed?

What if you pulled a credit card fraud or reversed the payment before 6 months?

You see bitcoin is just a payment system with well known characteristics that is actually so much better than any other payment system. But just because it is new and decentralized people think it should be treated differently until you get used to it.
The fact is that scamming using any other payment method is so much easier than scamming using bitcoin payment in most cases. For example if you pay the store with a decent amount of fee and not use RBF in your transaction the confidence in such a transaction is high and chances of scam is so much lower. The store's node could also be set up in a way to monitor the mempool and analyze the payment transaction for confidence.

For some nodes. For the nodes which had to discard Block B to accept Blocks A and A+1, then the confirmations would increase by 2, as the transaction jumped from unconfirmed to 2 confirmations.

Absolutely, but the longer the period between Blocks B and B+1, then the more chance that Block A+1 is found first and the split is resolved in favor of the alternate chain.

The terms "double spend" and "replace by fee", while related, are not synonymous. In an attempted double spend, the first transaction will only be dropped if it is flagged as RBF enabled. Otherwise, double spend attempts will be ignored by the vast majority of nodes, even if it pays a higher fee than the transaction already in their mempools.

When making a transaction we are paying for the fees and the miners will make the transactions faster it depends on how much you are willing to speed up the process. If you don't hurry up too much you can make a slow to the normal transaction or if you hurry up and make a speed up you need to use the fast transactions. Is this worth it depends on whether you are willing to wait or not The number of people making a transaction the more it gets congested.

Thank you clarifying this o_e_l_e_o :) Actually, am well aware of the difference between double spendind and replace by fee. Maybe I had to clarify that this is just how Electrum name it, sorry if that sound confusing.
As the name suggests, a transaction flagged as rbf can be replace by a transaction consuming at least one of the same inputs and paying higher fees. If the transaction isn't flagged as rbf, any other transaction consuming any of its inputs will be considered invalid and will be rejected by any node that has the first transaction in its mempool.

This! So it is the wallet that makes sure that I won't be able to spend more than I have. But, what if I develop my own wallet that will not check my balances and eventually allow me spend more than I have?

Then your transaction will be rejected by the nodes and it won't have any chance to be included in a block.
Once you broadcast a transaction to the network, your node sends it to other nodes. The nodes that receive your transaction check validity of your transaction and they send your transaction to other nodes only if it's valid.

No, it is the network. The vast majority of nodes are configured to reject any transaction which double spends an input which is used in a transaction already in their mempool, unless the original transaction is flagged as RBF enabled. And if you were successful in broadcasting two competing transactions, then only one of them will ever get confirmed.

It won't. You can broadcast competing transactions as much as you want, and you can easily set up a wallet to let you do this, but the network will reject them. Most wallets simply prevent users from doing this so as to avoid confusion and because there is no point in endlessly broadcasting invalid transactions.

Of course, you can modify your existing bitcoin wallet (provided it is fully open source) or develop your own software that will do whatever you programmed it to do. You also may want to modify the software of your own full node to equip it to accept the transactions from your modified software wallet. You also may want to connect to only those full nodes that run the modified software developed by you to avoid being rejected by non-modified full nodes. Essentially, to make your modified software work, you need to create your own ecosystem of modified clients, full nodes, miners, exchanges, merchants, etc. Then and only then will it be possible to double spend your bitcoin, but, oh wait, I forgot to mention that the name of your coin also needs to be renamed to avoid confusion. So, you will be running your own version of bitcoin if you try to go against consensus rules, but it is unlikely to last for long because no economically rational players would support your network of constant double spends.

I've explained it all, you chose to understand what you want.
The wallet helps you not make mistakes. The blockchain ensures you're not play smartass.

Thanks for the explanations. Not that I want (or I can) to try double-spend, it is just how I learn this complex topic. By asking dumb questions sometimes and questioning myself first of all. Anyway thanks

No problem and sorry if I was a bit harsh, it did sound to me like you want to insist into wrong direction, especially after getting so many answers covering the topic.
At least I am kinda sure now that you've got the point.

I bet the book OP read won't tell us what happens whenever the mempool is congested and how long we have to wait for transactions to confirm. I've had to wait for over 72 hours (three days) for a transaction I did to confirm. Literally, my spirit nearly left my body while waiting for it. It was a moment of anxiety for me as that was my first experience of a long wait. Usually, before that incident, the longest wait for me was a day. However, I learnt something from that experience and I was given to understand that no matter how long it took; a transaction must definitely confirm. Otherwise, the blockchain will experience a gap or something. I can't remember the right word used then by veterans here. After I came out of that, I deliberately set a much lower fees for a few transactions of mine from one of my wallets to another to watch what happened. It actually worked. Now, I don't bother whenever I make transactions by thinking they won't confirm because of low fees. It's just to give it some time. Don't panic.

If the mempool is particularly congested and you have set a particularly low fee, then rarely your transaction might not confirm. There are two scenarios this can happen; either your transaction has been unconfirmed for so long that nodes start dropping it from their mempool, or the mempool becomes so full with higher paying transactions that it hits its maximum size limit and your transaction is pushed out the bottom. The default value for these two settings are 336 hours (14 days) and 300 megabytes, respectively.

There is still no reason to panic in either scenario, though. The worst case scenario is that your unconfirmed transaction disappears from nodes' mempools, which means the coins you tried to send never moved. They will be back in your wallet and you can simply use them to make another transaction (with a higher fee this time).

I haven't experienced that returned unconfirmed transactions with Bitcoin but it was almost a regular for me with ETH those days because of its crazy and exorbitant fees. I would deliberately choose a low fee thinking it was the same way with Bitcoin transactions but it would return after some days, staring me in the face in the wallet.

BTW, congrats on hitting the 10,000 merit threshold like LoyceV. 👍. At least, he won't be lonely in that apartment any more.

So does that mean if I have to get my transaction quickly confirmed when paying for a service with Bitcoin, I have to increase the fee from low to high?

If your transaction has been flagged as RBF, you can increase the fee rate, so it's confirmed faster. The fee rate you should set for getting a fast confirmation depends on the network status.
If your transaction hasn't been flagged as RBF, it's very very unlikely that you can replace your transaction with a new one, even if you pay a very high fee.

Note that with increasing the fee, you actually make a new transaction with a different hash. So, if the service you are paying to hasn't been coded properly, you may have to contact them and tell them about increase in the fee.

In addition to what @hosseinimr93 wrote, my advice is to learn to interpret mempool correctly so that you can make the right decision at any time. All those who make transactions actually compete with each other, especially those who want confirmation in the next block. I would recommend you to look at this site (mempoolspace (https://mempool.space/)) where you can always see current information, and it is quite easy to understand the most basic things you need to determine the most optimal fee.

You are right.

The best is for transaction to support replace-by-fee. That is just one of the reasons I like Electrum, unlike most other wallets that make bitcoin transaction as final and inability to pump the fee. There are some situations CPFP can still be used. But if the mempool is congested and the person do not want to use CPFP, but the transaction fee is above 10 sat/byte, ViaBTC free accelerator  (https://www.viabtc.com/tools/txaccelerator) can still be used, although it may be disappointing if the mempool is so congested as many people would want to make use of the free accelerator at the time.

@Charles-Tim, via still works as far as I know, but if you don't know exactly how to make it work it becomes a real waste of time. Apart from that, it seems to me that I rarely see them on the list of those who find the block (only twice in the last 4 hours), but in the end it's all a matter of luck - RBF and mempool are always the best choice for me.

That's exactly what expected.
According to the information shown on their website (https://www.viabtc.com/), their hash rate is around 22 EH/s which is around 8.5% of the total hash power.
With that hashrate share, it's expected that they mine 1 block in every 12 blocks on average.

You have to set a fee which is appropriate for the current mempool conditions. If the mempool is empty, then a fee of 3 sats/byte might be a high fee and get you confirmed in the next block. If the mempool is full, then a fee of 10 sats/byte might be a low fee and have you waiting several hours.

The two sites I use to observe the current mempool are:
https://mempool.space/
https://jochen-hoenicke.de/queue/#1,8h

If you want the easy route, then just take the number from the top left of mempool.space which corresponds to low/medium/high and use that. If you want a more in depth but more accurate approach, then take a look at the mempool bands yourself and place your transaction exactly where you want it to be from the tip of the mempool. If you've already made a transaction and discovered the fee is too low, then your only real options are either RBF or CPFP as discussed above.