Topic: Requesting parents for orphan transactions (Read 1011 times)

I agree lack of syncing is the most likely cause.

It could happen if a node received a long chain of transactions that aren't in a previous block.

The case outside of the above, in which the OP was probably referring to, is Transaction Chaining. To clarify for other users, and possibly get more information by someone who are more informed than I (perhaps as to if there are any other cases, or if any recent updates have affected this):


Transaction chains aren't sinister.  They are just transactions that are included in a block yet but are multiple levels deep.

Coinjoin is different, it isn't a chain, it is a way to combine multiple transactions into 1 transaction.  If you have a 10 one input, two output transactions, then you can combine them into a single 10 input and twenty output.  That means you can't match whos input matches with who's output.


If the transactions all pay fees, then it can't be used for that reason.  Even free transactions "pay" with coin-age.  DDOS protection happens by refusing to forward double spends.


The way it happens if if you haven't receive the parent of a transaction for some reason.  The suggestion is to allow nodes request the parent.  Most times you would just be missing one parent transaction and then you can insert that transaction into the memory pool and also the orphan.

To clarify for everyone who comes across this thread:

In most cases, not having a known parent means you don't have the block the parent is in (as opposed to an actual tx entry in your mempool or mapOrphan). Orphaned transactions should NOT be relayed to other nodes -- until they are being added to mempool (and thus no longer orphans). The typical cases for receiving an orphan tx:

-Your block chain isn't up to sync. (Either not at the bitcoin network height and is still syncing, in which case once it is caught up, it will have the parent information in blocks, and there isn't any value to having the txids in memory ahead of time. OR you just haven't gotten the newest block yet, which is unlikely since <45 seconds 95% of the network has a new block -- and in which case in a few seconds, it will.)  

-You or they are somehow on a forked chain: If you are, once you resync to the main chain you will have the proper reference, and if you stay off it for whatever reason the txids have no value anyway. If they are and the tx isnt already in a block then its likely the vin involved is coming from a block orphaned from the main chain -- in which case they are invalid and once that node is back on the main chain will realize this.

-A broken, malicious, or protocol violating node is attempting to relay an Orphan Transaction that it should not be, in which case it should not be followed up.

-A contract style tx with a locktime. (Also, should not be propagating across the network.)

In these kind of cases there wouldn't really be any benefit to requesting the txids of parents, because you have them in blocks already so your just taking up memory and network traffic for information you have to cross reference in blocks anyway.

The case outside of the above, in which the OP was probably referring to, is Transaction Chaining. To clarify for other users, and possibly get more information by someone who are more informed than I (perhaps as to if there are any other cases, or if any recent updates have affected this):

Transaction chaining is when multiple transactions which are dependent on other transactions being included being signed are sent at the same time -- in which case they can be included in the same block, and reference each other in that block as long as the vins are all proper (or, the tx's with vins already in a block get included in this one, and the others bounce through nodes or sit in mempool until the next in which they can reffer to the tx in the prior). There are some sites and services and techs that in the past have done this(CoinJoin), I do not know if they still do or the current implications of doing such. As far as im aware, it leaves one open to denial of service and potentially other types of attack through transaction malleability and other means -- although I know malleability concerns have mostly been addressed.  

So in the case of Transaction Chaining, it might make some sense, but its also logical since your connected to that node its likely to have relayed the other tx's as well. Also, I do not think transaction chaining is popular(and potentially reliable) enough to warrant this kind of change.

Right.  In that case, it counts as it having the transaction. 

I was thinking of the memory pool.  A response to a request for a transaction's parent could be the hash of the block.

Parent transaction can be already confirmed in block.

An orphan transaction is a transaction where some of the parents are missing.  This means that it cannot be added to the memory pool, since there is no way to verify those inputs.

Orphans are handled by being added to a hash map.  There is a limit of 100 orphans allowed at a time.  If more than 100 are in the store, then a random one is thrown out.

If a node sends an orphan transaction, then it should have the parent of that transaction.  If an orphan is added to the orphan pool, then the node which sent the orphan could be sent an inv message for the transactions that provide the missing inputs.

Something like the "getheaders" message would make this more efficient.  The "gettxs" message could a list of txids.  It would return the txids of all ancestors of any of the transactions in the list back until they hit a parent that was buried in a block at least 2 blocks deep (as far as the peer knows)  That is probably overkill though.