spend twice more Bitcoins while waiting the block to be verified?

[a298b112]

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.

[Charles-Tim]

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.

[NeuroticFish]

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?

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.

What if I will spend twice more Bitcoins then I have in my wallet while waiting the block to be completed? Thanks.

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.

[mk4]

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.

[hosseinimr93]

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.

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?

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)

[Lucius]

In theory even a confirmed transaction has still the chance to become invalid.

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.

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

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.

[BlackHatCoiner]

The transaction is valid if it's complied with the protocol. Once it's been included into a block we call it confirmed.

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?

If your transaction has 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!

As far as I know, this can only happen in the case of a 51% attack

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. It'll return you the probability of any combination you submit.

[hosseinimr93]

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.

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.

[Charles-Tim]

If your transaction has 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.

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.

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.

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.

[hosseinimr93]

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.

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.

[dansus021]

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

[o_e_l_e_o]

I will like o_e_l_e_o take on this.

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 was present in the losing block, while this conflicting transaction was present in the winning block. The only difference between the two is a slightly higher fee and a slightly lower change output.

[Pmalek]

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.

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.

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.

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.   

[BlackHatCoiner]

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.

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.

[khaled0111]

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?

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.

What if I will spend twice more Bitcoins then I have in my wallet while waiting the block to be completed? Thanks.

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.

[pooya87]

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?

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 I will spend twice more Bitcoins then I have in my wallet while waiting the block to be completed? Thanks.

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.

[o_e_l_e_o]

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.

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.

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.

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.

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.

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.

[Peanutswar]

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.

[khaled0111]

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.

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.

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.

[a298b112]

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.

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?