Topic: spend twice more Bitcoins while waiting the block to be verified? - page 2. (Read 466 times)

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.

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.

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.

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.   

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.

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

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.

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.

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.

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

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!

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.

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.

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)

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.

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.

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.

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.