It doesn't exist in my mempool either... So i dug a little deeper:
618fd46987cf54d8b61f05408708962fcb60a4a21f574f8a5a01106298f3c5a4
depends on unconfirmed inputs that were generated by
966d9a0be165593850e90e1c42adbfdf1a475b893a617425dfa0eb0af81dca88 which inputs are double spent by a4f76f6c820e8ed7dab4ab09939d77993c7c7365ca13a56c544937791619d53c
ViaBTC's node rejects transactions double spending inputs (as does my node), so viabtc didn't have transaction 966d9a0be165593850e90e1c42adbfdf1a475b893a617425dfa0eb0af81dca88 in its mempool (since it double spends inputs), so when it received your transaction it was rejected because the inputs were not in the UTXO set (they were not in the utxo set because the parent transaction was rejected)...
This one is actually pretty hard to crack... Can you tell me a bit about what happened? Were this transactions between your own wallets, or did you get payed by somebody? Did you use escrow? Was it a trusted person/service? What kind of wallet are you using???
Yeah I got paid by somebody and he's trusted because I'm paid few times. The wallet I'm using is Coins.ph, and I have received bitcoins from him with this wallet for my simple tasks.
This is turning into a big cluster here...
Somebody (probably the guy paying you), had an unspent output that he could spend, namely the output of (confirmed) transaction 2b6892629f357dc2ab26ee2d1dcea7c7cf5a6772e40ed1857b55bf57a5c01190
He used this one output to create 2 new transactions, namely 966d9a0be165593850e90e1c42adbfdf1a475b893a617425dfa0eb0af81dca88 and a4f76f6c820e8ed7dab4ab09939d77993c7c7365ca13a56c544937791619d53c... Both transactions use the same input, thus are double spending it, meaning only one of the two transactions can actually ever end up in a block, as soon as it does, the other one gets voided since it now uses an input that is no longer in the UTXO.
Both transactions use the same input, but also generate the same outputs, albeit, one of the two has a smaller output to the change address (thus a bigger fee)
The problem is that the outputs of both double spending transactions are now used to generate 2 new transaction chains...
966d9a0be165593850e90e1c42adbfdf1a475b893a617425dfa0eb0af81dca88 is a parent for
618fd46987cf54d8b61f05408708962fcb60a4a21f574f8a5a01106298f3c5a4 is a parent for
fce42478c33fc984c6acbb0242fec68061f0521f3211db491975549b4bf3e7d1
Addresses receiving funds from this chain: 33gvwFn2qMwCf3FnRBAN3w4eQP5AhVW1SQ, 39UJnWMpVKyegPJxotDZEVrrwGtXcygkB9, 19przVDzBdPYCUeqfEKACmWTRinNgDReCS
AAAAND
a4f76f6c820e8ed7dab4ab09939d77993c7c7365ca13a56c544937791619d53c is a parent for
f55049d3db713b7077bc3a0c7bc33fba22fe49121da8baf4dde78fb6c83a9d7
Addresses receiving funds from this chain: 33gvwFn2qMwCf3FnRBAN3w4eQP5AhVW1SQ, 3Lvd22fLHeari3VqHZjVcT4DHHJRTY4bAR
One of these chains is going to get voided sooner or later, and everybody payed by the voided chain will be a victim... It's pretty hard to predict which chain will get voided.
Your possible sollutions are rather minimal... You could contact the guy paying you and point out the problem or you could try a CPFP, altough i have no idear how to do this with an online wallet (like coin.ph). I don't think a lot of miners will be able to help you... Since most of the transactions had a sub-standard fee, you might get lucky if both transactions get dropped from the mempool of most nodes before a miner decides to put them into the block he/she is working on.