<p>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 <a href="https://en.bitcoin.it/wiki/Protocol_rules" rel="nofollow">Protocol Rules</a>.  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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2011-09-01T18:29:54.687Z
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.
David Perry
CC BY-SA 3.0
2011-09-01T18:34:13.860Z
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.
David Schwartz
CC BY-SA 3.0
2011-09-01T18:34:50.463Z
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).
Joshua Kolden
CC BY-SA 3.0
2011-09-01T18:35:59.783Z
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.
David Schwartz
CC BY-SA 3.0
2011-09-01T18:40:54.983Z
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.
Joshua Kolden
CC BY-SA 3.0
2011-09-01T18:56:07.253Z
A big player will monitor the network continuously. They'll see all transactions posted to the network with the possible exception of transactions that conflict with transactions they've already seen. They'll know if a transaction "disappears" after they see it as unconfirmed. (They could know this even if it's not for them, but I doubt anyone tracks this except maybe researchers.) He's hoping they'll tell us if they've ever seen this. You could rephrase his question: "Has any valid Bitcoin transaction ever seen on the live network ever conflicted with a subsequent confirmed transaction?"
David Schwartz
CC BY-SA 3.0
2011-09-01T19:01:09.473Z
Ok that may make more sense.  He said "have wallets with enough transactions", which makes me think he's talking about someone with a lot of 0/unconfirmed messages in their client (which we agree doesn't happen), not a developer/researcher actively watching the transaction pool.  Basically this question is poorly formed on a number of levels.
Joshua Kolden
CC BY-SA 3.0
2011-09-01T19:07:14.313Z
It may not happen in the client but `bitcoind listtransactions` shows much more information than the client. For example, I had some orphaned block generation rewards during the I0Coin launch and they simply disappear from the client, but they're still listed in the JSON output of `listtransactions` - having never seen a 0/unconfirmed transaction that didn't "clear" I have no idea how they would show but I suspected they might.
David Perry
CC BY-SA 3.0
2011-09-01T19:14:50.243Z
I mean, even if a 0/unconfirmed only happens in a double-spend attempt, it doesn't make sense to me that the record of its occurrence should just *disappear* after the fact. I suppose there's only one way to confirm though... Perhaps some time this weekend I'll attempt to "attack" myself in such a manner.
David Perry
CC BY-SA 3.0
2011-09-01T19:28:07.173Z
Yeah it does disappear.  In fact I'm surprised that listtransactions shows them, I wonder if it's caching results. Have you tried -rescan? I don't see how you could get that information unless the client always evaluates all orphaned branches, but then you'd also see two numbers for valid transactions and other weirdness.
Joshua Kolden
CC BY-SA 3.0
2011-09-01T19:31:53.837Z
I'll try a `-rescan` on I0Coin when I get home tonight, see if the "orphaned" listings disappear. I don't remember what field it showed it in but it did at least label the transactions as "orphaned."
David Perry
CC BY-SA 3.0
2011-09-01T18:26:42.607Z
2011-09-01T19:17:59.663Z
2011-09-01T19:17:59.663Z
Joshua Kolden
<p>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.</p>

<p>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. (<strong>Update</strong>: <em>Due to the risk of the <a href="https://bitcoin.stackexchange.com/questions/1192/would-a-reduced-block-generation-time-make-the-finney-attack-more-difficult/">Finney attack</a>, I withdraw this argument</em>.)</p>

<p>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.</p>

<p>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).</p>

CC BY-SA 3.0
2011-09-05T02:23:46.167Z
The reason you haven't seen the race attacks yet are because there aren't hardly any real-world merchants accepting  bitcoin:https://en.bitcoin.it/wiki/Real_world_shops
Stephen Gornick
CC BY-SA 3.0
2011-09-05T02:31:45.497Z
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.
Stephen Gornick
CC BY-SA 3.0
2011-09-01T18:24:12.183Z
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.
David Perry
CC BY-SA 3.0
2011-09-01T18:27:40.657Z
We need more answers per question anyway. :)
David Schwartz
CC BY-SA 3.0
2011-09-01T18:31:13.950Z
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 :(
David Perry
CC BY-SA 3.0
2011-09-01T18:15:23.390Z
2015-09-03T03:00:59.877Z
2017-04-13T12:47:33.743Z
David Schwartz
<p>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:</p>

<ol>
<li>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).</li>
<li>Is there anything aside from a double-spending attempt that can produce a 0/unconfirmed transaction that does not confirm.</li>
</ol>

<p>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.</p>

CC BY-SA 3.0
2011-09-01T18:50:04.960Z
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.
Joshua Kolden
CC BY-SA 3.0
2011-09-01T18:58:56.777Z
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.
David Perry
CC BY-SA 3.0
2011-09-01T19:13:21.853Z
Rewrote question to correct multiple terminology and structure problems. My question should be clearer now (I hope).
David Perry
CC BY-SA 3.0
2011-09-02T06:36:36.430Z
@David Perry Much better now. I was also confused before, but now I understand it perfectly.
nmat
<transactions><commerce>
What percentage of Bitcoin transactions never complete?
David Perry
# What percentage of Bitcoin transactions never complete?

(Asked by: username_0 on 2011-09-01)

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.

**Tags:** transactions, commerce

> **Comments:**
> **username_1**: 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 username_0's answers say effectively the same thing with regard to double spending.  
> **username_0**: 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.  
> **username_0**: Rewrote question to correct multiple terminology and structure problems. My question should be clearer now (I hope).  
> **username_2**: @username_0 Much better now. I was also confused before, but now I understand it perfectly.  

---

## 2 answers

### Answer by username_1 on 2011-09-01. Score: 3 | Accepted answer

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](https://en.bitcoin.it/wiki/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.

> **Comments:**
> **username_0**: 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.  
> **username_3**: 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.  
> **username_1**: 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).  
> **username_3**: 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.  
> **username_1**: 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.  
> **username_3**: A big player will monitor the network continuously. They'll see all transactions posted to the network with the possible exception of transactions that conflict with transactions they've already seen. They'll know if a transaction "disappears" after they see it as unconfirmed. (They could know this even if it's not for them, but I doubt anyone tracks this except maybe researchers.) He's hoping they'll tell us if they've ever seen this. You could rephrase his question: "Has any valid Bitcoin transaction ever seen on the live network ever conflicted with a subsequent confirmed transaction?"  
> **username_1**: Ok that may make more sense.  He said "have wallets with enough transactions", which makes me think he's talking about someone with a lot of 0/unconfirmed messages in their client (which we agree doesn't happen), not a developer/researcher actively watching the transaction pool.  Basically this question is poorly formed on a number of levels.  
> **username_0**: It may not happen in the client but `bitcoind listtransactions` shows much more information than the client. For example, I had some orphaned block generation rewards during the I0Coin launch and they simply disappear from the client, but they're still listed in the JSON output of `listtransactions` - having never seen a 0/unconfirmed transaction that didn't "clear" I have no idea how they would show but I suspected they might.  
> **username_0**: I mean, even if a 0/unconfirmed only happens in a double-spend attempt, it doesn't make sense to me that the record of its occurrence should just *disappear* after the fact. I suppose there's only one way to confirm though... Perhaps some time this weekend I'll attempt to "attack" myself in such a manner.  
> **username_1**: Yeah it does disappear.  In fact I'm surprised that listtransactions shows them, I wonder if it's caching results. Have you tried -rescan? I don't see how you could get that information unless the client always evaluates all orphaned branches, but then you'd also see two numbers for valid transactions and other weirdness.  
> **username_0**: I'll try a `-rescan` on I0Coin when I get home tonight, see if the "orphaned" listings disappear. I don't remember what field it showed it in but it did at least label the transactions as "orphaned."  

---

### Answer by username_3 on 2011-09-01. Score: 6

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](https://bitcoin.stackexchange.com/questions/1192/would-a-reduced-block-generation-time-make-the-finney-attack-more-difficult/), 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).

> **Comments:**
> **username_0**: 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.  
> **username_3**: We need more answers per question anyway. :)  
> **username_0**: 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 :(  
> **username_4**: The reason you haven't seen the race attacks yet are because there aren't hardly any real-world merchants accepting  bitcoin:https://en.bitcoin.it/wiki/Real_world_shops  
> **username_4**: 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.  

---

