One of the inputs for your transaction comes from 86b83900eb92fed174f5f620325c4bfe9b4f28ab0d26cf852a61ebba6eac59b3
That's a big transaction, 25kb with zero fee. And you need that one to get confirmed in order to have yours confirmed.
Accelerating that will not work with ViaBTC since the fee is zero. I don't know how CPFP could work for such a big transaction with so many outputs...
However, the problem is not your transaction; the problem is the source of your money (well, one of the sources).
I didn't dig this deep, but this is also a good explanation why the OP's tx is not broadcasted properly... If one of the inputs is unconfirmed and comes from a tx that has a 0 fee, it was probably rejected by a large part of the network, so the output never made it to the UTXO set, so OP's tx used inputs that were not in the UTXO, so it got rejected aswell... I tought it had something to do with double spending transactions that were still in the mempool, but this theory might actually be a better one
... I have to dig a bit deeper next time i give some advice
@OP: if this is true, chances are slim the parent transaction (the zero fee one) will actually get confirmed, unless there's a pool that mines it because it has a high priority (small chance, since most miners don't seem to reserve any more space for high priority transactions).
I'd focus on transaction 86b83900eb92fed174f5f620325c4bfe9b4f28ab0d26cf852a61ebba6eac59b3 first... If it's really important you can spend this output, try to do a CPFP, try to contact Quickseller or macbook-air and offer a reward, or try to convince the sender to double spend the inputs for this transaction to create a new transaction with the same outputs but a higher fee (so less output to the change address).
If you don't really need to spend the output from the parent transaction at this specific time, an other option would be to re-create your transaction, using the same inputs, exept the input you got from tx 86b83900eb92fed174f5f620325c4bfe9b4f28ab0d26cf852a61ebba6eac59b3.
