Topic: Transaction was confirmed, then unconfirmed on blockchain.info (Read 1480 times)

Yep, those were the two I was thinking of.

I haven't done much research either, and I personally know 2 long orphaned chains.
One originated from the output overflow bug https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139
Another one originated from the 2013 March fork https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

Ok, I think I understand now how it happens, also understood how a double spend happens, I saw that on blockchain.info for several transactions.

I think I should spend a lot of time reading about this to get a more clearer view coz if someone asks me I won't be able to explain it as well as you did

Thank u so much for this.

Already answered:



Transactions never get "cancelled".  They get forgotten about.  If a transaction remains in the pool of unconfirmed transactions for long enough (usually a few days), eventually peers start to remove it from their list of unconfirmed transactions.  After a long enough time, nearly all peers have forgotten about it.

Some wallets (such as Bitcoin Core) re-broadcast forever the unconfirmed transactions that the wallet previously sent.  It does this to continuously remind all the peers that have forgotten about the transaction.  This means the transaction will remain unconfirmed until it gets confirmed (which could be in the next block, could be never, or could be any amount of time in between those two extremes).

Other wallets (such as blockchain.info) give up on rebroadcasting the transaction and display the balance as being available to the original sender to be sent again elsewhere.

Note, that if a user re-spends those bitcoins elsewhere, many block explorers will remember that they saw a transaction with the same inputs previously, and will display a "double spend" warning to other users on the website.

Also note that once a transaction has been relayed throughout the network, there is nothing that is keeping anyone from storing a copy of the transaction and re-broadcasting it themselves.  As such, even if you are using the blockchain.info wallet to send a transaction, it is possible for the recipient of the transaction to re-broadcast it every few days to make sure that the network doesn't forget about it.  In that case, it will remain refreshed in the memory of all the peers until it gets confirmed, and you won't see the balance return to your blockchain.info wallet after a few days.

Wow, ok , this is deep, I understand it now somewhat. But the chances of this happening again and again with the next block is very high as you suggested.

But what happens to the transaction, it gets confirmed than unconfirmed, it will eventually get confirmed or it might get canceled?

Thank you so much! for such detailed explanation.

This is a peer-to-peer system.  There is no centralized server that is the authority of what has happened, and what has not.

Imagine for a moment, two miners both solve a block within fractions of a second of each other.  One of those miners had included your transaction in their block, the other didn't.

Which block gets to be added to the blockchain?

Each of the two miners broadcasts the block that they solved to all of the peers that they are connected to.  That means some peers on the network have seen the block with your transaction in it first, and other peers have seen the block without your transaction in it first.

The network is now split, with disagreement on which of the two blocks is the permanently "valid" block.

If the first block that your wallet received was the block that included your transaction, then your wallet will indicate to you that you have 1 confirmation.  The other half of the network will still know about your transaction, but they will see it as "unconfirmed".

Each half of the network then continues mining on whichever block they received first.

If the other half of the network solves the next block first, then they will add it to their version of the blockchain.  They will boradcast the new block to all of their peers.  Some of those peers will be on your half of the network.  Those peers will see that the new blockchain is longer than the one they are working on.  They will immediately switch over to the new longer blockchain and the relay it to the rest of your half of the network.  The entire network will see that this new chain is longer than the one that has your transaction confirmed.  All the transactions that were confirmed in the same block as yours, which weren't also confirmed in either of the two blocks from the other half of the network, will become unconfirmed again and will need to continue to wait to be included in a future block.

This is how the network arrives at consensus.  Anytime it splits, each half tries to make their half of the network into the "valid" one by being first to solve the next block.

With an average of 10 minutes between blocks, the odds are that most of the time two competing blocks won't be solved so close together in time, but it can (and does) happen.

Now, there is a possibility that when the network has split like that, each half of the network could each solve a block at nearly the same moment.  If that happens, then there is a fork that is 2 blocks long, and each half is racing to be the first to solve the third block.  It could happen again, and each half could be racing to solve the fourth block.

As you can perhaps see, there is no quantity of confirmations that result in a transaction that "cannot be unconfirmed".  However, the odds against a race condition still existing multiply with each additional block:

Most blocks are not orphaned.
Occasionally, a 1 block fork is orphaned.
Rarely, a 2 block fork is orphaned.
Extremely rarely, a 3 block fork might be orphaned.
I'm not sure how many times a 4 block fork has been orphaned.
I haven't done the research, but my guess is that a fork more than 4 blocks long hasn't been orphaned more than twice in the history of bitcoin.

Note that an orphaned block doesn't necessarily result in a transaction becoming unconfirmed.  If the transaction was confirmed in both forks of the blockchain, they it will remain confirmed regardless of which fork "wins".

Also note that, when a transaction does become "unconfirmed" due to an orphaned block, the transaction returns to the pool of unconfirmed transactions and is extremely likely to be re-confirmed in a block in the near future.

On the simpler side, you should wait for a minimum of one. If it is of larger value accordingly, then wait up to 6.
To answer your question, we must get technical, and there is no valid answer, as an attacker can have an alternative unbroadcasted blockchain as long as he wants.

I don't know about orphaned/UN-orphaned blocks too much, can you explain in simpler terms, or just tell me after how many confirmations a transaction cannot be unconfirmed?

It is possible if the block including your tx is orphaned, and the "winning" block doesn't include your tx.

Unlikely to be hacked, I believe it is only a orphan block. Blocks need certain amount of confirmations to be fully confirmed. If not it is orphaned.

So it was just a glitch with the blockchain.info website right? it is not possible for  a transaction to get unconfirmed after it is confirmed? or is this a new hack or something?

Blockchain.info has been unreliable recently. It will be fixed eventually. Better to use a second block explorer to view transactions, such as blockr.io

it doesn't matter. see dannyhamilton's response above.

sorry, where is the TXid found?

blockchain.info has had some issues with their database recently, especially when there is a recent orphaned block.  They eventually get it fixed, but in the meantime the state of transactions (confirmed vs. unconfirmed) can be incorrect on their website.

When did this happen? Do you have a txid?

^ what's up with that?