Bitcoin Forum

No tx fee included although the amount isn't that tiny and the size is minimal:

https://blockchain.info/tx/072b41c0b11ff88b454e3a0c9c3a3810a74c3fa25d92209a856554d6fe26092a

Was sent nearly 24 hours ago and queue position seems to move and up then move back (now saying another 10 hours).

Is it likely to get "dropped" if I make sure my client doesn't broadcast it again (so I could try another spend attempt with a fee) or is it stuck until it's included no matter how long that takes?

It's stuck until it's including in a block unfortunately  :'(

Was afraid that that would be the case.

:(

The problem you are having is TradeFortress keeps sending repayments after the Inputs.io "hack" and refuses to pay any Transaction Fees whatsoever that's the reason your queue position keeps going up constantly :'(

If a miner/pool could take a replacement raw tx for me then I'd gladly give them 0.0021 in fees (assuming it gets included in a block before the spend that's waiting).

You can try double spending this via http://doublespend.cfapps.io/

(not my tool)

It may or may not work. You need to put your private key, so be aware of the risks.

Right now its priority is 65.7M which is higher than the minimum required 57.6M so I'm somewhat surprised to see it isn't confirmed.

I just checked the website's source code and I wouldn't trust that website if I were you. It does a POST request with your private key to a certain page on the website (http://doublespend.cfapps.io/spend (http://doublespend.cfapps.io/spend))

Never trust a website with your private key if it does a POST request to somewhere else or when you cannot the source code.

Luckily it is a change address so am not really worried about the private key (as the one UTXO was the only one for this address).

But it didn't work anyway (am thinking that you'd need custom software on the miner side to replace the tx with another).

This is what I do when I have double spend problems with my faucet (don't even ask how they happen, because I have no idea), it might help you:

1. Send the BTC again with a fee to a new clean address. (You might have to import the private key in a wallet like Electrum)
2. Wait until that TX is confirmed.
3. Resend it again to the address with fee's.

The last TX will be accepted and the first one will be dropped.

Can't do - everyone has already seen the first TX so any attempt to spend that UTXO again fails.

Hmm, alright then. Anyway, good luck!

Hmm... strange - that particular transaction's *amount* appears in brackets in bitcoin-qt (i.e. [0.2121]) but another unconfirmed transaction amount does not.

Any idea why that is?

The tool I cited is made by someone I know (yes, the magic happens on the server, not client side). I used it to successfully get coins stuck in limbo for few hours. However, it was running on localhost that time. Possibly the cfapps.io server has issues connecting to the p2p network. Try again a few times, and make sure the fee is high.. at least 0.0005 btc.

If it prints a tx, try pushing it via blockchain.info/pushtx

Tried (and with a whopping 0.0021 fee) but again you can't do that as blockchain.info already sees the other spend. :(

This is why I suspect you'd need a customer "miner" that will replace the spending of the UTXO with another spend for a greater fee (it is not standard behaviour and double-spends will not be relayed either so no way to get it to such a miner unless directly).

You can turn off your client for a couple of days until the network forgets the transaction, then broadcast again with a fee.

Re: square brackets, no idea.

Am thinking I might try waiting for a couple of days (unfortunately bad timing for that as I need to send some other transactions).

Yes - the brackets are strange. In the case of one unconfirmed tx that doesn't have them I see (in the transaction details):


and in the case of the one with the brackets around its amount I just see:

And that is the problem. The magic could include sending the private key to an e-mail address or add it into a text file. Who knows? You have no way of proving that it doesn't do something like that.