https://blockchain.info/tx/d2c8fe92f6f7f76ed967b47e6bfc8a411a5e28f2540c2da95cee6bd9da5c0c0a
https://blockchain.info/address/19bfw2P4fHfa4d6QBEkitguMsAN3z6vGfi <--the wallet
hmm... I dug some further:
the input of d2c8fe92f6f7f76ed967b47e6bfc8a411a5e28f2540c2da95cee6bd9da5c0c0a is vout n 0 of transaction af7337db5b6b5b3626d3ff6a7eb9866936a8ca2a336ca4e7e553a5aab2a6a7fe
the inputs of af7337db5b6b5b3626d3ff6a7eb9866936a8ca2a336ca4e7e553a5aab2a6a7fe are vout 1 of transaction 0c268d227af93bd448b17e961399bacc2992c7ddf39f4d6d470eff259890fd36 and vout 56 of b8d21dd69beab619f2617d97412a60f0964c7151a017d2a2a78298ba3cc00e59
blocktrail claims that af7337db5b6b5b3626d3ff6a7eb9866936a8ca2a336ca4e7e553a5aab2a6a7fe is using the same inputs as 04272f25818acfcc8e97ab796cb22921bef9725380b185d08feb9a4fe7a05a19
and they are correct, because if i look it up, the inputs of 04272f25818acfcc8e97ab796cb22921bef9725380b185d08feb9a4fe7a05a19 are vout 1 of transaction 0c268d227af93bd448b17e961399bacc2992c7ddf39f4d6d470eff259890fd36 and vout 56 of transaction b8d21dd69beab619f2617d97412a60f0964c7151a017d2a2a78298ba3cc00e59
I'm pretty tired at the moment, but it seems to be a bug in blockchain.info's block explorer. If the parent transaction af7337db5b6b5b3626d3ff6a7eb9866936a8ca2a336ca4e7e553a5aab2a6a7fe is using the same inputs as transaction 04272f25818acfcc8e97ab796cb22921bef9725380b185d08feb9a4fe7a05a19 (and 04272f25818acfcc8e97ab796cb22921bef9725380b185d08feb9a4fe7a05a19 is confirmed), then af7337db5b6b5b3626d3ff6a7eb9866936a8ca2a336ca4e7e553a5aab2a6a7fe can never confirm, thus any transaction depending on this transaction will never confirm.
For the second transaction that was expired/removed (d2c8fe92f6f7f76ed967b47e6bfc8a411a5e28f2540c2da95cee6bd9da5c0c0a) from blocktrail: this is not a big problem, it just means that blocktrails's node removed the transaction from it's mempool... It means it might be high time to either abandon the transaction, or rebroadcast it