Occasionally transactions will be broadcast to the network that will show in a 0/unconfirmed status in the Bitcoin client. It is also the case that from time to time for various reasons those transactions will never confirm. One known reason for such unconfirmed transactions is a double-spending attempt, though these are usually quickly resolved by the network. My question is twofold:

  1. Is there any source of data or is there a known statistic stating what percent of transactions hit 0/unconfirmed and never progress beyond this state (i.e. are resolved as conflicts by the network).
  2. Is there anything aside from a double-spending attempt that can produce a 0/unconfirmed transaction that does not confirm.

Please note that I am not referring to the "generated" transactions by which miners are paid, but rather a point-to-point transfer of bitcoins.

  • Maybe I don't understand the question. It sounds like you're not asking a technical question, your asking "how often do people attempt to double spend." Since that's the only context in which this scenario could occur. The only way you can get a percentage of double spend attempts is if you attempt to double spend, so the answer would be rather obvious. Both mine and David's answers say effectively the same thing with regard to double spending. Sep 1, 2011 at 18:50
  • I suppose that makes sense. If the only transaction that can actually get lost when a block is orphaned is the "generated" transaction that paid the miner then intentional double-spends would seem to be the only way we get 0/unconfirmed transactions that don't complete. In any case chargebacks from intentional fraud are a subset of chargebacks, so the percentage should (in theory) be less for BTC than CC. Sep 1, 2011 at 18:58
  • Rewrote question to correct multiple terminology and structure problems. My question should be clearer now (I hope). Sep 1, 2011 at 19:13
  • @David Perry Much better now. I was also confused before, but now I understand it perfectly.
    – nmat
    Sep 2, 2011 at 6:36

2 Answers 2


An orphaned transaction is formally a transaction that depends on a prior transaction that is not yet in the block chain or pool. See the Protocol Rules. These types of transactions are held back from the transaction pool until the prerequisite is met. However, these types of transactions are very difficult to generate, the client won't generate such transaction, so you'd have to construct it manually.

The purpose of allowing them is because the protocol must allow for the possibility that it receives transactions in the wrong order. Accidentally generating transactions in the wrong order is not possible as far as I know.

If you are referring to orphaned blocks, then you should not see transactions get orphaned in this way, the blocks that are accepted instead of the orphaned ones should also contain all of the same transactions.

Edit: The question has been rephrased. The percentage of general transactions that never complete should be zero. I've never heard of it and I've never seen it. The two exceptions, as mentioned elsewhere are coin generation on orphaned blocks, and intentional double spend attempts (in which case the answer is "as many times as people try to double spend"). As I mention above, the reason for this is because general transactions do not become orphaned if a block chain branch becomes orphaned.

  • Then why would there be ANY general consensus that we need to wait until 6 confirmations to accept a transaction? There is some basis to this question though perhaps I've used the wrong specific terminology. The general form would be "what percent of 0/unconfirmed transactions never reach 6/confirmed?" If you can suggest a better way of phrasing it I'll happily edit my question. Sep 1, 2011 at 18:29
  • Yes, "Orphaned" is the wrong term. "Unconfirmed" is what you want. Orphaned transaction can be complete gibberish and are not validatable. I assume you meant unconfirmed but known valid transactions. It has to be this way because of the way your question was phrased. If you had said "What percentage of orphaned transactions make it into a block?" then it could be interpreted the other way. Sep 1, 2011 at 18:34
  • The only context I understand your question to work in is an intentional double spend. Where a person using two clients with the same wallet attempts to spend the money in two places at once. One of those transactions will become valid, the other will not become orphaned but will cease to exist because it is not a valid transaction in the accepted block chain. The person victim to this will not see a 0/unconfirmed message, the transaction will disappear altogether (they where never paid the bitcoins). Sep 1, 2011 at 18:34
  • They will see the 0/unconfirmed while the transaction paying to them is pending and the transaction paying to someone else is unconfirmed. Then it will disappear when/if the other transaction confirms. This is the case I believe the question is about. Sep 1, 2011 at 18:35
  • Right, but being a "big player" you won't see these 0/unconfirmed messages in your transaction history. They will all be valid except for the most recent few, or the big player is the one attempting the double spend. Sep 1, 2011 at 18:40

I have watched for reports of a transaction that appeared live on the net that never got into a block. It has never happened, and I don't think it's likely to happen. The only practical way for it to happen is for the network to be split due to a connectivity problem or for a miner in cahoots with the person attempting the double-spend attack to mine a conflicting transaction (not accepted by the network) into a block before the transaction itself gets into a block.

I agree that accepting 0/unconfirmed transactions is sufficient for point of sale applications. Someone is very unlikely to attempt a double-spend in person for a few thousand dollars or less and is even more unlikely to succeed. (Update: Due to the risk of the Finney attack, I withdraw this argument.)

I think your guess is only reasonable within limits though. For big transactions, companies will sue people who charge them back. They can do the same thing with Bitcoin transactions if they ask for ID first. For face-to-face transactions, I don't think confirmations matter for transactions that aren't massive.

It's not a big deal for online transactions for a different reason. If we're talking a small payment for access to a web site, is anyone really going to bother with an attack? And does anyone care? Here, the percentage risk argument works. And for big online stuff, delivery's usually not immediate anyway (think PayPal, eBay, Amazon).

  • I agree wholeheartedly with your statements here, the only reason I'm not marking it as the accepted answer is because I'm REALLY hoping to get an actual statistic out of this. It would make for an excellent talking point when trying to convince the merchants and short of mining up a small fortune in testnet coins and scripting a LOT of transfers I can't see any way to gather this statistic. Someone like MagicalTux might already have a wallet big enough to just grab a listtransactions and do some math. Sep 1, 2011 at 18:24
  • We need more answers per question anyway. :) Sep 1, 2011 at 18:27
  • Very true. I've been asking this on the forums for ages. Get the feeling I'll end up on testnet running a script for a week to get my answer :( Sep 1, 2011 at 18:31
  • The reason you haven't seen the race attacks yet are because there aren't hardly any real-world merchants accepting bitcoin:en.bitcoin.it/wiki/Real_world_shops Sep 5, 2011 at 2:23
  • Also, a criminal considering this would seek out a merchant that has no video surveillance, would not likely have race attack/double-spend monitoring in place (which none yet do) and sells items valued high enough so that the attempt would be financially worth the effort. Since a race attack could be technically successful maybe 50% of the time [wild-assed guess] it will likely be attempted once there are more tempting merchants out there. Sep 5, 2011 at 2:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.