You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many orphans, so I believe there are many different reasons for them. I will try to list here what I find:
Locktime issue
If a node lags behind in block processing - it might reject transactions that have a locktime. So all children of such transactions will be orphans
Orphans I was observing were not truly orphans. They were already included in a block. And this block was already processed by my node. No forking occurred. What went wrong is the AlreadyHave function.
This function looks for tx hash in mempool and also:
pcoinsTip->HaveCoinInCache(COutPoint(inv.hash, 0)) || // Best effort: only try output 0 and 1
pcoinsTip->HaveCoinInCache(COutPoint(inv.hash, 1));
Setup:
We have a transaction a in block A.
In the following block B we spend the only output of a.
And now, If some node lags a bit - it might send you a while you already have B. AlreadyHave will treat this as a new transaction!(because this tx is not in mempool anymore and it's outputs are spent). a ends up in orphan pool because it's inputs are spent by... a.
I tried making a workaround fix by storing all recently connected txs in ConnectBlock and checking for them in AlreadhyHave and I have 0 orphans. So this confirms my theory.
This all leads to lots of inefficiencies in tx transfer - such transactions are relayed several extra times and debug log is also misleading. Not to mention orphan pool pollution.
I suggest moving this issue into next milestone. Because mentioned inefficiencies are not critical.
I am observing lots of orphan transactions processed by my node:
The text was updated successfully, but these errors were encountered: